<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ## 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 * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) ## 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](https://docs.gitlab.com/ee/ci/yaml/index.html#environmentaction) ## Implementation - [ ] [Agent] Update [agent configuration](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/pkg/agentcfg/agentcfg.proto#L121-131) 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 <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ## Permissions and Security Permissions do not change in configuring the access. It still needs at least "Developer" access to the configuration project. ## Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ## 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 <!-- 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 -->