AWS Secrets Manager now lets you create and manage your resource-based policies utilizing the Secrets Manager console. With this particular launch, we have been also improving your security posture by both identifying and preventing creation of resource policies that grant overly broad usage of your secrets across your Amazon Web Services (AWS) accounts. To do this, we utilize the Zelkova engine to mathematically analyze access granted by your resource policy and alert you if such permissions are located. The analysis verifies access across all resource-policy statements, actions, and the pair of condition keys found in your policies. To be looked at non-public, the resource policy must grant access and then fixed values (values that don’t include a wildcard) of one or even more of the next: aws:SourceArn, aws:SourceVpc, aws:SourceVpce, aws:SourceAccount, aws:SourceIP, and ensure the main does not add a “*” entry.

If the policy grants Public or broad usage of your secrets across AWS accounts overly, Secrets Manager will block you from applying the policy in the console and alert you with a dashboard message. This prevents your policy from granting broader usage of your secrets accidentally, ensuring you’re restricting it to the intended AWS accounts instead, AWS services, and AWS Identity and Access Management (IAM) entities. Usage of AWS Secrets Manager requires AWS credentials. Those credentials must contain permission to gain access to the AWS resources you intend to access, such as for example your Secrets Manager secrets. In this website post, we use Public or broad usage of make reference to values (or perhaps a mix of values) in the resource policy that create a wide access across AWS accounts and principals.

With AWS Secrets Manager, the choice is had by one to store, rotate, manage, and retrieve various kinds of secrets. These could be database passwords and usernames, API keys, string values, and binary data. AWS supports the capability to share these secrets cross-account through the use of resource policies via the AWS Command Line Interface (AWS CLI) and today via the Secrets Manager console.

Why would you have to share a secret? There are lots of reasons. You might have database credentials managed in a central account which are needed by applications in your production account. Perhaps you have the binary stored for an encryption key that other accounts use to generate AWS Key Management Service (AWS KMS) keys within their accounts. To do this goal while ensuring a secure transfer of information and least privilege permissions, you shall require a resource-based policy on your own secret, a resource-based policy on your own AWS KMS Customer Managed Key (CMK) useful for encrypting the trick, and a user-based policy on your own IAM principal.

You can still develop a policy using AWS CLI or AWS SDK permitting usage of a broader scope of entities if your organization needs dictate. Should you choose permit this sort of broader access, AWS Secrets Manager shall show a notification in your dashboard, as shown in Figure 2, below.

Figure 1. This shows the warning when you try to create a resource policy that grants broad access to your secrets via the AWS Secrets Manager console.

Figure 2. This alert arises when you select a secret which has a resource policy attached via the CLI that grants broad usage of the secret.

In the example below, you’ll observe how to utilize the AWS Secrets Manager console to add a resource-based policy and invite usage of your secret from the secondary account. A secret in the CENTRAL_SECURITY_ACCOUNT will undoubtedly be set to permit it to be accessed by an IAM role in the PRODUCTION_ACCOUNT.

In this example:

• SECURITY_SECRET = The trick created in the CENTRAL_SECURITY_ACCOUNT.
• SECURITY_CMK = The AWS KMS CMK used to encrypt the SECURITY_SECRET.
• PRODUCTION_ROLE = The AWS IAM role used to gain access to the SECURITY_SECRET.
• PRODUCTION_ACCOUNT = The AWS account that owns the AWS IAM role useful for cross-account access.

Overview of solution

The architecture of the answer can be divided into four steps, which are outlined in Figure 3. The four main steps are:

1. Create the resource-based policy via the AWS Secrets Manager console on the SECURITY_SECRET in the CENTRAL_SECURITY_ACCOUNT.
2. Update the SECURITY_CMK policy in the CENTRAL_SECURITY_ACCOUNT to permit the role from the PRODUCTION account access.
3. Grant the AWS IAM function in the Manufacturing_ACCOUNT permissions to gain access to the secret.
4. Check and verify gain access to from the Creation_ACCOUNT.

Physique 3. A visual summary of the four methods to utilize the AWS Secrets Supervisor console to add a resource-based plan, allow usage of your secret from the secondary account, and ensure that you verify the process.

Prerequisites

To use the instance in this article, you need:

• An AWS accounts.
• An IAM Function with permissions to create modifications in both CENTRAL_SECURITY_Accounts and the PRODUCTION_ACCOUNT.
• An IAM role in the PRODUCTION_ACCOUNT you intend to grant permissions to gain access to the SECURITY_SECRET.

Deploying the solution

Step 1: Develop a resource-based policy in your CENTRAL_SECURITY account on the SECURITY_SECRET secret

1. Log in to the AWS Secrets Manager console in the CENTRAL_SECURITY_ACCOUNT.
2. Choose SECURITY_SECRET.
3. Choose Edit Permissions close to Resource Permissions (optional).
   

   Figure 4. The dashboard view where you edit permissions.

4. This will bring one to the page to include the resource policy. It shall offer you a basic template as shown in Figure 5, below.
   

   Figure 5. The essential template to include the resource policy.

