This article explains how Druva enables File-Level Restore (FLR) for your air-gapped EC2 instances directly into your own Amazon Web Services (AWS) account. This method bypasses the need for direct access to the EC2 instance, enhancing security and simplifying the recovery process.
Design Diagram:
The following diagram illustrates the workflow of Druva's EC2 airgap FLR:
Workflow Breakdown:
The FLR agent residing within air-gapped EC2 instance communicates with the Druva Cloud to initiate the restore process.
The Druva Cloud identifies the requested files for recovery.
A Druva Lambda function, operating within Druva's AWS account, retrieves the necessary data from the Druva Cloud.
The Lambda function compresses and prepares the restored content for writing to your AWS account.
Crucially, the Druva Lambda function then assumes a role within your AWS account. This role is configured with specific IAM permissions.
Using the assumed role's permissions, the Lambda function performs S3 operations to write the restored files into a designated S3 bucket within your AWS account.
Permissions Required for S3 Operation in Customer Account:
For Druva to successfully restore files to your S3 bucket, the IAM role assumed by the Druva Lambda function in your AWS account must possess the following permissions:
s3:CreateBucket: Allows Druva to create a new S3 bucket to store the restored content. This is typically a one-time operation performed during the first FLR job.
s3:PutObject: Grants permission to write (upload) the restored files into the specified S3 bucket.
s3:GetObject: Enables Druva to read metadata or perform checks on the bucket and objects if required during the restore process.
IAM Role and Bucket Policy:
When an S3 bucket is designated for FLR restores, it will have a resource-based bucket policy attached to it, granting Druva the necessary permissions to write the restored data.
For example, a bucket named druva-btdc-flr-UID might have the following policy attached, explicitly allowing the IAM role cr-prod-data-processing-role-ec2data-Role within the AWS account to interact with it:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "druva_cloud_mount_s3_permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AWSAccountID:role/cr-prod-data-processing-role-ec2data-Role"
},
"Action": [
"s3:Get*",
"s3:List*",
"s3:Put*"
],
"Resource": [
"arn:aws:s3:::druva-btdc-flr-UID/*",
"arn:aws:s3:::druva-btdc-flr-UID"
]
}
]This resource-based bucket policy grants the IAM role
arn:aws:iam::AWSAccountID:role/cr-prod-data-processing-role-ec2data-Rolethe permissions to perform all Get, List, and Put actions on the druva-btdc-flr-AccountID S3 bucket and its contents.This indicates that the Druva Lambda function, after assuming the cr-prod-data-processing-role-ec2data-Role, will have the necessary permissions to write (s3:PutObject included in s3:Put*) and read (s3:GetObject and s3:ListBucket included in s3:Get* and s3:List*) data within this specific S3 bucket.
IAM Role Created by CloudFormation which creates the S3 bucket for FLR:
During the initial onboarding of your AWS account with Druva, a CloudFormation template is deployed.
This template creates various IAM roles, including the cloudranger-orchestration role.
This role contains an S3 policy statement named s3steatements that grants Druva broader permissions for managing FLR, including the potential to create buckets and interact with druva-* named buckets:
S3statements policy:
{
"Statement": [
{
"Action": [
"s3:CreateBucket",
"S3:PutBucketAcl",
"S3:PutEncryptionConfiguration",
"S3:PutBucketPublicAccessBlock",
"S3:GetObject",
"S3:PutObject",
"S3:PutObjectAcl",
"s3:restoreObject",
"s3:PutBucketVersioning",
"s3:PutBucketTagging",
"S3:DeleteObject",
"S3:DeleteObjectVersion",
"s3:PutObjectTagging",
"S3:PutBucketObjectLockConfiguration",
"S3:PutBucketVersioning",
"S3:GetObjectAcl",
"S3:GetObjectVersion",
"S3:GetObjectVersionAcl",
"S3:GetObjectTagging",
"S3:HeadBucket",
"S3:HeadObject",
"S3:GetBucketObjectLockConfiguration",
"S3:GetBucketPublicAccessBlock",
"S3:GetBucketLocation",
"s3:PutBucketPolicy"
],
"Resource": [
"arn:aws:s3:::cloudranger-*",
"arn:aws:s3:::druva-*"
],
"Effect": "Allow"
},
{
"Action": [
"S3:ListBucket",
"S3:ListAllMyBuckets",
"S3:ListBucketVersions",
"S3:ListBucketByTags"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
Permissions Required for Users to Access the Restored Files:
Make sure the user/role trying to access the file has a policy that allows the GetObject action.
Also, ensure there’s not another policy (either identity-based attached to the user/role or resource-based like a bucket policy) with an explicit Deny that overrides an Allow.
Example of an IAM Policy for User Access:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::druva-*/*",
"arn:aws:s3:::druva-*"
]
}
]
}
Note: This policy grants permission to perform the s3:GetObject action on all objects within any S3 bucket starting with druva- in your account, as well as on the buckets themselves.
Best Practice and Permissions for Deleting Downloaded Files:
As a security best practice, after successfully downloading and verifying the restored zip file, it is recommended to delete the file from the S3 bucket to minimize storage costs and potential security risks associated with keeping temporary restore data.
To delete the files from the S3 bucket, the IAM principal (user or role) performing the deletion must have the s3:DeleteObject permission on the specific object(s) they intend to remove.
Example of an IAM Policy granting s3:DeleteObject permission:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:DeleteObject",
"Resource": [
"arn:aws:s3:::druva-*/*"
]
}
]
}