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

• Priyanka (Platform Engineer)
• Allison (Application Ops)

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

• Manifest projects outside of the Agent configur... (&7704 - closed)

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.