5 ms·

The problem is that all IAM conditionals just give a generic "Denied" statement which is hard to debug. You at left figuring out if you are missing a uppercase

The problem is that all IAM conditionals just give a generic "Denied" statement which is hard to debug. You at left figuring out if you are missing a uppercase character in your tag key. AWS IAM is currently not meant to be used in a devops/enforcement of best practices way. They have AWS config for that, but that's always after the fact while immediate feedback is what you need to function at scale. A possible fix is to allow custom deny reasons but large changes like this to any already extremely large and entangled system like IAM is unlikely.

whoknew1122 6y ago
> "A possible fix is to allow custom deny reasons but large changes like this to any already extremely large and entangled system like IAM is unlikely." This would allow an attack to enumerate permissions by seeing what's denied. Generic statements aren't a bug, they're a feature.
- Spivak 6y ago
  Yes, but what they're talking about isn't a security denial but a configuration check. Can you imagine if the only output to a git commit pre-hook was "no" and you were left to figure out why?
  - whoknew1122 6y ago
    > "Yes, but what they're talking about isn't a security denial but a configuration check." Configuration is a part of security though. Let's say AWS credentials are leaked. One of the most common uses for leaked credentials is to launch EC2 instance for crypto mining. A malicious actor tries to launch RunInstances on $20k worth of instances and gets denied because there isn't a tag on the instances. Would you want the error to say 'Access denied because you didn't don't have the following tag...'?
    - Spivak 6y ago
      Yes, because lacking a tag isn't a security boundary. The account has permission to launch EC2 instances and knowing that instances need to have tags isn't a password designed to keep malicious actors out, it's a safeguard.
- renewiltord 6y ago
  I feel like this is not a complex problem. You just ensure that someone has `iam:GetDetailedError`. Then you can turn it on for your role/user/whatever and if that doesn't work you can turn it on at the global level temporarily. After all, if you think about it, if you are unable to determine that you're denying the person for the right reason, you could easily later allow them for the wrong reason. e.g. A policy that's not meant to be applied to some IAM user is being applied to them but it's documented to be for a different purpose. When that purpose expires, you might remove that policy, and accidentally enable access. If you can get a trace of the denial then you know that it's for the right reasons.

whoknew1122 6y ago

> "A possible fix is to allow custom deny reasons but large changes like this to any already extremely large and entangled system like IAM is unlikely." This would allow an attack to enumerate permissions by seeing what's denied. Generic statements aren't a bug, they're a feature.

Spivak 6y ago
Yes, but what they're talking about isn't a security denial but a configuration check. Can you imagine if the only output to a git commit pre-hook was "no" and you were left to figure out why?
- whoknew1122 6y ago
  > "Yes, but what they're talking about isn't a security denial but a configuration check." Configuration is a part of security though. Let's say AWS credentials are leaked. One of the most common uses for leaked credentials is to launch EC2 instance for crypto mining. A malicious actor tries to launch RunInstances on $20k worth of instances and gets denied because there isn't a tag on the instances. Would you want the error to say 'Access denied because you didn't don't have the following tag...'?
  - Spivak 6y ago
    Yes, because lacking a tag isn't a security boundary. The account has permission to launch EC2 instances and knowing that instances need to have tags isn't a password designed to keep malicious actors out, it's a safeguard.
renewiltord 6y ago
I feel like this is not a complex problem. You just ensure that someone has `iam:GetDetailedError`. Then you can turn it on for your role/user/whatever and if that doesn't work you can turn it on at the global level temporarily. After all, if you think about it, if you are unable to determine that you're denying the person for the right reason, you could easily later allow them for the wrong reason. e.g. A policy that's not meant to be applied to some IAM user is being applied to them but it's documented to be for a different purpose. When that purpose expires, you might remove that policy, and accidentally enable access. If you can get a trace of the denial then you know that it's for the right reasons.