commitdev/zero

Role/User changes in AIM should be run separately

massenz opened this issue · 3 comments

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.

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?

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.

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.