5. Since the entire policy is provided for you personally in this example, delete the template from the written text box.
6. Copy the policy below and paste it in the written text box. Be sure to replace together with your AWS account ID PRODUCTION. It is possible to adjust the permissions you grant if needed also. This policy allows a particular role in the PRODUCTION_ACCOUNT account to retrieve the existing version of one’s secret. In the example, my IAM Role is named PRODUCTION_ROLE. Note you certainly do not need to replace with any value AWSCURRENT.

   
   
       "Version": "2012-10-17",
       "Statement": [
           
               "Effect": "Allow",
               "Principal": 
                   "AWS": "arn:aws:iam::PRODUCTION:role/PRODUCTION_ROLE"
               ,
               "Action": "secretsmanager:GetSecretValue",
               "Resource": "*",
               "Condition": 
                   "ForAnyValue:StringEquals": 
                       "secretsmanager:VersionStage": "AWSCURRENT"
                   
               
           
       ]
   
   

   As shown in Figure 6, below, you’ll see this in the resource policy text area (together with your AWS account ID instead of PRODUCTION).

   

   Figure 6. The example resource policy shown in the console.

7. Choose Save.

Step 2: Update the resource-based policy in your CENTRAL_SECURITY account on the SECURITY_CMK

Note: Secrets in AWS Secrets Manager are encrypted automagically. However, it’s important for you yourself to provide authorization for IAM Principals that require to gain access to your secrets. Complete authorization requires usage of the trick and the KMS CMK used to encrypt it, which prevents accidental public permissions on the trick. You should maintain both sets of authorization to supply appropriate usage of secrets.

1. Log into the AWS KMS console in the CENTRAL_SECURITY_ACCOUNT.
2. Choose SECURITY_CMK.
3. Next to Key policy pick the Edit button.
4. Paste the below code snippet into your key policy to permit the PRODUCTION_ACCOUNT access:

   
   
       "Sid": "AllowUseOfTheKey",
       "Effect": "Allow",
       "Principal": 
           "AWS": "arn:aws:iam::PRODUCTION:role/PRODUCTION_ROLE"
       ,
       "Action": [
           "kms:Decrypt",
           "kms:DescribeKey"
       ],
       "Resource": "arn:aws:kms:us-east-1:CENTRAL_SECURITY:key/SECURITY_CMK"
   
   

   You need to replace together with your production account ID PRODUCTION, PRODUCTION_ROLE together with your production Role name, CENTRAL_SECURITY together with your security account ID, and SECURITY_CMK with the CMK key ID of one’s security CMK. If you forget to swap out the account IDs in the policy with your personal, you’ll see one message like the one shown in Figure 7, below.

   

   Figure 7. Error message that appears in the event that you don’t swap out your account number correctly.

5. Choose Save changes.

Step 3: Add permissions to the PRODUCTION_ROLE in the PRODUCTION account

1. Log into the AWS IAM console inside the PRODUCTION_ACCOUNT account.
2. In the left routing pane, choose Functions.
3. Select Manufacturing_ROLE.
4. Under the Permissions tab, choose Add inline policy.
5. Choose the JSON tab and paste the below plan:

   
   
       "Version": "2012-10-17",
       "Statement": [
           
               "Effect": "Allow",
               "Action": "secretsmanager:GetSecretValue",
               "Useful resource": " arn:aws:secretsmanager:us-east-1:CENTRAL_SECURITY:magic formula:SECURITY_SECRET"
           ,
           
               "Effect": "Allow",
               "Action": [
                   "kms:Decrypt",
                   "kms:DescribeKey"
               ],
               "Source": "arn:aws:kms:us-east-1:CENTRAL_SECURITY:crucial/SECURITY_CMK"
           
       ]
   
   

   You will have to replace together with your security account id CENTRAL_SECURITY, SECURITY_SECRET with the trick id, and Protection_CMK with the CMK essential id of one’s security CMK.

6. Choose Evaluation policy.
7. Name the plan Central_Security_Account_Security-Secret-Access, and choose Create policy.

Action 4: Test usage of the SECURITY_Key from the Creation account

Verification of entry via AWS CLI

1. From the AWS CLI, utilize the PRODUCTION_ROLE credentials to perform the get-secret-value command.
2. Returned output should appear to be the illustration, below, in Figure 8.

   
   $aws secretsmanager get-secret-value --secret-id SECURITY_SECRET --version-stage AWSCURRENT
   
   
       “ARN”: “arn:aws:secretsmanager:us-east-1:CENTRAL_SECURITY:secret:SECURITY_SECRET”,
       “Name”: “SECURITY_SECRET”,
       “SecretString”: “TheSecretString”,
       “CreatedDate”: 123456789,
       “VersionId”: “64c4250d-0b81-42e0-9a0c-e189d3c9aea8”,
       “VersionsStages”: [
           “AWSCURRENT”
       ]
   
   

You can even verify the policy was attached from the CENTRAL_SECURITY_ACCOUNT by following steps below.

Verification of policy via console

1. Log in to the AWS Secrets Manager console in the CENTRAL_SECURITY_ACCOUNT.
2. Choose SECURITY_SECRET.
3. Scroll right down to where it shows Resource Permissions (optional), and you’ll see your resource policy stored in the console, as shown in Figure 8, below.
   

   Figure 8. What the example resource policy appears like in the console.

Conclusion

In this article, you saw how exactly to put in a resource-based policy on a secret in AWS Secrets Manager utilizing the console, and how exactly to update your AWS KMS CMK resource-based policy make it possible for access. The example showed establishing cross-account access, and allowing a job from the PRODUCTION_ACCOUNT to utilize the trick in the CENTRAL_SECURITY_ACCOUNT. Utilizing the AWS Secrets Manager console to create the resource-based policy, you’ve got a straight-forward now, visual solution to add and manage resource-based policies for the secrets and receive notifications if that policy is too broad.

When you have feedback concerning this post, submit comments in the Comments section below. When you have questions concerning this post, take up a new thread on the AWS Secrets Manager forum or contact AWS Support.

Want more AWS Security how-to content, news, and show announcements? Follow us on Twitter.