Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Role/User changes in AIM should be run separately #423

Open
massenz opened this issue Oct 13, 2021 · 3 comments
Open

Role/User changes in AIM should be run separately #423

massenz opened this issue Oct 13, 2021 · 3 comments

Comments

@massenz
Copy link

massenz commented Oct 13, 2021

Several of the TF actions in the infrastructure/terraform/environments/shared folder make changes to the Roles and Policies in AIM, and require to essentially run the zero apply with an Admin-level user; this is probably unnecessary for most of the other deployment actions, where a much lover permission level is required.

Also, deploying resources with such a high privilege level may complicate matters when tearing them down.

It would be great if those could be separated out (zero prepare?) with a separate, admin-level user; also bearing in mind that they won't probably change much over the course of a project's life, so could easily be only run once.

@davidcheung
Copy link
Contributor

Thanks for the suggestion @massenz!

Right now we're assuming someone with AWS account's root access doing the provisioning and updating the infrastructure (creating the eks creator role...etc) and haven't been a priority as there isn't too much in the shared-env

Yeah the separation down the road can definitely add value,
more frequently changed resources like the users list and other shared resource (ECR moving to shared), would allow us to include CI for deploying the terraform changes too

@bmonkman what do you think?

@bmonkman
Copy link
Contributor

When the apply command runs the "shared" terraform it creates any users specified there, but previous to this step we sort of have to assume that the user has provisioned their own AWS user with admin access and some credentials, otherwise they won't be able to run anything.
Yeah I agree that it would be better to be able to fully separate all IAM actions into a different set of terraform which must be run by someone with full access and then encourage people to use the user creation terraform to create themselves a new "operator"-level account which has access to do everything else within the terraform but not the IAM stuff.
We'd need to think about this though because right now the actual creation of the per-environment IAM stuff is done in the terraform for each environment, so we'd need to entirely separate them, then we would need to audit the "operator" role we are creating to make sure it has full access to everything the rest of the terraform needs to do.
All-in-all we would need to do quite a bit of detangling and instead of having the current setup where we create users in "shared" and then assign them per-environment roles and instead we would need to probably combine them all into that single "shared" environment.

@massenz
Copy link
Author

massenz commented Oct 21, 2021

Thanks for getting back to me - I was only able to follow partially :) as I'm not that familiar with TF (otherwise, I'd have offered contribute it myself...).

I still think the separation of the roles in a "God Mode" admin and a "DevOps Mode" operator would make it easier to keep the roles (and the TF code) separated in the long run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants