what kind of application changes are you thinking it would equire?
my policies are definitely too broad, but feels like I should be able to tighten them up without changing code. (just potentially breaking things if I get it wrong and go too tight).
my policies are definitely too broad, but feels like I should be able to tighten them up without changing code. (just potentially breaking things if I get it wrong and go too tight).
1. The application has to start using credentials for the first time, or consume them a different way. For example, stop consuming an environment variable and rely on a service account.
2. You have to change ops to support new workflows. Often you have to put approval workflows in place because fewer people can do things and you want only the machines touching production
3. You have to change human behaviors and habits (this is the real hard one). I've had to revert changes because the increased security blocked developers and they don't have time to adapt for the next deadline.
4. Getting parity in local development workflows is also challenging. How and where do you match vs except from IAM parity?
5. Should I give the current server access to a particular cloud service/resource or break out that particular function into a lambda and minimize the permissions there? You have to think through the implications of a breach and how/where you want to limit the blast radius.
6. This is probably obvious, but implementing application level controls, like API endpoint permissioning. IAM is not limited to cloud infra
ask questions to deepen your understanding
> ...ping-pong...
It was a scheduling problem rather than a decision problem. The impact radius is always more than you anticipate