Issues using an AWS Managed key (aws/backup) and trying to restore

This behavior is expected when restoring an Amazon EFS backup that was encrypted with the AWS managed key aws/backup. The aws/backup key is owned and managed entirely by AWS Backup and is only used for encrypting backup vault data. It isn't accessible to other services like EFS during a restore, which is why the key policy can’t be modified to include EFS as a principal. When you restore an EFS recovery point, AWS Backup decrypts the data using aws/backup and re-encrypts it with a key that EFS can use. To complete the restore, specify a valid EFS encryption key in your restore job—either the AWS-managed key aws/elasticfilesystem or a customer-managed KMS key that you control. —Taz

When restoring an EFS file system that was backed up using the AWS managed key (aws/backup), you may encounter permission issues because the restore process requires specific KMS key permissions.

To resolve this issue, you need to ensure your restore role has the proper permissions to access the KMS key. Here's what you should do:

1. Add the following AWS KMS permissions to your IAM restore role's policy:

{
"Effect": "Allow",
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:REGION:ACCOUNT-ID:key/KEY-ID"
]
}

2. Update the KMS key policy to allow the restore role access:

{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT-ID:role/RESTORE-ROLE-NAME"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:CreateGrant"
],
"Resource": "*"
}

3. Also ensure your IAM role has the necessary EFS permissions:

• elasticfilesystem:Restore
• elasticfilesystem:CreateFilesystem
• elasticfilesystem:DescribeFilesystems
• elasticfilesystem:DeleteFilesystem

4. Make sure your IAM role has the iam:PassRole permission, which is often required when you encounter "insufficient privileges" errors during EFS restores.

If you're using an AWS managed key, you cannot directly modify its policy. In this case, you might need to create your own customer managed key with the appropriate permissions for both backup and restore operations, then use that key for your EFS backups going forward.
Sources
Troubleshoot EFS file system restore issues for AWS Backup | AWS re:Post
Troubleshoot failed AWS Backup restore testing plans | AWS re:Post
Unable to restore EFS | AWS re:Post

Recovery points using the aws/backup key can only be restored via AWS Backup, not directly via the underlying service, such as EFS. Have you tried restoring the backup via the AWS Backup service? The procedure is explained in detail on this documentation page: https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-efs.html

If the procedure isn't working, then the problem is almost certainly with relevant permissions being missing from the self-managed IAM role that you are using to tell AWS Backup to restore the file system. You can see KMS permission errors within 5 minutes of them occurring in the CloudTrail logs in the region hosting the backup vault and KMS key.

My Command looks like this:

aws backup start-restore-job \
  --region us-gov-west-1 \
  --recovery-point-arn "arn:aws-us-gov:backup:us-gov-west-1:***********:recovery-point:<<recover_point_id>>" \
  --iam-role-arn "arn:aws-us-gov:iam::***********:role/efs-backup-role" \
  --metadata '{
    "file-system-id": "fs-12345678",
    "newFileSystem": "true",
    "CreationToken": "logs-efs",
    "Encrypted": "true",
    "KmsKeyId": "<<key_id>>",
    "PerformanceMode": "generalPurpose"
  }'

And my policy looks like this:

        {
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey",
                "kms:CreateGrant"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },

And the error is:

Error while completing request: You do not have permission to use the specified KMS key. [error=AccessDeniedException] (Service: AmazonElasticFileSystem; Status Code: 400; Error Code: BadRequest; Request ID: 81632c49-4686-41d6-b23f-c9bae8a1e95d; Proxy: null)

My policy is wide open. I cant change the KMS Key Policy because it is a AWS Managed Key.

Which KMS key are you specifying in the metadata attribute "KmsKeyId": "<<key_id>>"? Is it the aws/elasticfilesystem key or aws/backup?

aws/backup

The aws/backup key can only be used by AWS Backup, not by the newly created EFS file system.

I'd generally recommend creating a customer-managed key for EFS and setting the new file system to use it. A customer-managed key supports cross-account access and various advanced access control scenarios, which aren't possible with AWS-managed keys.

If you want to avoid the monthly charge of $1 for a customer-managed key or prefer to use an AWS-managed key for other reasons, such as that it cannot be destroyed or disabled accidentally, the AWS-managed key you can use with EFS is the key with the alias aws/elasticfilesystem.

Thanks Leo,

While I appreciate your help, I already knew that I needed a CMK. The issue here is that I am using an AWS Managed Key, which should be perfectly acceptable in these cases. My understanding of CMK's is that they are needed when someone wants control of the key. That isn't the case with us - we just need the encryption. I am surprised that I can't restore this data. Backup allows me to restore to a new EFS, but the key provided by AWS to use for Backup does not have sufficient permissions to actually do the restore. I've already worked around this issue (created a new, empty EFS and will pull data from the older one as needed)

This feels like a miss by AWS, so this is a bug report. But since I don't pay for support, as I don't often need the assistance to justify the cost, I am posting it here. Hopefully they will see it

Thanks again.

Ah, I understand now. The KeyId in the meta data is for encryption TO the EFS, not the decryption FROM the backup.

Thanks a bunch.