AWS Storage Blog

Enhancing resource-level permission for creating an Amazon EBS volume from a snapshot

Businesses use Amazon Elastic Block Store (Amazon EBS) snapshots to capture point-in-time copies of application data volumes that can serve as baseline standards when creating new volumes. This enables them to quickly launch application workloads in different AWS Regions or meet data protection and disaster recovery requirements. Security and regulatory compliance remain top priorities as users migrate their AWS workloads across different AWS Regions and accounts, with a common request being resource-level permissions for API calls to enable granular access control.

Today, Amazon EBS announces enhanced resource-level permissions for the CreateVolume action, allowing users to specify additional resource-level authorization in their AWS Identity and Access Management (IAM) policies for source snapshots when creating volumes. This enhancement helps users control which IAM identities can create EBS volumes from source snapshots and define the conditions under which these snapshots can be used to create EBS volumes.

In this post, we outline the changes to resource-level permission, explore use cases for their implementation, and discuss the importance of adopting this improved permission model. We also provide a transition plan for you to migrate from the previous resource-level authorization model.

What is changing? 

When creating or restoring a volume from a source snapshot, you need to use an IAM policy to grant permissions to perform the CreateVolume action. Previously, the CreateVolume action in your IAM policy needed authorization for the volume getting created, and the source snapshot was not part of the resource context of the CreateVolume action in your IAM policy. With this change, you can now enforce resource-level permissions for both the volume getting created and the source snapshot. To meet your specific permission requirements on the source snapshots, you can also use any of these five Amazon Elastic Compute Cloud (Amazon EC2)-specific condition keys: ec2:Encrypted, ec2:VolumeSize, ec2:Owner, ec2:ParentVolume, and ec2:SnapshotTime. Furthermore, you can use global condition keys for the source snapshot in your IAM policy. If you have already added a resource statement using an Amazon Resource Name (ARN) for the volumes being created, then you must also explicitly specify a resource statement for your snapshot. Observe the following.

Previous policy: 

A policy that allows the volume resource being created was needed.

{
    "Effect": "Allow",
    "Action": "ec2:CreateVolume",
    "Resource": "arn:aws:ec2:*:*:volume/*"
}
JSON

Policy required after this change:

A policy that allows both the volume and source snapshot resources is now needed.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:CreateVolume",
            "Resource": "arn:aws:ec2:*:*:volume/*"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:CreateVolume",
            "Resource": "arn:aws:ec2:*:*:snapshot/*"
        }
    ]
}
JSON

What can you do with additional resource-level permission for source snapshots?

Transitioning to the new resource-level permission model offers two benefits:

1/ Enhanced granularity in access control

Resource-level permissions for source snapshots provide you with fine-grained control over which snapshots can be used to create volumes. Specifying conditions allows you to set permissions for individual snapshots or categories of snapshots. For example, if your organization takes EBS snapshots as regular backups of workloads containing sensitive data owned by a specific AWS account, then with this new permission model you can restrict the creation of volumes to snapshots owned by authorized users.

Policy examples:

1. Only allow the creation of volumes from snapshots that belong to my organization.

{
    "Effect": "Allow",
    "Action": "ec2:CreateVolume",
    "Resource": [
        "arn:aws:ec2:*:*:volume/*",
        "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0"
    ],
    "Condition": {
        "StringEquals": {
            "aws:ResourceOrgId": "<your organization ID>"
        }
    }
}
JSON

2. Only allow the creation of volumes from snapshots that belong to my account.

{
    "Effect": "Allow",
    "Action": "ec2:CreateVolume",
    "Resource": [
        "arn:aws:ec2:*:*:volume/*",
        "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0"
    ],
    "Condition": {
        "StringEquals": {
            "aws:ResourceAccount": "<your account ID>"
        }
    }
}
JSON

3. Only allow the creation of volumes from snapshots with a specific tag.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:CreateVolume",
            "Resource": [
                "arn:aws:ec2:*::snapshot/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/classification": "not-sensitive",
                    "aws:ResourceOrgId": "<your organization ID>"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "ec2:CreateVolume",
            "Resource": "arn:aws:ec2:*:*:volume/*"
        }
    ]
}
JSON

2/Resource and cost optimization

This additional permission not only enhances your security and compliance requirements but also provides a powerful tool for resource prioritization and cost optimization. Specifying conditions such as snapshot age or encryption status allows you to control which snapshots are prioritized for creating volumes. For example, you can make sure that more recent or encrypted snapshots are prioritized over others. This can help streamline your backup strategy, such as restoring a volume in a secondary Region, while aligning resource usage with your business priorities.

Policy examples:

1. Only allow the creation of volumes from encrypted snapshots.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:CreateVolume",
      "Resource": [
        "arn:aws:ec2:*::snapshot/*"
      ],
      "Condition": {
        "Bool": {
          "ec2:Encrypted": "true"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ec2:CreateVolume",
      "Resource": "arn:aws:ec2:*:*:volume/*"
    }
  ]
}
JSON

