Using Permissions to Unlock Resilience with AWS Resilience Hub

AWS customers come to AWS Resilience Hub for the ability to assess their application against their Recovery Time Objectives (RTO), the maximum acceptable time an application can be in a disrupted state, and Recovery Point Objectives (RPO), the maximum amount of data that can be lost due to disruption. Although customers come for the assessment capabilities, customers stay for the recommendations and operational tools available on Resilience Hub to take the mystery out of managing an application’s resilience posture. A key component in maximizing the value of Resilience Hub is ensuring that permissions are setup to allow for regularly assessing applications by opting into notifications with drift detection or integrating resilience assessments into a CI/CD pipeline. As Resilience Hub continues to expand the AWS services that are assessable, application architectures change, and new functionality is provided, we find customers using the managed policy from Resilience Hub get the most value.

We have updated our permissions design to provide customers with flexibility in configuration of AWS Identity and Access Management (IAM) roles for use with Resilience Hub. The design provides the ability to select a pre-provisioned role within your organization to use with Resilience Hub on the application you are assessing. Additionally, we have rolled out a managed policy which will allow customers to have the most accurate and up-to-date permissions for the services that Resilience Hub supports. Resilience Hub will also continue to support customers with manual configurations who are comfortable with their existing permissions setup.

In this blog, we will show you how to leverage the permissions options available to you in Resilience Hub, and will focus on permissions that grant Resilience Hub the ability to read resources relevant to the resilience of your application. In addition, we will review some services that require additional permissions beyond Resilience Hub. This blog assumes that user has permissions to access Resilience Hub, and that your organization does not have any service control policies that would override the access covered in this blog.

Account Access

There are numerous ways you can define your application in Resilience Hub, including defining your application in a single AWS account or across multiple accounts. Depending on how you have configured your AWS applications and Resilience Hub, there are two account iterations you should consider when determining your permissions strategy with Resilience Hub:

• Primary account – The account in which Resilience Hub is configured, and potentially where the resources associated to your application reside. In the case that Resilience Hub and all application resources reside within a single account, you will only need to configure permissions for this account.
• Secondary/Cross account (optional) – A secondary or cross account is going to be an account that contains the resources associated with your application, but not the account that Resilience Hub is configured within. In this scenario, you will need to make sure you have the appropriate roles in both the primary account, as well as the secondary account(s).

Permissions Setup on Resilience Hub

When onboarding an application to Resilience Hub, you are required to select the permissions configuration that best suits your needs based on your organization’s permissions policies and how your application is deployed within your accounts. In order to onboard an application to Resilience Hub, we will use the permissions of the user/role you are currently logged into the AWS console. To create or update applications on Resilience Hub, it is required to have iam:passRole permission.

Every application onboarded to Resilience Hub can be configured to use the Invoker role (an IAM role), or use the current IAM user permissions. If using the current IAM user permissions, you will need to include a set of predefined roles for cross-account and drift detection. Regardless of whether you use the permissions of the user you log into the console with or another role available to you, it is recommended you include the Resilience Hub managed policy in the permissions.

Managed Policy

An AWS managed policy is a standalone policy that is created and administered by AWS. For Resilience Hub, this policy is AWSResilienceHubAsssessmentExecutionPolicy. The benefit of associating an AWS managed policy to your role or user is that permissions are provided for many common use cases, and the policy is automatically updated when additional functionality is made available.

• There are two key benefits of using role with an AWS managed policy.
  1. As new services are supported on Resilience Hub, the permissions to assess applications that contain resources related to that service will be automatically made available to you.
  2. As you expand usage of Resilience Hub to include functionality like drift detection or integration into a CI/CD pipeline, you can be confident that the correct permissions are in place.
• If your organization wants the efficiency of a managed policy, but has concerns about access to certain resources, you can add a policy to override access to the resources that are of concern.
  1. Resilience Hub requires read-only access in order to assess your application, and must have this access in order to provide accurate assessments and recommendations.
  2. You can limit the managed policy to remove specific permissions that are not consistent with your organization’s policies, or limit the permission scope to specific resources.
     • If you limit the managed policy, it may impact your ability to assess applications.
     • We suggest you add a “deny” policy to work with the managed policy in order to get the benefit of the managed policy while also staying compliant with your organization’s policies.
     • An example of a “deny” policy can be found below, where Resilience Hub is denied the ability to access any resources in the AWS Backup service.
       
     • Changes made to the managed policy are documented here.

