Skip to content

Restrict access to a tunnel to specific environments

Release notes

The CI/CD tunnel provided by the GitLab Kubernetes Agent enables GitLab users to keep using their existing CI/CD based workflows, and still leverage the secure integration of a Kubernetes cluster with GitLab. A CI/CD tunnel can be shared among multiple groups and projects to save on resources and to simplify maintenance.

Until now, if a CI/CD tunnel was available for a project, the given tunnel could be used from all the branches, for all the environments. This functionality limited the use cases as some users would prefer to restrict access to some tunnels. Like access to the production cluster should only be available from the main branch as that describes the expected production state of the cluster.

Access to the CI/CD tunnel can now be restricted to specific environments or environments matching a wildcard pattern.

Problem to solve

As a Platform Engineer, I want to restrict ci_access sharing of the production cluster connection to CI jobs that reference a given environment.

As a Platform Engineer, I want to restrict ci_access sharing of the customer cluster connections to CI jobs that reference an environment matching a pattern.

Not in scope

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 production cluster connection to CI jobs that run on a Git tag following a pattern.

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

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.

UI proposal

The feature can be configured in code

ci_access:
  # This agent is accessible from CI jobs in projects in these groups
  groups:
  - id: group/subgroup
    environments:
    - staging
  - id: group/subgroup2
    environments:
    - dev
    - review/*

Intended users

User experience goal

The necessary Kubernetes context is injected only into pipelines/jobs that satisfy the requirements. If environments is not present in config, that means all branches and environments.

Proposal

ci_access:
  groups:
  - id: group/subgroup2
    environments:
    - review/*

Default

ci_access:
  groups:
  - id: group/subgroup

Means that the tunnel is available on all the branches and for all the environments.

environment:action support

The context should be available for all the environment:action categories

Implementation

  • [Agent] Update agent configuration to accept a list of environments for project and group entries.
  • [Rails] Update the allowed_agents API to filter by environments if applicable
  • [Rails] Verify the configured environments match that of the CI job when generating the injected KUBECONFIG

Further details

Permissions and Security

Permissions do not change in configuring the access. It still needs at least "Developer" access to the configuration project.

Documentation

Available Tier

GitLab Free

What does success look like, and how can we measure that?

  • collect the number of ci_access.groups, ci_access.projects configurations for a baseline
  • collect the number of environment configurations
  • 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.

Edited by Pam Artiaga