Those tips where posted between June and July 2022 on LinkedIn by Roberto Migli.
#IAM tip #1: There are 4 main types of IAM policies: Identity-based policies, resource-based policies, permissions boundaries, Organizations SCPs and Session Policies. Matt Luttrell's blog post will guide you through when and how to use them.
You can control authorization for the root user with an SCP or a resource-based policy. If you want to target the root user, you can use the condition key "aws:PrincipalType" with a value of "Account", or use the condition key "aws:PrincipalArn" with a value of "arn:aws:iam::*:root" 👇
Resource-based policy are sufficient to give access to a principal in the same account - except for 2 services (if you know which ones, comment below or look for tomorrow’s tip!). But to allow cross-account access, you need an allow statement both in the resource-based policy AND in the identity-based policy. For more information, see the doc page
IAM Roles have a resource-based policy and is called a trust policy. That’s how you define which principal can use the role. IAM roles trust policy is mandatory, and it must grant access to a principal even in the same account: IAM roles are one of the 2 exceptions mentioned in yesterday’s tip. For example, even if you have Administrator access, you cannot assume a role with the trust policy below, as it only allows AWS Lambda service as principal. What is the 2nd service that requires a mandatory resource-based policy for same-account access?
KMS key policies must authorize even same account access. Like we saw in the last tip, this is similar to IAM trust policies. This allows you even greater control over access to data in services that integrate with AWS, as explained in S3 this blog post.
When assuming a role, you can pass an inline session policy to filter out the resulting authorization. This is very useful to quickly test your policies - this gist will help you getting started. Bonus tip: do you know you can generate an URL to access the AWS Management Console from an access key ID, a secret access key, and a session token? See the gist for more info!
Although you could build a policy using the NotPrincipal element, there are very few scenarios in which it makes sense to use it - especially in combination with an Allow statement. Consider using the aws:PrincipalArn condition key instead. Have any use cases with NotPrincipal? Comment below!
aws:PrincipalArn is a very powerful condition key that you can use to limit a statement to a set of specific principal. Possible values for aws:PrincipalArn are:
- arn:aws:iam:::root when the AWS Principal is the root user
- arn:aws:iam:::role/ when the AWS Principal is an assumed role
- arn:aws:iam:::user/ when the AWS Principal is an IAM User
- arn:aws:sts:::federated-user/ when the AWS Principal is a federated user
Some condition context keys can be multi-valued: for example, aws:TagKeys contains a list of tags of the target resource. Use ForAllValues and ForAnyValue operators to compare such keys. Always look at the page "Actions, resources, and condition keys for " to check the type of a Condition Key and if it's multi-valued.
Do you want to have an overview of resources that are shared outside of an AWS account or Organization? AWS IAM Access Analyzer can do that for you, for free, and with literally just 3 clicks. You can (should?) automate Access Analyzer scans to be part of your cloud governance. Yes, it's free to use.
You can specify different types of Principals in a resource-based policy: AWS account and root user, IAM roles Role sessions, IAM users, AWS services and All principals - including anonymous principals for S3, SNS, SQS. Anonymous principal is equivalent to saying “anyone” - even if they’re not signed in to AWS. This is useful for making S3 public websites for example. Take extra care in writing policy statements that use “AWS”: “*” as Principal with an Allow effect.
In the previous tips we mentioned many times the resource-based policies: there are currently 30 services that use support resource-based policies. Resource-based policies are the preferred way to give cross-account access to those services. EC2 is a bit special in this: although the service does not directly use resource-based policies, it allows you to create VPC Endpoints. In turn, VPC Endpoints have policies that can allow/deny access to each service they are associated with. A cool feature of VPC Endpoints policies is that they allow you to create guardrails that apply to any identity that access the service through its VPC Endpoint - in contrast with SCPs that act on identities that belong to the organization. More on this topic in the next tip!
Identity-based policies, resource-based policies, SCPs and VPC Endpoint policies can be used together to create a Data Perimeter. The #data perimeter is a set of preventive guardrails in your AWS environment you use to help ensure that only your trusted identities are accessing trusted resources from expected networks. Regulated industries like FSI must make data perimeters one of their top priorities.
You can use the data perimeter as part of the Data Loss Prevention (DLP) journey. Ilya Epshteyn and his team worked on building a complete set of content, workshops, videos and blog posts to help you to build a data perimeter at scale.
The landing page on data perimeter is the best starting point . Did you already build your data perimeter? Comment below!
There are different IAM identifiers available to use. For example, customers commonly use ARNs such as arn:aws:iam::123456789012:role/S3Access to identify a role. There are also Unique Identifiers available - you use the command "aws sts get-caller-identity" to get the UserId field that includes your unique identifier. Unique identifiers are - by definition - unique!
Try to create a role named "unique-name", get its unique ID, delete the role, create in the same account a role named "unique-name" and get the unique ID again: you will get a different ID - although the ARN is the same.
When you write an IAM policy, IAM identifiers used in the Principal element are internally translated to unique IDs - and you can use them interchangeably as shown in the screenshot below. So if you create a statement in a resource-based policy that references a role by its ARN, delete the policy with that ARN and re-create a policy with the same name, that statement will never apply.
But, if you use the condition key aws:PrincipalArn, then you are referencing to - as the name says - the principal ARN, which is the same if you delete and re-create a role with the same name.
Bonus tip: the first 4 characters of the unique id tell you the resource type. In the example below it's a role principal and so the prefix AROA. Other common prefixes are AKIA to reference an Access Key and AIDA to reference IAM users.
Did you know you can programmatically test an identity policy with the API aws iam simulate-principal-policy ? John Culkin wrote a recipe part of his book "AWS Cookbook" to help you getting started and see it in action!
ArnLike is a very powerful policy condition operator to compare ARNs. ArnLike allows you to compare an ARN against a string pattern - by evaluating each of the six colon-delimited components of the ARN separately.
This is different from the condition operator StringLike, for example if you use the pattern arn:aws:someservice::111122223333:finance/ and you have a context value ARN of arn:aws:someservice:us-east-2:999999999999:store/abc:111122223333:finance/document.txt then StringLike will match, while ArnLike will not.
Get familiar with the IAM Policy evaluation logic by reviewing the dedicated documentation page linked below. For example, in the tip #3 we saw how a resource-based policy can allow same-account access - without an allow in an identity policy.
To see the this - and more - in action, I've built together with Ilya Epshteyn, Chungha Sung, Matt Luttrell and Cassia Martin a new workshop "IAM Policy Evaluation Logic in action" - which I'm excited to present in Boston at re:Inforce next week with Adam Andrews.
Don't know where to start on improving your security posture with IAM? Take a look at the newly released "Security best practices in IAM" from the official docs.
One of my favourites is about achieving least privilege: start with coarse-grained permissions in low-risk environments like dev, and reduce progressively permissions towards fine-grained access when you move to higher environments while gaining insights on how your application performs. IAM Access Analyzer can help you figuring out over time what permissions are actually required for your application!