Securely installing AWS Replication Agent using AWS Security Token Service

UPDATE (7/7/2022): We’ve revised this blog post to align with the latest AWS security best practices. We’ve removed the step of adding an AWS Identity and Access Management (IAM) user, and replaced it with using an EC2 instance profile when the source server is an EC2 instance (the AWS Replication Agent also retrieves credentials automatically from the IAM role attached to the instance, without the need to enter them during installation), or with AWS Single Sign-On when the source server is on premises.

UPDATE (8/29/2022): We’ve revised this blog post to use the AWS Identify and Access Management (IAM) role AWSElasticDisasterRecoveryEC2InstancePolicy instead of AWSElasticDisasterRecoveryAgentInstallationPolicy for Amazon EC2 instances.

Establishing and maintaining a disaster recovery (DR) solution within the bounds of rigorous organizational security protocols and requirements is one key to a well-architected data-maintenance framework. The first step in a DR solution is setting it up, and having a secure method in place at the outset is critical. One way to securely implement your DR solution is to use temporary security credentials during set up, making it so that no long-term security clearance is provided, eliminating future unwanted incursions or tampering.

AWS Elastic Disaster Recovery (AWS DRS) is a block-level replication DR service that recovers on-premises or cloud-based applications to AWS with minimum downtime and data losses. Currently, AWS DRS is agent-based. This means there is a replication agent that must be installed on every source machine you replicate to AWS.

Using AWS Security Token Service (AWS STS), you can create and use or provide temporary security credentials that can control access to your AWS resources. Temporary security credentials work almost identically to the long-term access key credentials that your AWS Identity and Access Management (IAM) users can use, with two differences. First, they are short term, so they expire after a time that you configure. After they expire, AWS no longer recognizes them or allows any kind of access from API requests made with them. Second, they are not stored, but are generated dynamically and provided when requested.

In this blog post, I show you the best practices to install the AWS Replication Agent using temporary security credentials. I discuss two cases, the first one is when your source server is an Amazon Elastic Compute Cloud (EC2) instance, and the second case is when your source server is an on-premises server. The installation of each setup is a little different for each case, so let’s get started.

Source server is an Amazon EC2 instance

I start by creating an IAM role and attaching the necessary permissions to install the AWS DRS agent on my EC2 instance. I then attach the IAM role to the instance and install the agent. The AWS DRS Agent will automatically retrieve temporally credentials from the instance profile metadata. In this section, I walk through these steps.

1. Create an IAM role

In the IAM console, I choose Roles, then Create role.

Create an IAM role

For Selected trusted entity, I choose AWS service, and then I choose EC2 for Use case. Then select Next.

For Selected trusted entity, I choose AWS service, and then I choose EC2 for Use case. Then select Next.

In the next screen, I add permissions to the role. I search for the managed policy named AWSElasticDisasterRecoveryEC2InstancePolicy. This policy includes the permissions required to install the AWS DRS agent on Amazon EC2.

Adding permissions to the role

I don’t have to make any changes to the Trust relationship at this point so I keep it as is.

2. Attach IAM role to the source server

I will now attach the IAM role (DRS-Role) to the source server. To do so, I select the EC2 instance where I want to install the agent. I choose Actions, Security, and then Modify IAM Role. I then choose DRS-Role and select Update IAM role.

I choose Actions, Security, and then Modify IAM Role. I then choose DRS-Role and select Update IAM role.

When I install the agent, it asks me to specify the AWS Region for my DR site, and then it starts the installation process automatically without asking to manually specify the credentials.

During agent installation - specify the AWS Region for my DR site, and then it starts the installation process automatically without further credentials

Source server is an on-premises server

If you’re source server is not on AWS (i.e. physical or virtual server on premises), then you need to create an IAM role with the necessary permissions and then assume that role from the on-premises server. I’m using AWS Single Sign-On (AWS SSO), a service that enables you to quickly and easily assign and manage your on-premises employees’ access to multiple AWS accounts, for my identity management. For the purpose of this walkthrough, I created an AWS SSO user (drs-sso-user) that simulates an on-premise user. For your production scenario, you can create users directly in AWS SSO, or you can bring your users from existing identity sources like Microsoft Active Directory, Okta Universal Directory or any another supported Idp. Check for more details here.

This is the workflow for installing the AWS Replication Agent using AWS SSO:

On AWS, enable AWS SSO and create users.
On the source server, configure AWS SSO and login.
On the source server, assume the role, generate temporary credentials and install the agent.

