
AWS IAM Policies in a Nutshell - colemorrison
http://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/
======
ecesena
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

~~~
joshpadnick
I work on multiple AWS installations and we use the approach you describe of
only defining IAM Policies and avoiding resource-based policies where
possible. The one exception is KMS Keys, which require a KMS Key Policy.

That being said, I've found IAM's power impressive but ultimately complex. If
you're really serious about isolating users from certain resources, separate
AWS accounts for each environment may well be the best way to do this. This
way, you can grant "admin" access to users in your "stage" AWS account, they
get all the permissions they need to do their work, and have no permissions to
the more sensitive "prod" account.

~~~
ecesena
Out of curiosity, do you keep 1-1 mapping among
users/groups/roles(/resources?) across different accounts? Because that's
another possible source of complexity.

~~~
joshpadnick
We ([http://gruntwork.io](http://gruntwork.io)) are still establishing best
practices around managing multiple AWS accounts, but so far having a single
"admin" account where all IAM Users are managed seems like a best practice.
You can then implement a nifty dropdown that allows IAM Users to easily switch
accounts. [1] I'm not sure about how IAM Groups fits into this.

For IAM Roles, we use Infrastructure-as-Code (Terraform) to create all those
anyway, so I still prefer to create those in the AWS account that contains the
resources to which they apply.

[1] [https://aws.amazon.com/blogs/security/enable-a-new-
feature-i...](https://aws.amazon.com/blogs/security/enable-a-new-feature-in-
the-aws-management-console-cross-account-access/)

~~~
colemorrison
Just for anyone wondering, as per joshpadnick's great suggestions, you can
specify other AWS account's users/roles via Principal in a policy as well.
Just use the other AWS account in the ARN. edit: if you want to do so via
policies that is

I'd be interested to see your team's workflow for multiple accounts
@joshpadnick.

------
halestock
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
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
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
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_Assum...](http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)

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
Thank you for posting this.

------
sghiassy
Very nice explanation. Thanks!

------
officelineback
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
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
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
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

