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 the "GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG" automation are enumerated here: https://gitlab.com/guided-explorations/aws/gitlab-runner-aut...

I believe it should be - though I've not done it myself. One example I found was https://dev.to/stack-labs/securing-access-to-aws-iam-roles-f....

In addition, you can just assign IAM roles to the runner EC2 instances themselves, placing ALL of the authentication and authorization in AWS rather than in GitLab. Then the runner will only be able to access the things that you allow through its IAM policy.