1. On AWS, enable SSO and create users

I connect to my AWS Account and select AWS Region (US-East-2). I follow the steps in the documentation on enabling AWS SSO to enable AWS SSO in my account. I choose AWS SSO as my identity store. After completing this step, a user portal URL will be created for my users. I take a note of it, as I will need it in a later step.

I follow the steps in the documentation on enabling AWS SSO to enable AWS SSO in my account. I choose AWS SSO as my identity store.

Now I need to create a user (drs-sso-user) to simulate an employee for my on-premises environment. I follow the steps in the documentation on adding users.

Now I need to create a user (drs-sso-user) to simulate an employee for my on-premises environment. I follow the steps in the documentation on adding users.

Next, I need to create a permission set for my user. I choose a custom permissions set and select AWSElasticDisasterRecoveryAgentInstallationPolicy for the permissions. I then give the permission set a name (DRS-PermissionSet).

I choose a custom permissions set and select AWSElasticDisasterRecoveryAgentInstallationPolicy for the permissions.

After completing this step, I select AWS Account in the AWS SSO console and grant the users SSO access to my AWS Account. The following is how my permissions set looks:

I select AWS Account in the AWS SSO console and grant the users SSO access to my AWS Account

2. Authenticate AWS SSO user on the source server

Before I can use drs-sso-user on the source server, I need to add the AWS SSO profile to my AWS Command Line Interface (AWS CLI). I connect to the source server and run the aws configure sso command . The prompt will ask me to provide the following:

SSO Start URL: I provide the URL I created in the screenshot under step 1 in this section.
SSO Region : US-EAST-2

Then prompt shows me the AWS Account and the permissions set I configured in the first step. I confirm that I want my user to have that access, and I give the profile a name (drs-profile). I need to use this profile when I assume the role later.

Authenticate AWS SSO user on source server

Next I run the aws sts get-caller-identity command to quickly confirm that I’m logged in using my AWS SSO user.

3. Assume the role, generate temporary credentials, and install the agent

For the purpose of this walkthrough, I’m going to use the same role I created in the first step of the first section of this blog (DRS-Role). Before my AWS SSO users can assume this role and generate the temporary credentials using AWS STS necessary to install the AWS Replication agent, I need to adjust the principal part of the trust policy to allow the AWS SSO user to assume the role. We recommend that you allow the permissions to install the agent for the IAM role and not for a specific user.

To do so, I go to the IAM console and find the role (DRS-Role), then I go to the Trust relationships tab and select Edit trust policy. In the policy, I locate the Principal section and add the ARN for the DRS-Role: arn:aws:iam::548169619584:role/DRS-Role.

Preceding the edit:

Before the edit

Following the edit:

In the policy, I locate the Principal section and add the ARN for the DRS-Role

Now I’m ready to assume DRS-Role, so I run the following command:

Aws sts assume-role –role-arn arn:aws:iam:: 548169619584:role/DRS-Role AgentInstallRole –role-session-name drs-session --profile drs-profile

I take a note of the AccessKeyId, SecretAccessKey and SessionToken.

Running the command to assume the DRS-Role

I download AWS ReplicationAgnet and run it. It asks me to provide the temporary credentials I generated in the previous screen. I enter the credential’s and continue with the installation process. Check the documentation for details on AWS Replication Agent installation instructions.

AWS Replication agent successfuly installed - take note of accesskeyid, secretaccesskey, and session

Cleaning up

After you successfully finish the installation of the AWS Replication Agent, it will start the replication process and it create Amazon EBS Snapshots. To avoid incurring unwanted AWS costs, make sure that you delete all AWS resources that are created as part of this demonstration. That includes the source EC2 instance and EBS snapshots.

Conclusion

In this blog post, I walked you through using temporary credentials provided by IAM roles instead of long-term credentials provided by IAM users while installing the AWS DRS Replication Agent. I discussed two cases, the first using an EC2 instance profile to attach an IAM role to the source server, and the second using AWS SSO to install the agent on an on-premises server. We used AWS SSO identity store to simulate on-premises identity providers. I then created an IAM role, assumed the role by the AWS SSO user, generated temporary credentials, and completed the AWS Replication Agent installation. This is the recommended way to install the AWS Replication Agent, because the security keys are temporary and you don’t have to rotate or revoke them when you finish the installation.

Thanks for reading this blog! If you have any comments or questions, you can add them in the comments section.