Below we will go through creation of a role, which includes the managed policy for Resilience Hub.

Default: “Use an IAM role”

When selecting this option, Resilience Hub will populate all roles available to the user to select from in the dropdown, “Select an IAM role”, which include resiliencehub.amazon.com in the trust policy; a trust policy is where you define the principals that you trust to assume the role, here you can find more information about trust policy for IAM. If you don’t see the role you’re looking for in the dropdown menu, ensure you’ve followed the steps below:

• In order for the role to appear in the dropdown menu, make sure resiliencehub.amazon.com is included in the trust policy for your application.
• We require that the user you are logged in with has the ability to ListRoles, which allows Resilience Hub to pull a list of the roles that match the criteria above
  • If you do not have ListRoles permission for the user/role you are logged in with and have a role that you would like to manually enter, we provide the ability to enter the role name

Let’s review the key items we recommend to include in the role or user permissions in order to get the most out of Resilience Hub:

• The role should include the AWSResilienceHubAssessmentExecutionPolicy, which is the managed policy that ensures permissions are configured correctly.
• The role should be created using the guidance to create an InvokerRole, when creating a role for AWS Resilience Hub.

Optional: “Add cross account IAM role(s) ARN” is applicable if you have an application that has resources in another account which Resilience Hub will need the ability to read. Resilience Hub requires permission to access the resources in the other accounts, which can be accomplished through the following two options:

• Provide a list of custom cross account role ARNs, which will be used to access resources in the associated account. When providing Resilience Hub with a list of cross account role ARNs, Resilience Hub will use role chaining to access resources located in the associated account. This is done by assuming the matching IAM role using the InvokerRole. When using this option, you must ensure that you provided a matching IAM role from each account in which your application resources are defined.
• If you do not provide any cross account role ARNs, then Resilience Hub will assume an IAM role with the same name as the InvokerRole exists in the cross account, and will use role chaining to assume the matching IAM role in the cross account using the InvokerRole.

Optional: “Use the current IAM user permissions”

When selecting this option, Resilience Hub will use the current IAM user to access your application’s resources. It is important that you ensure the user has the appropriate permissions configured to have read access to all supported resources within your application. In this scenario, we recommend to include the managed policy. The Resilience Hub User Guide provides additional information on configuring your permissions using this method. When your resources are in a different account, we will need to assume the following IAM roles in order to access the application:

• AwsResilienceHubAdminAccountRole in the current account
• AwsResilienceHubExecutorAccountRole in other accounts

In order to use drift detection, a feature when enabled requires Resilience Hub to run daily assessments on your application, Resilience Hub must also be able to assume the AwsResilienceHubPeriodicAssessmentRole role. If you are manually running assessments on Resilience Hub, this permission is not required.

Although Resilience Hub recommends using the managed policy, depending on where you are in your Resilience Hub adoption, there are a couple of benefits of using this option:

• Testing out Resilience Hub to see if the service is appropriate for your use case. Before setting up permissions, you may want to run a simple application to get a feel for the product.
• If you are logged in as an administrator, you will be able to leverage the inherent permissions associated with that login.

Similar to the role above that does not have the AWS managed policy associated to it, you will need to manually update permissions any time new services or functionality are released. Due to this manual requirement, Resilience Hub highly suggests associating the AWS managed policy to the role you use for Resilience Hub.

Creating Role with AWS Managed Policy

Resilience Hub now supports associating the AWS managed policy, AWSResilienceHubAssessmentExecutionPolicy, to the role you use for Resilience Hub. Once you have associated the managed policy to the role, Resilience Hub will automatically update the permissions of the managed policy when new services or functionality are made available.

Below we will review creation using the AWS console, but if you create your roles outside of the AWS console see Creating a role for an AWS service in the IAM User Guide.

