Flux to GitLab access management
Release notes
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
:
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
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
:
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
:
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
Feature Usage Metrics
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
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.