Gitlab-runner: gitlabUrl: runnerRegistrationToken: 'aaaaaa-bbbbbb' unregisterRunners: false runners: outputLimit: 200000 privileged: true imagePullSecrets: - gitlab-registry-access-secret serviceAccountName: -gitlab-runner rbac: create: true resources: verbs: serviceAccountAnnotations: /role-arn: arn:aws:iam::111122223333:role/gitlab-runner-role Here is an example of a values.yaml file that can be used for a GitLab runner:

GitLab provides a Helm chart for the runner, it can be found here and thanks to this merge request we can now link an IAM role to a gitlab runner installation. IAM roles that use temporary credentials is the way to go.Īnd luckily now it is possible to link a GitLab runner deployed in a Kubernetes cluster to an IAM role. Using GitLab runners we can store some AWS credentials so we cna have access to these APIs in custom environment variables, but thats not a good practice because it is hard to rotate them and you might end up having them in many places.

So in our pipelines besides building binaries and pushing them to production, we need to do stuff like read/write to S3 buckets, read some tokens/credentials from AWS Parameter Store, add entries to Route53 and so on. And this means that your CI/CD pipelines for such repos need to perform a lot of things. It comes in handy because more things are moving to git as a source of truth.įrom infrastructure as code, pipeline as code, gitops it is not just code that resides in git nowadays, but also our configuration, infrastructure, all sorts of pipelines and a lot of other declarative manifests. And some of those scenarios involved CI/CD so I am going to explain how to setup an IAM role for your own hosted Kubernetes GitLab runners. This part with IAM roles for service accounts I want to touch because it is useful in many scenarios.

How to install gitlab on aws