2. Only allow the creation of volumes from snapshots taken after 2025-01-01 00:00:00.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:CreateVolume",
            "Resource": [
                "arn:aws:ec2:*::snapshot/*"
            ],
            "Condition": {
                "DateGreaterThan": {
                    "ec2:SnapshotTime": "2025-01-01T00:00:00Z"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "ec2:CreateVolume",
            "Resource": "arn:aws:ec2:*:*:volume/*"
        }
    ]
}
JSON

How do I prepare for the change?

Most AWS users aren’t impacted by this update. We have notified you by email and through your AWS Health Dashboard if we detected that you have a policy that would be impacted by this change. Impacted accounts are currently allowlisted, and your previous policy will remain in place until February 17, 2025. On February 17, 2025, AWS will start removing accounts from the allowlist as you update your IAM policies with May 17, 2025 being the final deadline for all accounts to migrate to the new permission model. After May 17, 2025, your requests to invoke CreateVolume API may be denied if you have not taken any action to update your policy.

Timeline:

  • February 17, 2025: AWS begins removing accounts from the allowlist, starting with users who have updated your IAM policies.
  • May 17, 2025: Final deadline for all accounts to migrate to the new permission model.

Identifying and updating impacted policies:

You can review your AWS CloudTrail logs or run the IAM get-account-authorization-details CLI command to list all IAM policies, such as CreateVolume actions to identify the relevant policies. In general, policies needing updates fall into the following two categories.

Category 1: You do not have an allow statement for a snapshot resource.
If your policy’s Resource element only matched volumes, then you need to allow the snapshot resource as well. Observe the code example.

{
    "Effect": "Allow",
    "Action": "ec2:CreateVolume",
    "Resource": "arn:aws:ec2:*:*:volume/*"
}
JSON

The updated code block would become the following.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:CreateVolume",
      "Resource": "arn:aws:ec2:*:*:volume/*"
    },
    {
      "Effect": "Allow",
      "Action": "ec2:CreateVolume",
      "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0"
    }
  ]
}
JSON

An example of a similar AWS managed policy is the AWSElasticDisasterRecoveryServiceRolePolicy.

Category 2: Your resource element allows both volumes and snapshots, but your condition only applies to a volume.
If your policy’s Resource element uses a wildcard to match both volumes and snapshots and includes Condition elements that are specific to a volume, then you must modify the Resource element to apply only to volumes and add a new statement to authorize snapshots.

Here is an example of a previous policy that will not work after this change.

{
    "Effect": "Allow",
    "Action": "ec2:CreateVolume",
    "Resource": "*",
    "Condition": {
        "StringLike": {
            "aws:RequestTag/CSIVolumeName": "*"
        }
    }
}
JSON

To update the policy and make it work, it would become the following.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:CreateVolume",
      "Resource": "arn:aws:ec2:*:*:volume/*",
      "Condition": {
        "StringLike": {
          "aws:RequestTag/CSIVolumeName": "*"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ec2:CreateVolume",
      "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0"
    }
  ]
}
JSON

An example of a similar AWS managed policy is the AmazonEBSCSIDriverPolicy.

Validating updates using DryRun mode

If you need to validate that your IAM policies are correct, then use the DryRun mode to test that your changes to IAM policies are correct. The DryRun mode allows you to see the authorization result under the new permission model even if your actual APIs are allowlisted to use the old permission model. To use DryRun, specify the -dry-run parameter in AWS Command Line Interface (AWS CLI) commands or Amazon EBS CreateVolume API calls. Your CreateVolume API calls that use DryRun always returns an error response. If you receive an error with DryRunOperation, then this means your policy works with the new permission model. If you receive an error with UnauthorizedOperation, then you must make an update on your IAM policies. Refer to the CLI documentation to find out more about the DryRun mode.

Conclusion

The updated resource-level permissions enhance security, control, and operational flexibility. If you currently use the old permission model and need to continue to do so, then you can reach out to AWS Support to seek an accommodation of your use case. If you are ready to migrate to the new permission policy before February 17, 2025, then you can also ask AWS Support to remove you from the allow-list. This change is part of a broader initiative to enable similar permissions for other actions such as CopySnapshot.

For more details about the supported condition keys, please visit the documentation. If you have feedback about this post, then submit it in the comments section or contact AWS Support. To learn more about Amazon EBS volumes and Snapshots, visit the Amazon EBS user guide.

Emma Fu

Emma Fu

Emma Fu is a Senior Technical Product Manager with the Amazon EBS team. She is passionate about exploring emerging use cases in Backup, Security and AI. Outside of work, she enjoys spending time with her family, cooking, and wine tasting.

Matt Luttrell

Matt Luttrell

Matt is a Principal Solutions Architect on the AWS Identity Solutions team. When he’s not spending time chasing his kids around, he enjoys skiing, cycling, and the occasional video game.