search

buildkite / elastic-ci-stack-for-aws

An auto-scaling cluster of build agents running in your own AWS VPC
https://buildkite.com/docs/quickstart/elastic-ci-stack-aws
MIT License
417 stars 267 forks source link

Using existing IAM Role #536

Closed themohammedali closed 3 years ago

themohammedali commented 5 years ago

Are there any plans to allows us to use existing IAM roles when creating stacks, this would really save a lot of effort transferring policies to new roles the stacks cloudformation creates?

Thanks

lox commented 5 years ago

No plans, but sounds like an interesting idea that we’d welcome a PR for!

nitrocode commented 3 years ago

I'd like this feature a lot since our iam roles are tied to kms policies which need to be updated whenever we destroy iam roles or move queues to new iam roles.

To get around this issue were trying to make the buildkite queuename the stackname and the iam role so they are all consistent.

nitrocode commented 3 years ago

The current param InstanceRoleName is simply overwriting the IAM role name but for the IAM role to still be created by the stack so we cannot create a condition on this parameter.

I imagine it would have to be a new parameter like ReuseIamRole=true where you could create a condition that says to reuse the iam role passed in if this is set.

The issue with adding new inputs is that cloudformation has a bad limit of 60 input vars and the stack is currently at 57 iirc. What's a good way forward for this change ? @lox @yob

nitrocode commented 3 years ago

Scratch that. The 60 parameter limit has recently been raised to 200. I'll PR a new input parameter for the ability to reuse an existing role.

keithduncan commented 3 years ago

Are there any plans to allows us to use existing IAM roles when creating stacks, this would really save a lot of effort transferring policies to new roles the stacks cloudformation creates?

This should be automatable today using the ManagedPolicyARN parameter which accepts a list of IAM policies to append to the role.

I’m going to close this as I believe we have an answer for the outcome you’re looking for without supporting fully replacing the Elastic CI Stack’s role (which would have to support and track the new IAM actions the stack itself needs access to as you update).

Let us know if this parameter isn’t sufficient for your use case and we can look into alternatives 🙇‍♂️

nitrocode commented 3 years ago

Appending an iam policy to a role managed by the stack is very different from reusing an existing role.

What if you have an existing iam role with inline policies or an existing iam role name conflict. Now you have to convert your inline iam policies to managed policies, delete the existing iam role, and only to allow the cf stack to unnecessarily manage the iam role? It doesn't make sense. It seems like a limitation that can easily be lifted IMHO.

keithduncan commented 3 years ago

Appending an iam policy to a role managed by the stack is very different from reusing an existing role.

What if you were to provide assume-role permission into your fixed set of roles using a managed policy?