6 ms·

AWS IAM Policies in a Nutshell

222 points by colemorrison 10y ago

officelineback 10y ago
Isn't the "Principal" element only a part of S3 permission policies, not IAM? In IAM the "principal" is implied, it's the user to which the policy is attached. Edit: I see you explain well into the article, but I believe the title of the article could be improved.
- colemorrison 10y ago
  Yeah, I mention that in the "Who" aka Principal section. It's like that for any resource based policy (i.e. like S3). So IAM Users/groups have it implied, but Resource based ones like S3 do not have it implied.
  - officelineback 10y ago
    The thing is, an S3 bucket policy is not an IAM policy. It's a bucket policy. They use the same language, format, and syntax, but they are not called the same thing.
    - colemorrison 10y ago
      Indeed, they're just a "resource" policy. They're still talked about and share the so many same attributes that it became more character saving to say AWS IAM Policies vs. AWS IAM, S3, SNS, SQS, Glacier Policies =P
- unkoman 10y ago
  Principal can be any AWS resource, such as Kinesis firehose or Lambda. Whichever resource that needs the permissions. For example: "Statement": [{ "Effect": "Allow", "Principal": {"Service": [ "firehose.amazonaws.com" ] }, "Action": ["sts:AssumeRole"] } ] }
ecesena 10y ago
Q: do you apply policy on roles, resources, or both? How do you maintain mental sanity? We use 1 base policy + 1 policy/role, and so for each role it's easy to see what are its permissions. We have no policy on resources, so it's hard, e.g., given a bucket to know who has access to it. We're building tooling for that. edit: grammar/typos
- colemorrison 10y ago
  It's honestly going to depend. In some cases you don't really have a choice. For example if you want to limit an S3 bucket to an IAM group, since S3/Resource Policies don't support IAM groups ARNs in the principal, the only solution is to apply the permissions around access to that S3 bucket to the IAM group (as opposed to the bucket). As for which direction, this is going to be a bit of preference and need. Do you want permissions to begin at the user or at the resource? For scenarios, like a bucket controlling access to non-aws users, it makes sense to have it on the resource. For others, like delegating bucket access to certain EC2 instances, it makes more sense to keep it on the role user. The fuzzy lines of gray are only exaggerated by the fact that the docs love doing stuff like: "These two policies are equivalent!" And showing examples that accomplish both. Tl;dr, (a) pick the permission direction that makes sense (b) set a standard for your team and infrastructure and stick with it (c) try to not use NotVersions of actions
  - ecesena 10y ago
    These recommendations are great, and for us the direction is definitely everything on roles. I was curious to see what others do concretely.
    - devonbleak 10y ago
      We have both out of necessity. IAM policies on roles/users/groups are a given, but here are some concrete examples of what we're using resource policies for: - Granting cross-account access to resources without requiring an explicit sts:AssumeRole on the other side (in some cases for things like CloudTrail and billing reports this is the only option) - Enforcing SSE on S3 buckets (implemented as a DENY in the bucket policy with conditions to check for missing SSE headers)
sghiassy 10y ago
Very nice explanation. Thanks!
halestock 10y ago
There's been lots of griping about AWS and IAM, which I'm sure is at least in part due to AWS' popularity, but how does it compare to permissions management from other major cloud providers, e.g. google and azure?
- devonbleak 10y ago
  Haven't dealt with Google much but Azure and AWS have good and bad points with identity. Azure is much easier to define RBAC access for individual resources in the portal, but doesn't give a unified view of what a user has access to (that I've found). AWS IAM provides a much more consistent experience across services - I have a key pair or role and that key pair/role works across all the AWS services according to the policies defined. Compare to Azure Storage Account access for example. AWS IAM can get frustrating when you take into consideration interaction between things like user policy, bucket policy and VPC endpoint policy when trying to access S3 from an EC2 instance in a VPC. AWS IAM policies can make it difficult to express some use cases, mostly relying on tags and the console doesn't support tags on resource creation for many services. I've also run into bugs in cloudformation where it ignores or doesn't support putting tags on redshift clusters, meaning the only way I could give someone access to create a redshift cluster with tags was either through the CLI or APIs directly. AWS IAM Roles and Instance Profiles are amazing for granting access to EC2 instances, and they added similar functionality for containers in ECS recently also. Overall I like the AWS approach better because I find it much easier to implement as code and also probably because I've been using it for much longer.
anon345235 10y ago
When you switch roles in the console, you don't have to enter in your credentials. So, if I get access to the account, I have access to all the roles. So, what additional protection is provided by separating out permissions into roles that are trivially accessible? I can see how if conditions are added to the AccessRole action, such that I can only switch roles based on time of day or IP address, then that might be useful (although those conditions could be applied directly to policies as well). So, absent the conditions mention above (which is still questionable), is there any point to using roles in the console?
- andrewguenther 10y ago
  This is where users come in. You should be setting up users other than the root user which have significantly fewer permissions. We essentially use our root user to set up the account and then throw away the MFA key (not really, but you get the idea). As for roles themselves in the console, those become useful when you're using federation: https://aws.amazon.com/iam/details/manage-federation/ https://aws.amazon.com/iam/details/manage-federation/ This allows you to use your company's own identity provider instead of IAM users (or in conjunction with). In this scenario, users access the console by assuming a role. You essentially say "Users within this Active Directory group are allowed to access the console by assuming this role." This process uses Active Directory to communicate with STS to give you a temporary token allowing you to assume the role: http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html http://docs.aws.amazon.com/STS/latest/APIReference/API_Assum... The diagram on this page provides a nice overview of how that all ends up working: https://aws.amazon.com/code/4001165270590826 https://aws.amazon.com/code/4001165270590826
konceptz 10y ago
Thank you for posting this.

222 points by colemorrison 10y ago

Isn't the "Principal" element only a part of S3 permission policies, not IAM? In IAM the "principal" is implied, it's the user to which the policy is attached. Edit: I see you explain well into the article, but I believe the title of the article could be improved.

colemorrison 10y ago
Yeah, I mention that in the "Who" aka Principal section. It's like that for any resource based policy (i.e. like S3). So IAM Users/groups have it implied, but Resource based ones like S3 do not have it implied.
- officelineback 10y ago
  The thing is, an S3 bucket policy is not an IAM policy. It's a bucket policy. They use the same language, format, and syntax, but they are not called the same thing.
  - colemorrison 10y ago
    Indeed, they're just a "resource" policy. They're still talked about and share the so many same attributes that it became more character saving to say AWS IAM Policies vs. AWS IAM, S3, SNS, SQS, Glacier Policies =P
unkoman 10y ago
Principal can be any AWS resource, such as Kinesis firehose or Lambda. Whichever resource that needs the permissions. For example: "Statement": [{ "Effect": "Allow", "Principal": {"Service": [ "firehose.amazonaws.com" ] }, "Action": ["sts:AssumeRole"] } ] }

