<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=389393) </details> <!--IssueSummary end--> <!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ## Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ## Problem to solve As an Application Operator, I want a very simple API and/or UI driven approach to authorize access of given Flux installation to my GitLab repo to retrieve manifests from it. As an Application Operator, I want a very simple API and/or UI driven approach to authorize access of given Flux installation and Kubernetes cluster to my GitLab container registry to retrieve containers from it. As an Application Operator, I want a very simple API and/or UI driven approach to restrict access to my manifests and containers only to the namespaces and service accounts I own. As a Platform Engineer, once I authorized a team to deploy using potentially a set of restrictions (a service account), I want to ensure that application team can easily deploy their workflows without much overhead. As a Platform Engineer, I want any keys accessing GitLab to be regularly and automatically rotated. ## Proposal In the agent `config.yaml`: ```yaml flux_access: role: read_repository | read_registry rotate: 90d projects: - id: group-1/project-A secret_name: gitlab-flux-token namespaces: - projectA groups: - id: group-2 secret_name: gitlab-flux-token namespaces: - project* ``` The above configuration will create a request under the respective projects and groups to authorize agent access. Once agent access is granted, GitLab sets up deploy keys with the given roles, and rotates with the given periodicity. ### Defaults ```yaml flux_access: role: read_registry rotate: 90d projects/groups: - secret_name: gitlab-flux-token ``` ### Out of scope Some users might prefer `role: api | write_repository`. These could be used to add an external commit status (`api`) when Flux reconciliation finished or to update the repository (`write_repository`) with the Flux image updater component. We might add these features later, but they are not in scope for the current issue. - `api` is not supporter by deploy keys as it's a different use case - `write_repository` while supported, we plan to recommend Renovate, instead of the Flux image updater component ### Created resources In the cluster, the automation creates the following resources For `read_registry`: ```yaml kind: Secret metadata: name: <secret_name> namespace: <one resource for each namespace in namespaces> spec: data: .dockerconfigjson: <the generated token as a docker config> ``` For `read_repository`: ```yaml kind: Secret metadata: name: <secret_name> namespace: <one resource for each namespace in namespaces> spec: data: username: the agent name (e.g. infra/agents:my-agent) password: the generated token ``` ### Tiering - The feature is available in ~"GitLab Free" , except for customizing `rotate` - A custom `rotate` argument is ~"GitLab Ultimate" - Out of scope for this issue: a compliance UI to report about the keys managed by this automation, available in ~"GitLab Ultimate" ## Intended users * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) ## Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> ## Educational Resources - https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/modules.md#extending-gitlab-kas-or-agentk-with-new-functionality About extending kas and agentk - https://docs.gitlab.com/ee/user/project/deploy_keys/ We talk a lot about Deploy Keys and Deploy Tokens - https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/kas_request_routing.md More interesting agentk/kas architecture - https://kubernetes.io/docs/concepts/security/multi-tenancy/ This is an incredibly good read and clears up a lot of the terminology around multi-tenancy (e.g. multi-team tenancy, multi-customer tenancy). - https://github.com/fluxcd/flux2-multi-tenancy This shows some examples as well as some Flux specific flows for onboarding new tenants ## Prior art / Related issues - https://gitlab.com/groups/gitlab-org/-/epics/7704+ <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->