3 ms·

This works if all developers understand IAM and don’t just throw a wildcard in the first time they don’t understand something.

bobbiechen 6y ago
Agreed, there is a large learning curve and it took me a long time to wrap my head around it. It requires a lot of knowledge and discipline, which sooner or later will create holes. For example, if you need to pass a role to a service, you'll need PassRole; if you grant it on " * ", then oops, you might have just created the opportunity for privilege escalation [1]. There's also probably issues specific to your company: allowing access to read resource foo in general is not an issue, except your specific company stores sensitive data there. If every developer is expected to be a security expert, the security risks increase, and the productivity overhead may even be worse than having a dedicated security/IAM team that gatekeeps permissions. [1] https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/ https://rhinosecuritylabs.com/aws/aws-privilege-escalation-m...
dopylitty 6y ago
I agree with this but I think AWS could have designed the interface for IAM policies better. There are a lot of actions where the resource has to be “”. There are also many situations where the Principal is because you’re using Conditions to restrict the access (eg by the org id). The resources are also “typed” despite the UI being json. This leads to confusion when a policy doesn’t work because the string in the resource is of the wrong type (eg S3 bucket vs S3 object). IAM happily lets you create the policy and there might be a small warning in the console that some of your policies somewhere have invalid resources for their actions but if you’re using CloudFormation you’ll never see those warnings. It begs for an automated linter that understands the type system and can fail your merge request or highlight the code in your IDE if the policy is invalid. AFAIK CFN-lint doesn’t do this but it certainly should.

bobbiechen 6y ago

Agreed, there is a large learning curve and it took me a long time to wrap my head around it. It requires a lot of knowledge and discipline, which sooner or later will create holes. For example, if you need to pass a role to a service, you'll need PassRole; if you grant it on " * ", then oops, you might have just created the opportunity for privilege escalation [1]. There's also probably issues specific to your company: allowing access to read resource foo in general is not an issue, except your specific company stores sensitive data there. If every developer is expected to be a security expert, the security risks increase, and the productivity overhead may even be worse than having a dedicated security/IAM team that gatekeeps permissions. [1] https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/ https://rhinosecuritylabs.com/aws/aws-privilege-escalation-m...

dopylitty 6y ago

I agree with this but I think AWS could have designed the interface for IAM policies better. There are a lot of actions where the resource has to be “”. There are also many situations where the Principal is because you’re using Conditions to restrict the access (eg by the org id). The resources are also “typed” despite the UI being json. This leads to confusion when a policy doesn’t work because the string in the resource is of the wrong type (eg S3 bucket vs S3 object). IAM happily lets you create the policy and there might be a small warning in the console that some of your policies somewhere have invalid resources for their actions but if you’re using CloudFormation you’ll never see those warnings. It begs for an automated linter that understands the type system and can fail your merge request or highlight the code in your IDE if the policy is invalid. AFAIK CFN-lint doesn’t do this but it certainly should.