Dynamic assignment of IAM permissions in Kubernetes Executor
Release notes
GitLab Runner Kubernetes Executor supports dynamic assignment of IAM permissions.
Problem to solve
We are migrating from specific runners on EC2 managed by each development team to shared runners running in Kubernetes which will provide a centralized, managed, and maintained build infrastructure. One capability we are losing in this transition is team-specific or project-specific resource and deployment privileges. With specific runners in EC2, the runner inherits team-specific privileges under the assumed role of the EC2 instance. We can similarly assume a role with the Kubernetes executor, but we can only configure one such role (as an annotation) for every pod executed by the Kubernetes executor.
We need the capability to annotate each job differently (based one source project/group) to correctly assign IAM permissions to the job.
Intended users
- Devon (DevOps Engineer)
- Alex (Security Operations Engineer)
- Allison (Application Ops)
- Priyanka (Platform Engineer)
User experience goal
Devon, Allison, and Priyanka should be able to securely deploy their applications and access cloud resources while Alex feels confident that least privilege principles and compliance requirements are being met.
Proposal
There are several mechanisms that would meet this requirement, including allowing user-specified templates for the pod launched by the Kubernetes executor, or supplying a rules
construct in the pod_annotations
parameters to the executor.
Runner administrator should be able to conditionally annotate the generated job pods. Conditional rules should be have access to job, project, and group metadata (rules should be able to match project name, branch, project labels, or group labels).
Further details
This request has a specific need that it addresses, but the implementation could be slightly broader and cover a number of additional use cases (different cloud environments, other job pod dynamic policies). Depending on the implementation path chosen, I would recommend grabbing any other low-hanging fruit.
Permissions and Security
These features should only be accessible to the runner administrator, and GitLab server permissions are not directly applicable.
Documentation
This feature should be documented under the Kubernetes executor.
Availability & Testing
Available Tier
What does success look like, and how can we measure that?
Kubernetes jobs should be able to run with a different set of pod annotations when run under different projects.