Fine-tuning access with AWS IAM global condition context keys
--
AWS IAM policies answer the question “who gets access to what?”. AWS IAM policy conditions answer the more precise question “who gets access to what, when?”. Conditions enhance the expressive power of IAM policies by allowing authors to restrict access control by context. But be warned! They come with surprising gotchas. This blog post describes the AWS global condition context keys (i.e. those prefixed with aws:) and their caveats. Use it as a reference the next time you need to solve advanced IAM access issues.
Restricting by calling service
CalledVia, CalledViaFirst, CalledViaLast
AWS “service-to-service” API requests are invoked by other AWS API requests. For example, a request to create a CloudFormation stack could cause CloudFormation to make a request to create an EC2 instance. The aws:CalledVia keys were released in early 2020 and can be used to restrict requests based on the chain of services making the request. CalledVia is a multi-valued condition key that can be used to restrict based on any, or all, of the calling services. aws:CalledViaFirst and aws:CalledViaLast are single values with the first and last calling service in the chain.
As of April 2020, CalledVia tags support four services: Athena, CloudFormation, DynamoDB, and KMS. These tags can help enforce the use of CloudFormation or restrict a KMS key for DynamoDB and Athena use cases.
ViaAWSService, SourceAccount, SourceArn
These older keys for restricting by calling service are more limited. aws:ViaAWSService is a boolean that is set to true for all “service-to-service” requests and is often used with other keys to distinguish direct versus indirect access. aws:SourceAccount and aws:SourceArn can be used to check the calling service account or resource, but only look at the direct caller instead of the entire call chain. These condition keys can be useful for preventing confused deputy vulnerabilities.