Creating a role in your primary account

• Open the IAM console at https://console.aws.amazon.com/iam/.
• Navigate to Roles and choose Create role.
• Choose Custom Trust Policy, copy the trust policy in Primary account tab, paste it in the Custom Trust Policy window, and then choose Next.
  • Use the following information to edit the Trust Policy:

    {
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Principal": {
                "Service": "resiliencehub.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }]
    }

In the Add permissions page, search for AWSResilienceHubAsssessmentExecutionPolicy, select the policy, and then choose Next.

• Enter a Unique role name, such as arhRole, and choose Create role.
  • We recommend naming the role something that clearly defines its association with the policy. This will make it easier to identify which role will meet your needs from the dropdown provided.

Once you have created the role through IAM, you will then be able to select this policy within Resilience Hub.

• For new applications, the role will be available through the Setup permissions container in the application onboarding wizard
  • If you have Resilience Hub open in the console when creating the role, you may need to use the refresh button for the role to become available to be selected.
• To update your permissions for existing applications within Resilience Hub:
  • Go to https://console.aws.amazon.com/resiliencehub/
  • Select Applications page, and select applicable application
  • Go to Actions in top right corner and select Update permissions

Creating a role in a secondary account

The creation of a role in additional accounts will follow a similar process as above, except you will need to use the Secondary Account trust policy. Additionally, if your resources are in different accounts, you will have to create a role in each of those accounts using the trust policy below.

Secondary/additional account trust policy:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::PRIMARY_ACCOUNT_ID:role/PRIMARY_ACCOUNT_ROLE"
        },
        "Action": "sts:AssumeRole"
    }]
}

Once the role has been created for the secondary account, you will need to add the ARN into the Add cross account IAM role(s) ARN field. If both accounts use the same role name, then you do not need to update the application, as Resilience Hub will assume a role with the name of the InvokerRole in the secondary account. You can find the ARN in the Summary page of the IAM console for the role you created above:

Here is an example of what a primary and secondary account setup may look like:

Related Services

Resilience Hub partners with other AWS services in order to provide some functionality offered within the product. In these scenarios, it is important to configure the permissions within that service in order to allow Resilience Hub to function correctly. Below are the three most common permissions that need to be configured outside of Resilience Hub:

Drift Detection Notifications

Resilience Hub uses Amazon Simple Notification System (SNS) topics in order to provide notification when your application is no longer meeting the recovery objectives you defined within the resiliency policy. To enable Resilience Hub to publish notifications to your SNS topic, you must update the access policy of the SNS topic to AllowResilienceHubPublish. The Resilience Hub User Guide provides additional information on configuring your permissions for drift detection notifications.

Application Definition using Terraform State Files

Resilience Hub provides the option for customers to define their application using Terraform state files. The option to define your application using Terraform state files is to provide the Infrastructure as Code (IaC) is by storing the state files in an Amazon S3 bucket within one of your AWS accounts. It is required that you provide read access to Resilience Hub to the S3 bucket. If your files are encrypted using AWS Key Management Service (KMS), then you must add the following kms:Decrypt permission. Click here to learn more.

Application Definition including Amazon EKS Clusters

Resilience Hub supports the ability to assess the resilience of an application that contains Amazon Elastic Kubernetes Service (Amazon EKS) clusters. In order to assess the application, Resilience Hub needs to access Kubernetes role-based access control (RBAC) configuration to assess other Kubernetes (K8s) workloads. For more information, read the blog that walks through onboarding an application containing EKS to Resilience Hub.

For a full list of permissions required to work with other services please refer to our documentation.

Conclusion

Permissions are necessary in order to protect your applications, but they shouldn’t become an obstacle to operational excellence for your organization. By using the managed policy when creating roles for use with AWS Resilience Hub, you will be able to easily take advantage of new functionality as it is made available. For users that are looking to automate the resilience assessments of their applications, either through use of drift detection notifications or integration with a CI/CD pipeline, the correct permissions setup will help you be successful with making resilience a continuous part of your application development lifecycle.

About the Author