Blog AWS Continuous Compliance
Last updated on March 1st, 2023 at 9:30am
AWS CalledVia conditions for Identify and Access Management (IAM) are some of the new conditions AWS just released that are based on the various AWS services through which actions are taken. These powerful new conditions can make a big impact in furthering your organizational guardrails and enforcing policy via IAM.
AWS Global Conditions is an AWS feature that allows users to define reusable condition expressions, which can then be used in policies to evaluate whether an AWS resource should be granted access or not. These conditions can be used in various AWS services, such as IAM, Key Management Service (KMS), and Amazon S3 bucket policies.
By using Global Conditions, AWS users can centralize the management of their access policies and improve their security posture by enforcing consistent, fine-grained access controls across their AWS resources. This feature can also help to simplify policy management by allowing users to reuse the same conditions across multiple policies, reducing the potential for errors and making policy updates easier to manage.
The aws:ViaAWSService condition is a boolean condition that you can use to allow or disallow actions based on whether or not the action was called via an AWS service. This is very useful when a principal (an IAM user or role) takes an action and, as a result, subsequent actions are taken on behalf of the principal by various AWS services.
There are also three new related AWS CalledVia conditions: aws:CalledVia, aws:CalledViaFirst, and aws:CalledViaLast. These new conditions allow you to specify conditions on your IAM policies based on the AWS service from which the principal made a request. For chained requests, the CalledViaFirst resolves to the first service in a chained request, and the CalledViaLast condition is the last. AWS documentation includes a great image that shows how these values change through a chained call.
Currently, the CalledVia supports 4 service principals; Athena, CloudFormation, DynamoDB, and KMS.
There are a ton of awesome use cases for these new conditions. We’ll highlight two below:
- Enforce infrastructure as code by limiting the ability to create/modify/delete EC2 resources unless they are deployed via CloudFormation
- Prevent access to AWS services unless from a trusted IP range
Enforcing Infrastructure As Code
Enforcing infrastructure as code is an important aspect of a well-managed cloud. Previously, it was impossible to enforce this using IAM policies. Now, this is really easy!
Say you have three environments: development, staging, and production. It’s a best practice to increase your security as you move towards production. If you want to deploy and manage your application in production using CloudFormation (infrastructure as code), you need to make sure your engineers can do that testing in staging using CloudFormation without having modify access to the resources directly. By enforcing this policy, you can be confident engineers won’t make changes outside of CloudFormation to get the application to run properly in staging, but they can view logs and double-check configurations.
It’s now possible in staging and production to limit users to only deploy using CloudFormation templates without access to the resources themselves by applying an IAM policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ForceInfrastructureAsCode",
"NotAction": [
"ec2:Get*",
"ec2:Describe*",
"cloudformation:*",
"s3:Put*",
"iam:Describe*",
"iam:List*",
"iam:Get*"
],
"Effect": "Deny",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:CalledViaFirst": "cloudformation.amazonaws.com"
}
}
}
]
}
For testing this policy, you can pair the ForceInfrastructureAsCode with the Administrator managed policy that AWS offers.
The ForceInfrastructureAsCode policy leverages the Deny and NotAction components to not interfere with other policies that are attached to a user or principal. Because IAM policy evaluation begins with “What is denied”, the effect will supersede any other actions that are allowed. In the NotAction section, the policy allows principals to browse ec2 resources via the ec2:Get* and ec2:Describe*. We’re also allowing broad CloudFormation permissions to be able to create, delete, and update stacks. Finally, we include s3:Put and IAM read actions to support the usage of CloudFormation via the console.
With this combination of policies on a principal, when a user goes to create an EC2 instance in the AWS console, they’ll get denied as they aren’t using CloudFormation. However, if you go to create that same resource using CloudFormation, you’ll get a success.
As mentioned, the aws:ViaAWSService is a boolean operator that checks whether an AWS services is making a request on behalf of a principal.
Only Allow Access from Approved IP Addresses
The next use case is in situations where you need to force IP restrictions on users. Previously, if you tried to enforce an IP restriction using the “aws:SourceIp” condition, services like Elastic Beanstalk environment would fail because first call would originate from the principal’s IP, but subsequent calls would originate from within AWS, which is denied. Until now, the recommended approach was to instruct a user to access AWS from an approved IP and then have them use the AssumeRole call to access another role with permissions. It was a more difficult workflow to explain to engineers and caused confusion, which could result in misconfiguration.
Using the new aws:ViaAWSService condition below can help solve this problem.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition":
{
"NotIpAddress": {
"aws:SourceIp": [
"192.168.21.55/32"
]
},
"Bool": {
"aws:ViaAWSService": "false"
}
}
}
}
Using this policy, users are forced to come from an approved IP while still being able to leverage services liked Elastic Beanstack and CloudFormation.
AWS CalledVia helps enforce the principle of least privilege by allowing users to restrict access to specific sources, such as certain IP addresses or AWS accounts, by configuring their security policies to only allow requests that are called via authorized sources. This can help to reduce the risk of unauthorized access, data breaches, and other security incidents. This feature is particularly valuable for security operations teams and compliance, as it provides an additional layer of protection for AWS resources and helps to simplify policy management by allowing policies to be applied consistently across all services.
AWS continues to innovate and provide new features around IAM; which is the most critical (and complicated) security component in the platform. These IAM policies are available today as organizational guardrails, and you can implement them in your organization via a cloudtamer.io Cloud Rule!
If you'd like to see how easy it is to use the new AWS IAM CalledVia conditions for these and other use cases in your organization, please reach out to our team.
