Our great sponsors
-
trackiam
A project to collate IAM actions, AWS APIs and managed policies from various public sources.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Shoutouts to Aidan, he always manages to dig up some real obscure AWS insights!
I can recommend checking out his trackiam project too: https://github.com/glassechidna/trackiam
There are a couple approaches. GitLab's JWT token allows custom scripting to interface it to other systems. This demo shows custom integration with Vault (it also demonstrates our native integration - so you have to parse out which code you are looking at): https://gitlab.com/bdowney/vault-demo
Another approach is placing a GitLab runner within AWS and assigning it an IAM role directly. While this isn't as flexible, it is also not as complex to debug why a specific user can't build or deploy a job when another can.
In this scheme, there is potentially a runner per-dev team that has the same exact IAM profile as the dev team.
This can be done using KIAM for EKS runners, or if you are doing docker runners, you can use the "GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG" here: https://gitlab.com/guided-explorations/aws/gitlab-runner-aut...
That last automation is designed to be self-service and can be setup in AWS Service Manager for teams to self-deploy their runners.
The many other benefits to this automation are enumerated here: https://gitlab.com/guided-explorations/aws/gitlab-runner-aut...
There are a couple approaches. GitLab's JWT token allows custom scripting to interface it to other systems. This demo shows custom integration with Vault (it also demonstrates our native integration - so you have to parse out which code you are looking at): https://gitlab.com/bdowney/vault-demo
Another approach is placing a GitLab runner within AWS and assigning it an IAM role directly. While this isn't as flexible, it is also not as complex to debug why a specific user can't build or deploy a job when another can.
In this scheme, there is potentially a runner per-dev team that has the same exact IAM profile as the dev team.
This can be done using KIAM for EKS runners, or if you are doing docker runners, you can use the "GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG" here: https://gitlab.com/guided-explorations/aws/gitlab-runner-aut...
That last automation is designed to be self-service and can be setup in AWS Service Manager for teams to self-deploy their runners.
The many other benefits to this automation are enumerated here: https://gitlab.com/guided-explorations/aws/gitlab-runner-aut...
There's an open issue to try to enable it - Gitlab issues a unique JWT to every pipeline but it's not directly consumable by AWS right now so you'd have to write an intermediate service that could convert the gitlab token into an AWS session: https://gitlab.com/gitlab-org/gitlab/-/issues/216259#note_44...