Allow Restricting GitLab Agent for Kubernetes to Environment Tiers.

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Context

Currently the agent for Kubernetes allows us to restrict access to specific project environments. (docs and issue #343885 (closed)) This is super helpful for controlling access. However, this relies on projects to name environments as expected. This allows for situations where a developer in a project can simply change the environment name and begin deploying to a given environment. This is non ideal in environment where we have strict Separation of Duty (SOD) requirements.

This SOD requires that even project maintainers aren't allowed to deploy direct to production (lowering the value of protected environments as they are also project level controls). In order to comply with these controls we rely on Group level protected environments. Specifying a group that includes our operators. This works well and prevents us from needing to control specific project setup manually. However today the agent doesn't support this directly and introduces some complexities and inconsistencies with controlling agent access.

Current Workaround

Today we rely on the job impersonation RBAC restriction added under #357934 (closed) which works ok. This has improved thing from what we were doing previously and tying to specific project level environments. However this still allows the cluster to show up in the kubecontext for jobs that shouldn't have access to the cluster and only block once someone makes calls to the K8s API. We'd like to prevent the calls altogether, and not need to rely on multiple steps of setup for this protection.

Example RBAC ```yaml apiVersion: v1 kind: Namespace metadata: name: poc --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: poc-role namespace: poc rules: - apiGroups: - '*' resources: - '*' verbs: - '*' --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: poc-rolebinding namespace: poc roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: poc-role subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: gitlab:group_env_tier:1234:production ```

Proposal

Similar to #343885 (closed) we could add an environment_tiers option in the ci_access config to look something like this

ci_access:
  # This agent is accessible from CI jobs in projects in these groups
  groups:
  - id: group/subgroup
    environment_tiers:
    - staging
    - testing
  - id: group/subgroup2
    environment_tiers:
    - production

This would compliment the group level protected environments well and keep clusters out of kubecontexts that don't need them, and remove the need to manage RBAC rules.

It may be worth calling this deployment_tier to match the yaml keyword but the predefined var is CI_ENVIRONMENT_TIER.

I'm not sure on how this should behave if both environment_tiers and environments are specified. I think it would make sense to have environments take precedence as it is more specific.

Edited by 🤖 GitLab Bot 🤖