Matthias Käppler (b803a8c6) at 18 Mar 08:15

@nolith We intend to create a GATE Helm chart in https://gitlab.com/gitlab-org/cloud-native/charts. Are these repositories managed through (or integrate with) the Release Platform as well? Or should we just go ahead and create a chart repo in here manually?

Find or create a maintainers group for you project

We can probably create something similar to @gitlab-org/software-supply-chain-security/authentication/authentication-runway-access, maybe @gitlab-org/software-supply-chain-security/authentication/gate-maintainers?

Another option could be to just rename the Runway group to gate-maintainers since it's likely that contributors to the Runway components will also contribute to other GATE components. WDYT @adil.farrukh?

If you need runway deployments: follow the onboarding guide but instead on Step 3, do not add the CI component, instead add the runway project id to the already existing release-platform template

@jknabl-gitlab Heads up that for https://gitlab.com/gitlab-org/gitlab/-/work_items/587663+, in order to use the Release Platform components, the CI config changes slightly as per the above.

@daniele-gitlab Could you review this MR from your perspective? Does it add the all the config you need?

self-review: The use of gen_random is inconsistent across this file. I wonder why? We generate secrets of various length/randomness, sometimes we re-encode it to base64 (even when it's already just alpha-numeric characters), other times we don't. I picked a solution that seemed reasonable to me.

@rshambhuni Could you review this shared secret generation from an AppSec point of view?

self-review: Eventually,host and port should be required, however we can't do that yet since we don't have a chart for the iam-auth service (see above) and this will for now be a service on Runway, which wouldn't be a sensible default.

self-review: This service must currently be optional as we are in a transitory state where OAuth flows must remain functional both via Rails and this new service. We will first enable this integration on gitlab.com, then when it works satisfactorily make this a mandatory setting on the chart (i.e. remove enabled). However, this means we will also have to first provide a chart for the iam-auth service, so customers can run it too. This will happen as part of https://gitlab.com/gitlab-org/gitlab/-/work_items/569457+.

self-review/question: I wasn't sure why sometimes mountSecrets is defined on gitlab and other times on gitlab.appConfig. My understanding of appConfig is that these are the values users provide to the chart, and secrets should always be mounted i.e. or more of an internal function/template?

Matthias Käppler (7ffbf23b) at 17 Mar 16:08

... and 1 more commit

Matthias Käppler (907c3e20) at 17 Mar 15:21

Matthias Käppler (2220151b) at 17 Mar 15:13

Matthias Käppler (f5214ae1) at 17 Mar 12:40

Matthias Käppler (cdae7647) at 17 Mar 11:01

Matthias Käppler (5b476062) at 17 Mar 10:30