Mastering AWS Condition Keys: The Key to Granular Access Control
- nandansv
- Sep 22, 2024
- 6 min read
Updated: Aug 17
Introduction:
Hello there! In today’s world of cloud computing, security is paramount, and AWS has provided us with a powerful tool called condition keys to help us maintain a robust security posture. Let’s dive into the world of AWS condition keys and explore how they can empower you to implement precise access control measures.
AWS Identity and Access Management (IAM) is a robust service that allows you to manage access to your AWS resources with ease. One of the core components of IAM is the use of policies, which define permissions for specific actions and resources. However, did you know that you can take your access control game to the next level by leveraging condition keys?
Condition keys are predefined variables that you can incorporate into your IAM policies to specify conditions for when a policy should take effect. These keys enable you to control access based on various factors, such as the time of day, the source IP address, or even the specific AWS service or resource being accessed. By utilizing condition keys, you can implement granular access control and enhance the security of your AWS environment, ensuring that only authorized entities can access your resources under specific circumstances.
Now, let’s address a common pitfall that many organizations face — overlooking the usage of condition keys. Neglecting these powerful tools can potentially lead to privilege escalation, which could have severe consequences for your data and applications. That’s why it’s crucial to embrace condition keys and leverage them to their fullest potential.
In this article, we’ll explore the different types of condition keys and provide practical examples to help you understand how to incorporate them into your IAM policies effectively. By the end of this journey, you’ll be equipped with the knowledge and tools to take your AWS security game to new heights, ensuring that your resources are safeguarded against unauthorized access while maintaining the flexibility to grant access when needed.
Get ready to embark on an exciting adventure into the world of AWS condition keys, where granular access control reigns supreme, and security takes center stage!
Types of Condition Keys:
AWS Global Condition Keys: AWS global condition keys are predefined condition keys that can be used across multiple AWS services. These keys are widely applicable and provide a consistent way to enforce conditions across your AWS resources. Some examples of AWS global condition keys include:
aws:CurrentTime: Allows you to specify a time range during which the policy is valid.
aws:SourceIp: Restricts access based on the IP address range from which the request originates.
aws:UserAgent: Allows or denies access based on the user agent string of the client application.
aws:PrincipalOrgID: Specifies the AWS Organizations ID of the account from which the request is made.
aws:FederatedProvider: Allows or denies access based on the federated identity provider used for authentication.
2. AWS Service-Specific Condition Keys: In addition to global condition keys, AWS also provides service-specific condition keys tailored to individual services. These keys allow you to define conditions specific to the service and resource you’re managing. For example, the Amazon S3 service has condition keys like s3:x-amz-acl and s3:prefix, which allow you to control access based on the access control list (ACL) and the object prefix, respectively.
Example IAM Policies with Condition Keys:
Allowing access based on date and time using aws:CurrentTime condition key:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-bucket",
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2023-05-01T00:00:00Z"
},
"DateLessThan": {
"aws:CurrentTime": "2023-05-31T23:59:59Z"
}
}
}
]
}In this example, the policy allows the s3:ListBucket action on the my-bucketS3 bucket, but only if the current time falls within the specified date range (May 1, 2023, to May 31, 2023).
2. Use case for aws:FederatedProvider condition key:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-bucket",
"Condition": {
"StringEquals": {
"aws:FederatedProvider": "Cognito"
}
}
}
]
}This policy allows the s3:ListBucket action on the my-bucket S3 bucket, but only if the request is authenticated using the Amazon Cognito federated identity provider. This condition key can be useful when you want to restrict access based on the identity provider used for authentication.
3. Use case for aws:CurrentTimecondition key:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-bucket",
"Condition": {
"IpAddressCondition": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
},
"DateCondition": {
"aws:CurrentTime": "aws:CurrentTime"
}
}
}
]
}In this example, the policy allows the s3:ListBucket action on the my-bucketS3 bucket, but only if the request originates from the specified IP address ranges (192.0.2.0/24 or 203.0.113.0/24) and if the current time falls within the specified time range (determined by the aws:CurrentTime condition key).
4. Restrict S3 bucket access based on source IP, user agent, and time range
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::my-secure-bucket",
"arn:aws:s3:::my-secure-bucket/*"
],
"Condition": {
"IpAddressCondition": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
},
"StringEqualsIgnoreCase": {
"aws:UserAgent": [
"Mozilla/5.0*",
"Chrome/*"
]
},
"DateTimeCondition": {
"aws:CurrentTime": [
"aws:CurrentTime"
]
}
}
}
]
}This policy allows the s3:ListBucket and s3:GetObject actions on the my-secure-bucket S3 bucket and its objects, but only if the following conditions are met:
The request originates from the specified IP address ranges (192.0.2.0/24 or 203.0.113.0/24).
The current time falls within the specified time range (determined by the aws:CurrentTime condition key).
5. Allow EC2 instance launch based on AMI ID, instance type, and AWS Organizations ID
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {
"ec2:ImageId": "ami-0abcdef1234567",
"ec2:InstanceType": "t2.micro"
},
"StringEquals": {
"aws:PrincipalOrgID": "o-1234567890abcdef"
}
}
}
]
}This policy allows the ec2:RunInstances action, which launches new EC2 instances, but only if the following conditions are met:
The Amazon Machine Image (AMI) ID used for the instance launch is “ami-0abcdef1234567”.
The instance type being launched is “t2.micro”.
The request originates from an account that belongs to the AWS Organizations ID “o-1234567890abcdef”.
6. Restrict Amazon RDS access based on source VPC and federated identity provider
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance",
"rds:ModifyDBInstance",
"rds:DeleteDBInstance"
],
"Resource": "arn:aws:rds:*:*:db:*",
"Condition": {
"StringEquals": {
"aws:SourceVpc": "vpc-0123456789abcdef"
},
"StringEquals": {
"aws:FederatedProvider": "Cognito"
}
}
}
]
}This policy allows the rds:CreateDBInstance, rds:ModifyDBInstance, and rds:DeleteDBInstance actions on Amazon RDS resources, but only if the following conditions are met:
The request originates from the specified Virtual Private Cloud (VPC) “vpc-0123456789abcdef”.
The request is authenticated using the Amazon Cognito federated identity provider.
7. Allow Amazon S3 object uploads based on object size and content type
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"NumericLessThanEquals": {
"s3:max-object-size": 104857600
},
"StringEqualsIgnoreCase": {
"s3:content-type": [
"image/jpeg",
"image/png",
"application/pdf"
]
}
}
}
]
}This policy allows the s3:PutObject action on objects in the my-bucket S3 bucket, but only if the following conditions are met:
The size of the uploaded object is less than or equal to 100 MB (104857600 bytes).
The content type of the uploaded object is either “image/jpeg”, “image/png”, or “application/pdf” (case-insensitive).
8. Allow AWS Lambda function execution based on source ARN and environment variable
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:*:*:function:my-function",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:events:*:*:rule/my-event-rule"
},
"StringEquals": {
"lambda:FunctionEnvironment:ENVIRONMENT_VARIABLE": "production"
}
}
}
]
}This policy allows the lambda:InvokeFunction action on the AWS Lambda function named "my-function", but only if the following conditions are met:
The request is initiated by the Amazon EventBridge rule with the ARN “arn:aws:events:::rule/my-event-rule”.
The environment variable ENVIRONMENT_VARIABLE for the Lambda function is set to "production".
These examples demonstrate the power and flexibility of condition keys in implementing complex access control rules based on various factors, such as source VPCs, federated identity providers, object sizes, content types, source ARNs, and environment variables. By combining multiple condition keys and leveraging their various operators and values, you can create highly tailored and secure policies that align with your organization’s specific requirements and security best practices.
Conclusion:
AWS condition keys are a powerful tool for implementing granular access control within your AWS environment. By leveraging global and service-specific condition keys, you can enforce precise conditions tailored to your organization’s security requirements. By understanding and utilizing condition keys effectively, you can enhance the security posture of your AWS resources and ensure that access is granted only under specific circumstances.
Comments