IAM policies to allow access to test environment but not production

[Kylir]

Hello!

We have been using Copilot for 2 years now. More than 8000 users, 3 environments and 11 services in each! A success story! A big thank you for making this possible :)

I have a question: So far I have been the only one configuring Copilot, deploying, accessing the logs, etc. My colleagues have been working through Github pipelines only. As our team is growing, I became the bottleneck. I need some of my colleagues to have access to the AWS resources for our Test and Staging environments. At the same time I want to restrict access to the Production one and all the customer data and secrets there.
What is the best way to manage this situation?

My knowledge of IAM is very limited. I was thinking about creating policies per environment/VPC or per services. But the list of resources is quite lengthy - and when we will add new services I will have to edit policies. That doesn't sound good.

Do you have any recommendations?
Thank you!

[Kylir]

I found that issue #2615 has a list of the IAM policies needed to deploy on a given environment. Looks like (the beginning of) an answer!

[dannyrandall]

Hey @Kylir! Great to hear your success story 🎉:relaxed:

You're right the an IAM role is probably the best way to restrict access to certain resources. There are a few different ways you could restrict access to specific environments, all with different tradeoffs. In my opinion, probably the best way I can think of doing that right now is by spitting up your environments into different accounts. In your case, you could have 4 separate AWS accounts:

1. "infra" account - This is the account you use to run your copilot commands
2. prod account - When running copilot env init (with infra account credentials), select the admin profile for this account
3. stage account
4. test account - both test and stage are created the same way as prod, just using a different profile.

Once you've created the environments using your IAM role, create a new role in the infra account with the policies listed in #2615. Copilot should have already set up a trust relationship between the infra account and the test/stage accounts' EnvManagerRole, so your new role should work for developers on your team that you don't want to give prod access to. Then, developers with restricted access use that infra account's role to run their Copilot commands, but are only allowed to run commands that affect the test/stage environments.

A couple of thoughts:

• You could combine the infra/prod accounts if you wanted, and the stage/test accounts too.
• Separate accounts makes it easier to give them a more permissive role to access the test/stage accounts in addition to the infra account role they use for Copilot that gives them flexibility to test things in those accounts, while limiting their blast radius.
• You could do something similar with a single account - just giving your colleagues access to a role that only has permissions to assume the env manager role for a specific environment. The downside is that you might not be able to give them a more permissive role to test things outside of Copilot without also giving the ability to affect prod resources.

To summarize options:

• multiple accounts, with a more permissive role to play with resources in test/stage (more complex, more flexibility)
• a single account, with a ReadOnly role to debug issues (simpler, less flexibility)

Both options require a role with the policies from #2615 to let them use Copilot for an environment, in addition to the extra role specified for Console access (assuming you want to give them that :))

I realize there's a lot here! So please feel free to ask any questions and I'm happy to clarify or go deeper into one of the options. 😊

[Kylir]

Hi Danny,

Thanks a lot for your answer. Took me a while to respond, sorry.
This is the setup we have: One AWS account with me as admin and colleagues with accounts belonging to a user group. I attached the policies listed in #2615 to the group but my users are still not able to run copilot on their machines with their aws cli configuration.
I'm missing something... I added a question in #2615 with the error message I'm getting. I don't even need my colleagues to deploy but see the logs, statuses and pipelines would be so handy.

[dannyrandall]

Hey @Kylir - sorry for the delayed response. Did your error get resolved in that issue?