ecesena 10y ago

Q: do you apply policy on roles, resources, or both? How do you maintain mental sanity? We use 1 base policy + 1 policy/role, and so for each role it's easy to see what are its permissions. We have no policy on resources, so it's hard, e.g., given a bucket to know who has access to it. We're building tooling for that. edit: grammar/typos

colemorrison 10y ago
It's honestly going to depend. In some cases you don't really have a choice. For example if you want to limit an S3 bucket to an IAM group, since S3/Resource Policies don't support IAM groups ARNs in the principal, the only solution is to apply the permissions around access to that S3 bucket to the IAM group (as opposed to the bucket). As for which direction, this is going to be a bit of preference and need. Do you want permissions to begin at the user or at the resource? For scenarios, like a bucket controlling access to non-aws users, it makes sense to have it on the resource. For others, like delegating bucket access to certain EC2 instances, it makes more sense to keep it on the role user. The fuzzy lines of gray are only exaggerated by the fact that the docs love doing stuff like: "These two policies are equivalent!" And showing examples that accomplish both. Tl;dr, (a) pick the permission direction that makes sense (b) set a standard for your team and infrastructure and stick with it (c) try to not use NotVersions of actions
- ecesena 10y ago
  These recommendations are great, and for us the direction is definitely everything on roles. I was curious to see what others do concretely.
  - devonbleak 10y ago
    We have both out of necessity. IAM policies on roles/users/groups are a given, but here are some concrete examples of what we're using resource policies for: - Granting cross-account access to resources without requiring an explicit sts:AssumeRole on the other side (in some cases for things like CloudTrail and billing reports this is the only option) - Enforcing SSE on S3 buckets (implemented as a DENY in the bucket policy with conditions to check for missing SSE headers)

sghiassy 10y ago

Very nice explanation. Thanks!

halestock 10y ago

There's been lots of griping about AWS and IAM, which I'm sure is at least in part due to AWS' popularity, but how does it compare to permissions management from other major cloud providers, e.g. google and azure?

devonbleak 10y ago
Haven't dealt with Google much but Azure and AWS have good and bad points with identity. Azure is much easier to define RBAC access for individual resources in the portal, but doesn't give a unified view of what a user has access to (that I've found). AWS IAM provides a much more consistent experience across services - I have a key pair or role and that key pair/role works across all the AWS services according to the policies defined. Compare to Azure Storage Account access for example. AWS IAM can get frustrating when you take into consideration interaction between things like user policy, bucket policy and VPC endpoint policy when trying to access S3 from an EC2 instance in a VPC. AWS IAM policies can make it difficult to express some use cases, mostly relying on tags and the console doesn't support tags on resource creation for many services. I've also run into bugs in cloudformation where it ignores or doesn't support putting tags on redshift clusters, meaning the only way I could give someone access to create a redshift cluster with tags was either through the CLI or APIs directly. AWS IAM Roles and Instance Profiles are amazing for granting access to EC2 instances, and they added similar functionality for containers in ECS recently also. Overall I like the AWS approach better because I find it much easier to implement as code and also probably because I've been using it for much longer.

anon345235 10y ago

When you switch roles in the console, you don't have to enter in your credentials. So, if I get access to the account, I have access to all the roles. So, what additional protection is provided by separating out permissions into roles that are trivially accessible? I can see how if conditions are added to the AccessRole action, such that I can only switch roles based on time of day or IP address, then that might be useful (although those conditions could be applied directly to policies as well). So, absent the conditions mention above (which is still questionable), is there any point to using roles in the console?

andrewguenther 10y ago
This is where users come in. You should be setting up users other than the root user which have significantly fewer permissions. We essentially use our root user to set up the account and then throw away the MFA key (not really, but you get the idea). As for roles themselves in the console, those become useful when you're using federation: https://aws.amazon.com/iam/details/manage-federation/ https://aws.amazon.com/iam/details/manage-federation/ This allows you to use your company's own identity provider instead of IAM users (or in conjunction with). In this scenario, users access the console by assuming a role. You essentially say "Users within this Active Directory group are allowed to access the console by assuming this role." This process uses Active Directory to communicate with STS to give you a temporary token allowing you to assume the role: http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html http://docs.aws.amazon.com/STS/latest/APIReference/API_Assum... The diagram on this page provides a nice overview of how that all ends up working: https://aws.amazon.com/code/4001165270590826 https://aws.amazon.com/code/4001165270590826

konceptz 10y ago

Thank you for posting this.