[radedespodovski]

Since with Microtica you could provision any kind of AWS service the policy mentioned in the documentation is left to be more open so you can tryout fast and then when you figure out what you need the access could be reduced.

Ultimately, the user has the complete control over what access he will give to Microtica.

Since this policy was primarily intended for DevOps module, and Cost Optimizer needs only a subset of those permissions we will update the documentation to avoid the confusion.

[a012]

No, please just no. Don't give anybody outside of your org full admin permissions. Putting a bad example is bad, and also show their incompetences. At least they can put a red giant box to warn people, not expecting everybody know not to do it.

[scarface74]

I avoid giving myself admin permissions except when absolutely necessary. I created a “read only role” with no permissions and then started adding permissions to it as I run into issues.

I log into our management account and switch to the read only role for our prod account. If I have to switch to admin role I have the toolbar display as red.

If I’m that paranoid about me making a mistake, why would I trust a third party with those rights?

[radedespodovski]

Just realized that the example with CLI in the docs have the right policy with least privileges. Somehow the part with the full access was overlooked. We just updated the documentation.

I completely agree with your approach, we also encourage our users to start with the base permissions and then give more when necessary. Even more, to give an access only on resources provisioned by our system. As we automatically tag all resources, using IAM policy conditions this could be easily done. The control is always on the user's side.