Limit agent access to protected branches

Release notes

Problem to solve

As a Platform Engineer, I want to restrict ci_access sharing of the production cluster connection to CI jobs that run on a Git tag.

As a Platform Engineer, I want to restrict ci_access sharing of the staging cluster connection to CI jobs that run on the main branch.

As a Platform Engineer, I want to restrict ci_access sharing of the dev cluster connection to CI jobs that run on a review branch.

Quoting the user

For least privileged we use multiple agents in each project, one for each environment. Let's say we have a staging and a production environment on a separate cluster each. We can reference this agents now by stage in CI like this:

    deploy:production:
    image:
        name: bitnami/kubectl:latest
        entrypoint: [""]
    variables:
        # Agent configs are located in the project itself
        KUBE_AGENT_CONTEXT: $CI_PROJECT_PATH:production-agent
    environment:
        name: production
    script:
        # results in listing both production and staging context
        # anybody can use the context without any limitations
        - kubectl config use-context $KUBE_AGENT_CONTEXT

The problem, this is also possible from any other branch which means any branch or merge request is able access my production cluster. Using a Kubernetes context from CI variables was easy, because we could use protected variables with scopes to each environment, but there seams to be no such option for Kubernetes agents.

Proposal

Intended users

• Priyanka (Platform Engineer)

Feature Usage Metrics

• MAU of CI jobs with a restricted access

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.