IAM Is the Worst

We have enough advanced cryptographic schemes by this point where you can just encrypt most of the sensitive data stored in cloud environments at the client-level and render it useless to an attacker (barring considerations that they might hold on to the encrypted data until a weakness in the encryption scheme is discovered).

Store secrets directly with the client so attacks only compromise the data of one user and not all of them. Want if they lose the key or what if multiple groups need access? Shamir’s secret sharing. What if we might not trust some of the k of n group members? Require interaction with a public ledger that provably logs secret access as a part of the secret sharing scheme. What about machine learning on a massive amount of user data? Well, homeomorphic encryption isn’t quite there yet, but how much sensitive info do you really need for your training data?

We’re not going to eliminate security flaws in systems without provably correct programs by default (which is probably never going to happen), and even with that, you have the whole social element of security, which means you still need to design the system in a way that limits the damage one or a few people can do. Which requires a different type of identity management than IAM.

> The article completely addresses the problems in #1 and you’ve offered no solutions.

You don't define the privileges you need, by running around with full privileges. The article is pitching some kind of tool the author developed, but you can do the same at least for AWS, for a long time. And if you don't know what policies you need you should talk to either the vendor or the application creator, as you will never be able to exercise all the compute paths...

"Generate policies based on access activity" - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_poli...

I don't run any clouds myself but if I were AWS or whoever I'd think there's a whole lot of ways to make this process more ergonomic without sacrificing functionality. A tool that can report permission failures with a "should we allow this yes/n?" button for admins. A user (real or service) tries to run a cache invalidation, or write a redshift DB or add an IP to a security group and gets a "permission denied". Admin gets an email or a ticket saying what process failed and click a button to enable or deny.

Typing that out it's really the massive gulf between the abstraction "User wants to invalidate a cache" vs the implementation of 87 granular grants with obscure nomenclature.

Whether you agree with the article's recommendations or not, I do not understand how there are so many commenters saying "IAM is not that complicated". Even engineers internally at AWS frequently get tripped up with IAM permission settings. It's rare that someone gets them right on the first try.

Just some of the things that make it challenging:

1. There are permissions at various layers. If anything along the chain doesn't line up, permission denied.

2. You need deep understanding of each service's specific IAM setup. It's not enough to write a policy that will grant you read access to a DynamoDB table. Your application probably also needs to grant access to the GSI/LSI indices created.

3. Ancillary permission requirements are not obvious if you're not familiar with the details of how a service works. Want a Lambda function to have logs and traces? Make sure you have the relevant CW and X-Ray permissions set on it.

4. Permission related failures do not make the root cause immediately clear. Your S3 get operation may fail because you're missing permissions to the related KMS key. The usage of the ancillary KMS API calls here is not obvious unless you inspect the configuration details of the resource.

5. Secrets related permissions are especially tricky. To be able to read a cross-account secret, you need to grant the IAM identity permissions to get the secret value, grant the identity permissions to decrypt the associated KMS key used for the secret, grant the related account identities permissions to decrypt the key in the KMS resource policy, and grant the related account identities permissions to get the secret value in the secret resource policy. This is assuming there's no other things like SCPs and permissions boundaries mucking it up.

6. The out-of-the-box managed policies are too broad and will often have you granting much more permissions than you need if you use them.

Low level IaC tools like CloudFormation and Terraform suck for this. They leave too much complexity to the end user to get right. CDK does mitigate the issue somewhat with it's grantX methods, but even those are fairly limited and require you to write manual policy statements for many use-cases.

Isn't this already how it works tho? At least in my time doing internships, I would hit some screen saying access needed and just press a couple of buttons tagging my manager and some sec team and soon enough it would be granted or explained that, actually no, I was accessing the wrong stuff, and be pointed in the right way.