AWS Secrets Manager

(1)

AWS Secrets Manager

User Guide

(2)

AWS Secrets Manager: User Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is AWS Secrets Manager?

In the past, when you created a custom application to retrieve information from a database, you typically embedded the credentials, the secret, for accessing the database directly in the application. When the time came to rotate the credentials, you had to do more than just create new credentials. You had to invest time to update the application to use the new credentials. Then you distributed the updated application. If you had multiple applications with shared credentials and you missed updating one of them, the application failed. Because of this risk, many customers choose not to regularly rotate credentials, which eﬀectively substitutes one risk for another.

Secrets Manager enables you to replace hardcoded credentials in your code, including passwords, with an API call to Secrets Manager to retrieve the secret programmatically. This helps ensure the secret can't be compromised by someone examining your code, because the secret no longer exists in the code. Also, you can configure Secrets Manager to automatically rotate the secret for you according to a specified schedule. This enables you to replace long-term secrets with short-term ones, significantly reducing the risk of compromise.

For a list of terms and concepts you need to understand to make full use of Secrets Manager, see Get started (p. 10).

Topics

• Basic AWS Secrets Manager scenario (p. 1)

• Features of AWS Secrets Manager (p. 2)

• Compliance with standards for AWS Secrets Manager (p. 4)

• Pricing for AWS Secrets Manager (p. 6)

• Support and feedback for AWS Secrets Manager (p. 6)

Basic AWS Secrets Manager scenario

The following diagram illustrates the most basic scenario. The diagram displays you can store credentials for a database in Secrets Manager, and then use those credentials in an application to access the

database.

1. The database administrator creates a set of credentials on the Personnel database for use by an application called MyCustomApp. The administrator also conﬁgures those credentials with the permissions required for the application to access the Personnel database.

2. The database administrator stores the credentials as a secret in Secrets Manager named

MyCustomAppCreds. Then, Secrets Manager encrypts and stores the credentials within the secret as the protected secret text.

(8)

Features

3. When MyCustomApp accesses the database, the application queries Secrets Manager for the secret named MyCustomAppCreds.

4. Secrets Manager retrieves the secret, decrypts the protected secret text, and returns the secret to the client app over a secured (HTTPS with TLS) channel.

5. The client application parses the credentials, connection string, and any other required information from the response and then uses the information to access the database server.

Note

Secrets Manager supports many types of secrets. However, Secrets Manager can natively rotate credentials for supported AWS databases (p. 3) without any additional programming.

However, rotating the secrets for other databases or services requires creating a custom Lambda function to deﬁne how Secrets Manager interacts with the database or service. You need some programming skill to create the function. For more information, see Rotate AWS Secrets Manager secrets (p. 81).

Features of AWS Secrets Manager

Programmatically retrieve encrypted secret values at runtime

Secrets Manager helps you improve your security posture by removing hard-coded credentials from your application source code, and by not storing credentials within the application, in any way. Storing the credentials in or with the application subjects them to possible compromise by anyone who can inspect your application or the components. Since you have to update your application and deploy the changes to every client before you can deprecate the old credentials, this process makes rotating your credentials diﬃcult.

Secrets Manager enables you to replace stored credentials with a runtime call to the Secrets Manager Web service, so you can retrieve the credentials dynamically when you need them.

Most of the time, your client requires access to the most recent version of the encrypted secret value.

When you query for the encrypted secret value, you can choose to provide only the secret name or Amazon Resource Name (ARN), without specifying any version information at all. If you do this, Secrets Manager automatically returns the most recent version of the secret value.

However, other versions can exist at the same time. Most systems support secrets more complicated than a simple password, such as full sets of credentials including the connection details, the user ID, and the password. Secrets Manager allows you to store multiple sets of these credentials at the same time.

Secrets Manager stores each set in a diﬀerent version of the secret. During the secret rotation process, Secrets Manager tracks the older credentials, as well as the new credentials you want to start using, until the rotation completes.

Store diﬀerent types of secrets

Secrets Manager enables you to store text in the encrypted secret data portion of a secret. This typically includes the connection details of the database or service. These details can include the server name, IP address, and port number, as well as the user name and password used to sign in to the service. For details on secrets, see the maximum and minimum values. The protected text doesn't include:

• Secret name and description

• Rotation or expiration settings

• ARN of the KMS key associated with the secret

• Any attached AWS tags

(9)

Encrypt your secret data

Secrets Manager encrypts the protected text of a secret by using AWS Key Management Service (AWS KMS). Many AWS services use AWS KMS for key storage and encryption. AWS KMS ensures secure encryption of your secret when at rest. Secrets Manager associates every secret with a KMS key. It can be either AWS managed key for Secrets Manager for the account (aws/secretsmanager), or a customer managed key you create in AWS KMS.

Whenever Secrets Manager encrypt a new version of the protected secret data, Secrets Manager requests AWS KMS to generate a new data key from the KMS key. Secrets Manager uses this data key for envelope encryption. Secrets Manager stores the encrypted data key with the protected secret data. Whenever the secret needs decryption, Secrets Manager requests AWS KMS to decrypt the data key, which Secrets Manager then uses to decrypt the protected secret data. Secrets Manager never stores the data key in unencrypted form, and always disposes the data key immediately after use.

In addition, Secrets Manager, by default, only accepts requests from hosts using open standard Transport Layer Security (TLS) and Perfect Forward Secrecy. Secrets Manager ensures encryption of your secret while in transit between AWS and the computers you use to retrieve the secret.

Automatically rotate your secrets

You can conﬁgure Secrets Manager to automatically rotate your secrets without user intervention and on a speciﬁed schedule.

You deﬁne and implement rotation with an AWS Lambda function. This function deﬁnes how Secrets Manager performs the following tasks:

• Creates a new version of the secret.

• Stores the secret in Secrets Manager.

• Conﬁgures the protected service to use the new version.

• Veriﬁes the new version.

• Marks the new version as production ready.

Staging labels help you to keep track of the diﬀerent versions of your secrets. Each version can have multiple staging labels attached, but each staging label can only be attached to one version. For example, Secrets Manager labels the currently active and in-use version of the secret with AWSCURRENT.

You should conﬁgure your applications to always query for the current version of the secret. When the rotation process creates a new version of a secret, Secrets Manager automatically adds the staging label AWSPENDING to the new version until testing and validation completes. Only then does Secrets Manager add the AWSCURRENT staging label to this new version. Your applications immediately start using the new secret the next time they query for the AWSCURRENT version.

Databases with fully conﬁgured and ready-to-use rotation support

When you choose to enable rotation, Secrets Manager supports the following Amazon Relational Database Service (Amazon RDS) databases with AWS written and tested Lambda rotation function templates, and full conﬁguration of the rotation process:

• Amazon Aurora on Amazon RDS

• MySQL on Amazon RDS

• PostgreSQL on Amazon RDS

• Oracle on Amazon RDS

• MariaDB on Amazon RDS

(10)

Control access to secrets

• Microsoft SQL Server on Amazon RDS

Other services with fully conﬁgured and ready-to-use rotation support

You can also choose to enable rotation on the following services, fully supported with AWS written and tested Lambda rotation function templates, and full conﬁguration of the rotation process:

• Amazon DocumentDB

• Amazon Redshift

You can also store secrets for almost any other kind of database or service. However, to automatically rotate the secrets, you need to create and conﬁgure a custom Lambda rotation function. For more information about writing a custom Lambda function for a database or service, see the section called

“How rotation works” (p. 88).

Control access to secrets

You can attach AWS Identity and Access Management (IAM) permission policies to your users, groups, and roles that grant or deny access to speciﬁc secrets, and restrict management of those secrets. For example, you might attach one policy to a group with members that require the ability to fully manage and conﬁgure your secrets. Another policy attached to a role used by an application might grant only read permission on the one secret the application needs to run.

Alternatively, you can attach a resource-based policy directly to the secret to grant permissions specifying users who can read or modify the secret and the versions. Unlike an identity-based policy which automatically applies to the user, group, or role, a resource-based policy attached to a secret uses the Principal element to identify the target of the policy. The Principal element can include users and roles from the same account as the secret or principals from other accounts.

Compliance with standards for AWS Secrets Manager

AWS Secrets Manager has undergone auditing for the following standards and can be part of your solution when you need to obtain compliance certiﬁcation.

AWS has expanded its Health Insurance Portability and Accountability Act (HIPAA) compliance program to include AWS Secrets Manager as a HIPAA-eligible service. If you have an executed Business Associate Agreement (BAA) with AWS, you can use Secrets Manager to help build your HIPAA-compliant applications. AWS oﬀers a HIPAA-focused whitepaper for customers who are interested in learning more about how they can leverage AWS for the processing and storage of health information. For more information, see HIPAA Compliance.

AWS Secrets Manager has an Attestation of Compliance for Payment Card Industry (PCI) Data Security Standard (DSS) version 3.2 at Service Provider Level 1. Customers who use AWS products and services to store, process, or transmit cardholder data can use AWS Secrets Manager as they manage their own PCI DSS compliance certiﬁcation. For more information about PCI DSS, including how to request a copy of the AWS PCI Compliance Package, see PCI DSS Level 1.

(11)

Compliance with standards

AWS Secrets Manager has successfully completed compliance certiﬁcation for ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, and ISO 9001. For more information, see ISO 27001, ISO 27017, ISO 27018, ISO 9001.

System and Organization Control (SOC) reports are independent third-party examination reports that demonstrate how Secrets Manager achieves key compliance controls and objectives. The purpose of these reports is to help you and your auditors understand the AWS controls that are established to support operations and compliance. For more information, see SOC Compliance.

The Federal Risk and Authorization Management Program (FedRAMP) is a government- wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. The FedRAMP Program also provides provisional authorizations for services and regions for East/West and GovCloud to consume government or regulated data. For more information, see FedRAMP Compliance.

The Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) provides a standardized assessment and authorization process for cloud service providers (CSPs) to gain a DoD provisional authorization, so that they can serve DoD customers. For more information, see DoD SRG Resources

The Information Security Registered Assessors Program (IRAP) enables Australian government customers to validate that appropriate controls are in place and determine the appropriate responsibility model for addressing the requirements of the Australian government Information Security Manual (ISM) produced by the Australian Cyber Security Centre (ACSC). For more information, see IRAP Resources

(12)

Pricing

Amazon Web Services (AWS) achieved the Outsourced Service Provider’s Audit Report (OSPAR) attestation. AWS alignment with the Association of Banks in Singapore (ABS) Guidelines on Control Objectives and Procedures for Outsourced Service Providers (ABS Guidelines) demonstrates to customers AWS commitment to meeting the high expectations for cloud service providers set by the ﬁnancial services industry in Singapore. For more information, see OSPAR Resources

Pricing for AWS Secrets Manager

When you use Secrets Manager, you pay only for what you use, and no minimum or setup fees. There is no charge for secrets that you have marked for deletion. For the current complete pricing list, see AWS Secrets Manager Pricing.

You can use the AWS managed key (aws/secretsmanager) that Secrets Manager creates to encrypt your secrets for free. If you create your own KMS keys to encrypt your secrets, AWS charges you at the current AWS KMS rate. For more information, see AWS Key Management Service pricing.

If you enable AWS CloudTrail on your account, you can obtain logs of the API calls that Secrets Manager sends out. Secrets Manager logs all events as management events. AWS CloudTrail stores the ﬁrst copy of all management events for free. However, you can incur charges for Amazon S3 for log storage and for Amazon SNS if you enable notiﬁcation. Also, if you set up additional trails, the additional copies of management events can incur costs. For more information, see AWS CloudTrail pricing.

Support and feedback for AWS Secrets Manager

We welcome your feedback. You can send comments to [email protected].

You also can post your feedback and questions in our AWS Secrets Manager support forum. For more information about the AWS Support forums, see Forums Help.

To request new features for the AWS Secrets Manager console or command line tools, we recommend you submit them in email to [email protected].

To provide feedback for our documentation, you can use the feedback link at the bottom of each web page. Be speciﬁc about the issue you face and how the documentation failed to help you. Let us know what you saw and how that diﬀered from what you expected. That helps us to understand what we need to do to improve the documentation.

Here are some additional resources available to you:

• AWS Training Catalog – Role-based and specialty courses, as well as self-paced labs, to help you sharpen your AWS skills and gain practical experience.

• AWS Developer Tools – Tools and resources that provide documentation, code examples, release notes, and other information to help you build innovative applications with AWS.

• AWS Support Center – The hub for creating and managing your AWS Support cases. It includes links to other helpful resources, such as forums, technical FAQs, service health status, and AWS Trusted Advisor.

(13)

Support and feedback

• AWS Support – A one-on-one, fast-response support channel for helping you build and run applications in the cloud.

• Contact Us – A central contact point for inquiries about AWS billing, accounts, events, and other issues.

• AWS Site Terms – Detailed information about our copyright and trademark, your account, your license, site access, and other topics.

(14)

Secrets Manager console

Access Secrets Manager

You can work with Secrets Manager in any of the following ways:

• Secrets Manager console (p. 8)

• Command line tools (p. 8)

• AWS SDKs (p. 8)

• HTTPS Query API (p. 9)

Secrets Manager console

You can manage your secrets using the browser-based Secrets Manager console and perform almost any task related to your secrets by using the console.

Command line tools

The AWS command line tools allows you to issue commands at your system command line to perform Secrets Manager and other AWS tasks. This can be faster and more convenient than using the console.

The command line tools can be useful if you want to build scripts to perform AWS tasks.

AWS provides two sets of command line tools:

• AWS Command Line Interface (AWS CLI)

• AWS Tools for Windows PowerShell

AWS SDKs

The AWS SDKs consist of libraries and sample code for various programming languages and platforms, for example, Java, Python, Ruby, .NET, and others. The SDKs include tasks such as cryptographically signing requests, managing errors, and retrying requests automatically. For more information, see the section called “AWS SDKs” (p. 8).

To download and install any of the SDKs, see Tools for Amazon Web Services.

For SDK documentation, see:

• C++

• Java

• PHP

• Python

• Ruby

• .NET

• Node.js

• Go

(15)

HTTPS Query API

The HTTPS Query API gives you programmatic access to Secrets Manager and AWS. The HTTPS Query API allows you to issue HTTPS requests directly to the service.

Although you can make direct calls to the Secrets Manager HTTPS Query API, we recommend that you use one of the SDKs instead. The SDK performs many useful tasks you otherwise must perform manually. For example, the SDKs automatically sign your requests and convert responses into a structure syntactically appropriate to your language.

(16)

Secrets Manager concepts

Get started with AWS Secrets Manager

There are many diﬀerent types of secrets you might have in your organization. Here are some of them, and where you can store them in AWS:

• AWS credentials – AWS Identity and Access Management

• Encryption keys – AWS Key Management Service

• SSH keys – Amazon EC2 Instance Connect

• Private keys and certiﬁcates – AWS Certiﬁcate Manager

• Database credentials – Secrets Manager

• Application credentials – Secrets Manager

• OAuth tokens – Secrets Manager

• Application Programming Interface (API) keys – Secrets Manager

Secrets Manager concepts

The following concepts are important for understanding how Secrets Manager works.

Secret

In Secrets Manager, a secret consists of secret information, the secret value, plus metadata about the secret. A secret value can be a string or binary. To store multiple string values in one secret, we recommend that you use a JSON text string with key/value pairs, for example:

{ "host" : "ProdServer-01.databases.example.com", "port" : "8888",

"username" : "administrator", "password" : "EXAMPLE-PASSWORD", "dbname" : "MyDatabase", "engine" : "mysql"

}

A secret's metadata includes:

• An Amazon Resource Name (ARN) with the following format:

arn:aws:secretsmanager:<Region>:<AccountId>:secret:SecretName-6RandomCharacters

• The name of the secret, a description, a resource policy, and tags.

• The ARN for an encryption key, an AWS KMS key that Secrets Manager uses to encrypt and decrypt the secret value. Secrets Manager stores secret text in an encrypted form and encrypts the secret in transit.

See the section called “Secret encryption and decryption” (p. 121).

• Information about how to rotate the secret, if you set up rotation. See the section called

“Rotation” (p. 11).

(17)

Rotation

Secrets Manager uses IAM permission policies to make sure that only authorized users can access or modify a secret. See Authentication and access control for AWS Secrets Manager (p. 15).

A secret has versions which hold copies of the encrypted secret value. When you change the secret value, or the secret is rotated, Secrets Manager creates a new version. See the section called

“Version” (p. 11).

You can use a secret across multiple AWS Regions by replicating it. When you replicate a secret, you create a copy of the original or primary secret called a replica secret. The replica secret remains linked to the primary secret. See the section called “Replicate a secret to other Regions” (p. 46).

See the section called “Create a secret” (p. 38).

Rotation

Rotation is the process of periodically updating a secret to make it more diﬃcult for an attacker to access the credentials. In Secrets Manager, you can set up automatic rotation for your secrets. When Secrets Manager rotates a secret, it updates the credentials in both the secret and the database or service. See Rotate secrets (p. 81).

Version

A secret has versions which hold copies of the encrypted secret value. When you change the secret value, or the secret is rotated, Secrets Manager creates a new version. A secret always has a version with the staging label AWSCURRENT, which is the current secret value.

During rotation, Secrets Manager uses staging labels to indicate the diﬀerent versions of a secret:

• AWSCURRENT indicates the version that is actively used by clients. A secret always has an AWSCURRENT version.

• AWSPENDING indicates the version that will become AWSCURRENT when rotation completes.

• AWSPREVIOUS indicates the last known good version, in other words, the previous AWSCURRENT version.

Secrets Manager deprecates versions with no staging labels and removes them when there are more than 100. Secrets Manager doesn't remove versions created less than 24 hours ago.

When you use the AWS CLI or AWS SDK to get the secret value, you can specify the version of the secret.

If you don't specify a version, either by version ID or staging label, Secrets Manager gets the version with the staging label AWSCURRENT attached.

You can also attach your own staging label to a version, for example to indicate development or production versions. You can attach up to 20 staging labels to a secret. Two versions of a secret can't have the same staging label.

(18)

Tutorial: Create and retrieve a secret

AWS Secrets Manager tutorials

Topics

• Tutorial: Create and retrieve a secret (p. 12)

Tutorial: Create and retrieve a secret

In this tutorial, you create a secret and store it in AWS Secrets Manager. You can use either the console or the AWS CLI. The secret contains a single password, stored as a key-value pair. You encrypt your secret with the AWS managed key (aws/secretsmanager). There is no cost for using this key.

You then retrieve the secret using the console or the AWS CLI.

Users new to Secrets Manager can beneﬁt from enrolling in the 30 day free trial and not receive billing for the activity performed in this tutorial.

Prerequisites

This tutorial assumes you can access an AWS account, and you can sign in to AWS as an IAM user with permissions to create and retrieve secrets in the AWS Secrets Manager console, or use equivalent commands in the AWS CLI. For more information on conﬁguring IAM users, refer to the IAM documentation.

Step 1: Create and store your secret in AWS Secrets Manager

To store your secret by using the console

1. Sign in to the AWS Secrets Manager console at https://console.aws.amazon.com/secretsmanager/.

2. Choose Store a new secret.

3. On the Store a new secret page, do the following:

a. For Secret type, choose Other type of secret.

b. For Key/value pairs, in the first field, enter MyPassword. In the second field, enter a password.

This is the text that will be encrypted when you store the secret.

c. For Encryption key, keep DefaultEncryptionKey.

d. Choose Next.

4. On the next page, for Secret name, enter tutorial/MyFirstSecret, and then at the bottom of the page, choose Next.

5. On the next page, keep Disable automatic rotation, and then at the bottom of the page, choose Next.

6. On the Review page, you can check your secret settings.

In Sample code, you can copy the code to paste in your applications. These examples retrieve the secret value that you stored. In this tutorial, you stored a password.

Choose Store.

(19)

Step 2: Retrieve your secret from AWS Secrets Manager

Secrets Manager console returns to the list of secrets in your account and your new secret is now in the list.

To store your secret by using the CLI

1. Open a command prompt to run the AWS CLI. If you haven't installed the AWS CLI, see Installing the AWS Command Line Interface.

2. Enter the following command:

$ aws secretsmanager create-secret --name tutorial/MyFirstSecret --secret- string EXAMPLE-PASSWORD

{ "ARN": "arn:aws:secretsmanager:us-east-2-2:111122223333:secret:tutorial/

MyFirstSecret-a1b2c3",

"Name": "tutorial/MyFirstSecret",

"VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE"

}

Step 2: Retrieve your secret from AWS Secrets Manager

To retrieve your secret by using the console

1. Open the Secrets Manager console at https://console.aws.amazon.com/secretsmanager/.

2. On the Secrets list page, choose tutorial/MyFirstSecret.

3. On the Secrets details page, in the Secret value section, choose Retrieve secret value.

You can view your secret as either key-value pairs, or on the Plaintext tab as a JSON text structure.

To retrieve your secret by using the CLI

1. Open a command prompt to run the AWS CLI. If you haven't installed the AWS CLI, see Installing the AWS Command Line Interface.

2. Enter the following command:

$ aws secretsmanager get-secret-value --secret-id tutorial/MyFirstSecret {

"ARN": "arn:aws:secretsmanager:us-east-2:111122223333:secret:tutorial/

MyFirstSecret-a1b2c3",

"Name": "tutorial/MyFirstSecret",

"VersionId": "EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE", "SecretString": "S3@ttl3R0cks",

"VersionStages": [ "AWSCURRENT"

],

"CreatedDate": 1522680764.668 }

(20)

Secrets Manager best practices

The following recommendations help you to more securely use AWS Secrets Manager:

Add retries to your application

Your AWS client might see calls to Secrets Manager fail due to rate limiting. When you exceed an API request quota, Secrets Manager throttles the request. To respond, use a backoﬀ and retry strategy.

See the section called “Add retries to your application” (p. 137).

Mitigate the risks of logging and debugging your Lambda function

When you create a Lambda rotation function, be cautious about including debugging or logging statements in your function. These statements can cause information in your function to be written to Amazon CloudWatch, so make sure the log doesn't include any sensitive data from the secret.

If you do include these statements in your code for testing and debugging, make sure you remove them before using the code in production. Also remove any logs that include sensitive information collected during development.

The Lambda functions for supported databases (p. 3) don't include logging and debug statements.

Mitigate the risks of using the AWS CLI to store your secrets

When you use the AWS CLI and enter commands in a command shell, there is a risk of the command history being accessed or utilities having access to your command parameters. See the section called

“Mitigate the risks of using the AWS CLI to store your secrets” (p. 118).

Run everything in a VPC

We recommend that you run as much of your infrastructure as possible on private networks that are not accessible from the public internet. See the section called “Amazon VPC” (p. 116).

Rotate secrets on a schedule

If you don't change your secrets for a long period of time, the secrets become more likely to be compromised. We recommend that you rotate your secrets every 30 days. See Rotate AWS Secrets Manager secrets (p. 81)

Monitor your secrets

Monitor your secrets and log any changes to them. You can use the logs if you need to investigate any unexpected usage or change, and then you can roll back unwanted changes. You can also set automated checks for inappropriate usage of secrets and any attempts to delete secrets. See Monitor AWS Secrets Manager secrets (p. 107).

Use Secrets Manager to provide credentials to Lambda functions

Use Secrets Manager to securely provide database credentials to Lambda functions without hardcoding the secrets in code or passing them through environmental variables. See How to securely provide database credentials to Lambda functions by using AWS Secrets Manager.

More resources on best practices

For more resources, see Security Pillar - AWS Well-Architected Framework.

(21)

Secrets Manager administrator permissions

Authentication and access control for AWS Secrets Manager

Secrets Manager uses AWS Identity and Access Management (IAM) to secure access to secrets. IAM provides authentication and access control. Authentication veriﬁes the identity of individuals' requests.

Secrets Manager uses a sign-in process with passwords, access keys, and multi-factor authentication (MFA) tokens to verify the identity of the users. See Signing in to AWS. Access control ensures that only approved individuals can perform operations on AWS resources such as secrets. Secrets Manager uses policies to deﬁne who has access to which resources, and which actions the identity can take on those resources. See Policies and permissions in IAM.

Secrets Manager administrator permissions

To grant Secrets Manager administrator permissions, follow the instructions at Adding and removing IAM identity permissions, and attach the following policies:

• SecretsManagerReadWrite

• IAMFullAccess

We recommend you do not grant administrator permissions to end users. While this allows your users to create and manage their secrets, the permission required to enable rotation (IAMFullAccess) grants signiﬁcant permissions that are not appropriate for end users.

Permissions to access secrets

By using IAM permission policies, you control which users or services have access to your secrets. A permissions policy describes who can perform which actions on which resources. You can:

• the section called “Attach a permissions policy to an identity” (p. 16)

• the section called “Attach a permissions policy to a secret” (p. 16)

Permissions for Lambda rotation functions

Secrets Manager uses AWS Lambda functions to rotate secrets. The Lambda function must have access to the secret as well as the database or service that the secret contains credentials for. See the section called “Permissions for rotation” (p. 90).

Permissions for encryption keys

Secrets Manager uses AWS Key Management Service (AWS KMS) keys to encrypt secrets. The AWS managed key aws/secretsmanager automatically has the correct permissions. If you use a diﬀerent KMS key, Secrets Manager needs permissions to that key. See the section called “Permissions for the KMS key” (p. 123).

(22)

Attach a permissions policy to an identity

You can attach permissions policies to IAM identities: users, user groups, and roles. In an identity-based policy, you specify which secrets the identity can access and the actions the identity can perform on the secrets.

You can use identity-based policies to:

• Grant an identity access to multiple secrets.

• Control who can create new secrets, and who can access secrets that haven't been created yet.

• Grant an IAM group access to secrets.

See the section called “Permissions policy examples” (p. 20).

To add or remove permissions on an identity

• Do one of the following:

• To use the console, see Adding IAM identity permissions (console).

• To use the AWS CLI, see Adding IAM identity permissions (AWS CLI)

• To use the AWS API, see Adding IAM identity permissions (AWS API)

Attach a permissions policy to a secret

In a resource-based policy, you specify who can access the secret and the actions they can perform on the secret. You can use resource-based policies to:

• Grant access to a single secret to multiple users and roles.

• Grant access to users or roles in other AWS accounts.

See the section called “Permissions policy examples” (p. 20).

When you attach a resource-based policy to a secret in the console, Secrets Manager uses the automated reasoning engine Zelkova and the API ValidateResourcePolicy to prevent you from granting a wide range of IAM principals access to your secrets. Alternatively, you can call the PutResourcePolicy API with the BlockPublicPolicy parameter from the CLI or SDK.

To view, change, or delete the resource policy for a secret (console)

1. Open the Secrets Manager console at https://console.aws.amazon.com/secretsmanager/.

2. In the secret details page for your secret, in the Resource permissions section, choose Edit permissions.

3. In the code ﬁeld, do one of the following, and then choose Save:

• To attach or modify a resource policy, enter the policy.

• To delete the policy, clear the code ﬁeld.

AWS CLI

To retrieve the policy attached to the secret, use get-resource-policy.

(23)

AWS SDK

Example

The following CLI command retrieves the policy attached to the secret.

$ aws secretsmanager get-resource-policy --secret-id production/MyAwesomeAppSecret {

"ARN": "arn:aws:secretsmanager:us-east-2:123456789012:secret:production/

MyAwesomeAppSecret-a1b2c3", "Name": "MyAwesomeAppSecret",

"ResourcePolicy": "{\"Version\":\"2012-10-17\",\"Statement\":{\"Effect\":\"Allow\",

\"Principal\":{\"AWS\":\"arn:aws:iam::111122223333:root\",\"arn:aws:iam::444455556666:root

\"},\"Action\":[\"secretsmanager:GetSecret\",\"secretsmanager:GetSecretValue\"],\"Resource

\":\"*\"}}"

}

To delete the policy attached to the secret, use delete-resource-policy.

Example

The following CLI command deletes the policy attached to the secret.

$ aws secretsmanager delete-resource-policy --secret-id production/MyAwesomeAppSecret { "ARN": "arn:aws:secretsmanager:us-east-2:123456789012:secret:production/

MyAwesomeAppSecret-a1b2c3",

"Name": "production/MyAwesomeAppSecret"

}

To attach a policy for the secret, use put-resource-policy. If there is already a policy attached, the command ﬁrst removes it, and then attaches the new policy. The policy must be formatted as JSON structured text. See JSON policy document structure.

Example

The following CLI command attaches the resource-based policy attached to the secret. The policy is deﬁned in the ﬁle secretpolicy.json. Use the the section called “Permissions policy examples” (p. 20) to get started writing your policy.

$ aws secretsmanager put-resource-policy --secret-id production/MyAwesomeAppSecret -- resource-policy file://secretpolicy.json

{ "ARN": "arn:aws:secretsmanager:us-east-2:123456789012:secret:production/

MyAwesomeAppSecret-a1b2c3", "Name": "MyAwesomeAppSecret"

}

AWS SDK

To retrieve the policy attached to a secret, use GetResourcePolicy . To delete a policy attached to a secret, use DeleteResourcePolicy.

To attach a policy to a secret, use PutResourcePolicy. If there is already a policy attached, the command ﬁrst removes it, and then attaches the new policy. The policy must be formatted as JSON structured text. See JSON policy document structure. Use the the section called “Permissions policy examples” (p. 20) to get started writing your policy.

For more information, see the section called “AWS SDKs” (p. 8).

(24)

AWS managed policy

AWS managed policies available for use with AWS Secrets Manager

AWS addresses many common use cases by providing managed policies, standalone IAM policies created and administered by AWS. Managed policies grant permissions for common use cases so you can avoid investigating the necessary permissions. You can attach or remove an AWS managed policy to users in your account, but you can't modify or delete the policy. For more information, see AWS managed policies in the IAM User Guide.

The following table describes the AWS managed policy you can use to help manage access to Secrets Manager secrets.

Policy Name Description ARN

SecretsManagerReadWriteProvides access to Secrets Manager operations. The policy doesn't allow the identity to conﬁgure rotation because rotation requires IAM permissions to create roles. If you need to enable rotation and conﬁgure Lambda rotation functions, you need to also assign the IAMFullAccess managed policy. See the section called

“Permissions for rotation” (p. 90).

arn:aws:iam::aws:policy/

SecretsManagerReadWrite

Determine who has permissions to your secrets

By default, IAM identities don't have permission to access secrets. When authorizing access to a secret, Secrets Manager evaluates the resource-based policy attached to the secret and all identity-based policies attached to the IAM user or role sending the request. To do this, Secrets Manager uses a process similar to the one described in Determining whether a request is allowed or denied in the IAM User Guide.

When multiple policies apply to a request, Secrets Manager uses a hierarchy to control permissions:

1. If a statement in any policy with an explicit deny matches the request action and resource:

The explicit deny overrides everything else and blocks the action.

2. If there is no explicit deny, but a statement with an explicit allow matches the request action and resource:

The explicit allow grants the action in the request access to the resources in the statement.

If the identity and the secret are in two diﬀerent accounts, there must be an allow in both the resource policy for the secret and the policy attached to the identity, otherwise AWS denies the request. For more information, see Cross-account access (p. 19).

3. If there is no statement with an explicit allow that matches the request action and resource:

AWS denies the request by default, which is called an implicit deny.

To view the resource-based policy for a secret

• Do one of the following:

(25)

Cross-account access

• Open the Secrets Manager console at https://console.aws.amazon.com/secretsmanager/.

In the secret details page for your secret, in the Resource permissions section, choose Edit permissions.

• Use the AWS CLI or AWS SDK to call GetResourcePolicy.

To determine who has access through identity-based policies

• Use the IAM policy simulator. See Testing IAM policies with the IAM policy simulator

Permissions for users in a diﬀerent account

To allow users in one account to access secrets in another account (cross-account access), you must allow access both in a resource policy and in an identity policy. This is diﬀerent than granting access to identities in the same account as the secret.

You must also allow the identity to use the KMS key that the secret is encrypted with. This is because you can't use the AWS managed key (aws/secretsmanager) for cross-account access. Instead, you must encrypt your secret with a KMS key that you create, and then attach a key policy to it. There is a charge for creating KMS keys. To change the encryption key for a secret, see the section called “Modify a secret” (p. 40).

The following example policies assume you have a secret and encryption key in Account1, and an identity in Account2 that you want to allow to access the secret value.

Step 1: Attach a resource policy to the secret in Account1

• The following policy allows ApplicationRole in Account2 to access the secret in Account1. To use this policy, see the section called “Attach a permissions policy to a secret” (p. 16).

{ "Version": "2012-10-17", "Statement": [

{

"Effect": "Allow", "Principal": {

"AWS": "arn:aws:iam::Account2:role/ApplicationRole"

},

"Action": "secretsmanager:GetSecretValue", "Resource": "*"

} ] }

Step 2: Add a statement to the key policy for the KMS key in Account1

• The following key policy statement allows ApplicationRole in Account2 to use the KMS key in Account1 to decrypt the secret in Account1. To use this statement, add it to the key policy for your KMS key. For more information, see Changing a key policy.

{ "Effect": "Allow", "Principal": {

"AWS": "arn:aws:iam::Account2:role/ApplicationRole"

},

"Action": [ "kms:Decrypt",

(26)

Permissions policy examples

"kms:DescribeKey"

], "Resource": "*"

}

Step 3: Attach an identity policy to the identity in Account2

• The following policy allows ApplicationRole in Account2 to access the secret in Account1 and decrypt the secret value by using the encryption key which is also in Account1. To use this policy, see the section called “Attach a permissions policy to an identity” (p. 16). You can ﬁnd the ARN for your secret in the Secrets Manager console on the secret details page under Secret ARN.

Alternatively, you can call DescribeSecret.

{ "Version" : "2012-10-17", "Statement" : [

{

"Effect": "Allow",

"Action": "secretsmanager:GetSecretValue", "Resource": "SecretARN"

}, {

"Effect": "Allow", "Action": "kms:Decrypt",

"Resource": "arn:aws:kms:Region:Account1:key/EncryptionKey"

} ]}

Permissions policy examples

A permissions policy is JSON structured text. See JSON policy document structure.

Permissions policies that you attach to resources and identities are very similar. Some elements you include in a policy for access to secrets include:

• Principal: who to grant access to. See Specifying a principal in the IAM User Guide. When you attach a policy to an identity, you don't include a Principal element in the policy.

You can grant permissions to an application that retrieves a secret from Secrets Manager. For example, an application running on an Amazon EC2 instance might need access to a database. You can create an IAM role attached to the EC2 instance proﬁle and then use a permissions policy to grant the role access to the secret.

You can also grant permissions to users authenticated by an identity system other than IAM. For example, you can associate IAM roles to mobile app users who sign in with Amazon Cognito. The role grants the app temporary credentials with the permissions in the role permission policy. Then you can use a permissions policy to grant the role access to the secret.

AWS service principals are not typically used as principals in a policy attached to a secret, but some AWS services require it. When the principal is a service principal, we recommend that you use the aws:SourceArn and aws:SourceAccount global condition keys. See the section called “Example: Service principal” (p. 26).

• Action: what they can do. See the section called “Secrets Manager actions” (p. 27).

• Resource: which secrets they can access. See the section called “Secrets Manager resources” (p. 34).

(27)

Example: Permission to retrieve secret values

The wildcard character (*) has diﬀerent meaning depending on what you attach the policy to:

• In a policy attached to a secret, * means the policy applies to this secret.

• In a policy attached to an identity, * means the policy applies to all resources, including secrets, in the account.

To attach a policy to a secret, see the section called “Attach a permissions policy to a secret” (p. 16).

To attach a policy to an identity, see the section called “Attach a permissions policy to an identity” (p. 16).

Topics

• Example: Permission to retrieve secret values (p. 21)

• Example: Wildcards (p. 22)

• Example: Permission to create secrets (p. 23)

• Example: Permissions and VPCs (p. 23)

• Example: Control access to secrets using tags (p. 25)

• Example: Limit access to identities with tags that match secrets' tags (p. 25)

• Example: Service principal (p. 26)

Example: Permission to retrieve secret values

To grant permission to retrieve secret values, you can attach policies to secrets or identities. For help determining which type of policy to use, see Identity-based policies and resource-based policies. For information about how to attach a policy, see the section called “Attach a permissions policy to a secret” (p. 16) and the section called “Attach a permissions policy to an identity” (p. 16).

The following examples show two diﬀerent ways to grant access to a secret. The ﬁrst example is a resource-based policy that you can attach to a secret. This example is useful when you want to grant access to a single secret to multiple users or roles. The second example is an identity-based policy that you can attach to a user or role in IAM. This example is useful when you want to grant access to an IAM group.

Example Read one secret (attach to a secret)

You can grant access to a secret by attaching the following policy to the secret. To use this policy, see the section called “Attach a permissions policy to a secret” (p. 16).

{

"AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets"

},

} ]}

(28)

Example: Wildcards

Example Read one secret (attach to an identity)

You can grant access to a secret by attaching the following policy to an identity. To use this policy, see the section called “Attach a permissions policy to an identity” (p. 16). If you attach this policy to the role EC2RoleToAccessSecrets, it grants the same permissions as the previous policy.

{

"Version": "2012-10-17", "Statement": [

{

"Effect": "Allow",

"Action": "secretsmanager:GetSecretValue", "Resource": "SecretARN"

} ] }

Example: Wildcards

You can use wildcards to include a set of values in a policy element.

Example Access all secrets in a path (attach to identity)

The following policy grants access to retrieve all secrets with a name beginning with "TestEnv/". To use this policy, see the section called “Attach a permissions policy to an identity” (p. 16).

{

"Version": "2012-10-17", "Statement": {

"Effect": "Allow",

"Action": "secretsmanager:GetSecretValue",

"Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*"

}}

Example Access metadata on all secrets (attach to identity)

The following policy grants DescribeSecret and permissions beginning with List: ListSecrets and ListSecretVersionIds. To use this policy, see the section called “Attach a permissions policy to an identity” (p. 16).

{

"Effect": "Allow", "Action": [

"secretsmanager:DescribeSecret", "secretsmanager:List*"

],

"Resource": "*"

}}

Example Match secret name (attach to identity)

The following policy grants all Secrets Manager permissions for a secret by name. To use this policy, see the section called “Attach a permissions policy to an identity” (p. 16).

(29)

Example: Permission to create secrets

To match a secret name, you create the ARN for the secret by putting together the Region, Account ID, secret name, and the wildcard (?) to match individual random characters. Secrets Manager appends six random characters to secret names as part of their ARN, so you can use this wildcard to match those characters. If you use the syntax "another_secret_name-*", Secrets Manager matches not only the intended secret with the 6 random characters, but also matches "another_secret_name-

<anything-here>a1b2c3".

Because you can predict all of the parts of the ARN of a secret except the 6 random characters, using the wildcard character '??????' syntax enables you to securely grant permissions to a secret that doesn't yet exist. Be aware, however, if you delete the secret and recreate it with the same name, the user automatically receives permission to the new secret, even though the 6 characters changed.

{

"Effect": "Allow",

"Action": "secretsmanager:*", "Resource": [

"arn:aws:secretsmanager:Region:AccountId:secret:a_specific_secret_name-a1b2c3", "arn:aws:secretsmanager:Region:AccountId:secret:another_secret_name-??????"

] } ] }

Example: Permission to create secrets

To grant a user permissions to create a secret, we recommend you attach a permissions policy to an IAM group the user belongs to. See IAM user groups.

Example Create secrets (attach to identity)

The following policy grants permission to create secrets and view a list of secrets. To use this policy, see the section called “Attach a permissions policy to an identity” (p. 16).

{

"Effect": "Allow", "Action": [

"secretsmanager:CreateSecret", "secretsmanager:ListSecrets"

],

"Resource": "*"

} ] }

Example: Permissions and VPCs

If you need to access Secrets Manager from within a VPC, you can make sure that requests to Secrets Manager come from the VPC by including a condition in your permissions policies. For more information, see VPC endpoint conditions (p. 36) and VPC endpoint (p. 101).

Make sure that requests to access the secret from other AWS services also come from the VPC, otherwise this policy will deny them access.

(30)

Example: Permissions and VPCs

Example Require requests to come through a VPC endpoint (attach to secret)

The following policy allows a user to perform Secrets Manager operations only when the request comes through the VPC endpoint vpce-1234a5678b9012c. To use this policy, see the section called “Attach a permissions policy to a secret” (p. 16).

{

"Id": "example-policy-1", "Version": "2012-10-17", "Statement": [

{

"Sid": "RestrictGetSecretValueoperation", "Effect": "Deny",

"Principal": "*",

"Action": "secretsmanager:GetSecretValue", "Resource": "*",

"Condition": {

"StringNotEquals": {

"aws:sourceVpce": "vpce-1234a5678b9012c"

} } } ]}

Example Require requests to come from a VPC (attach to secret)

The following policy allows commands to create and manage secrets only when they come from vpc-12345678. In addition, the policy allows operations that use access the secret encrypted value only when the requests come from vpc-2b2b2b2b. You might use a policy like this one if you run an application in one VPC, but you use a second, isolated VPC for management functions. To use this policy, see the section called “Attach a permissions policy to a secret” (p. 16).

{ "Id": "example-policy-2", "Version": "2012-10-17", "Statement": [

{

"Sid": "AllowAdministrativeActionsfromONLYvpc-12345678", "Effect": "Deny",

"Principal": "*", "Action": [

"secretsmanager:Create*", "secretsmanager:Put*", "secretsmanager:Update*", "secretsmanager:Delete*", "secretsmanager:Restore*", "secretsmanager:RotateSecret", "secretsmanager:CancelRotate*", "secretsmanager:TagResource", "secretsmanager:UntagResource"

],

"Resource": "*", "Condition": {

"aws:sourceVpc": "vpc-12345678"

} } }, {

"Sid": "AllowSecretValueAccessfromONLYvpc-2b2b2b2b", "Effect": "Deny",

"Principal": "*",

(31)

Example: Control access to secrets using tags

"Action": [

"secretsmanager:GetSecretValue"

],

"Resource": "*", "Condition": {

"aws:sourceVpc": "vpc-2b2b2b2b"

} } } ] }

Example: Control access to secrets using tags

You can use tags to control access to your secrets. Using tags to control permissions is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome. One strategy is to attach tags to secrets and then grant permissions to an identity when a secret has a speciﬁc tag.

Example Allow access to secrets with a speciﬁc tag (attach to an identity)

The following policy allows DescribeSecret on secrets with a tag with the key "ServerName" and the value "ServerABC". To use this policy, see the section called “Attach a permissions policy to an identity” (p. 16).

{ "Version": "2012-10-17", "Statement": {

"Effect": "Allow",

"Action": "secretsmanager:DescribeSecret", "Resource": "*",

"Condition": { "StringEquals": {

"secretsmanager:ResourceTag/ServerName": "ServerABC"

} } } }

Example: Limit access to identities with tags that match secrets' tags

One strategy is to attach tags to both secrets and IAM identities. Then you create permissions policies to allow operations when the identity's tag matches the secret's tag. For a complete tutorial, see Deﬁne permissions to access secrets based on tags.

Using tags to control permissions is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome. For more information, see What is ABAC for AWS?

Example Allow access to roles that have the same tags as secrets (attach to a secret)

The following policy grants GetSecretValue to account 123456789012 only if the tag

AccessProject has the same value for the secret and the role. To use this policy, see the section called

“Attach a permissions policy to a secret” (p. 16).

(32)

Example: Service principal

"AWS": "123456789012"

},

"Condition": { "StringEquals": {

"aws:ResourceTag/AccessProject": "${ aws:PrincipalTag/AccessProject }"

} },

} }

Example: Service principal

If the resource policy attached to your secret includes an AWS service principal, we recommend that you use the aws:SourceArn and aws:SourceAccount global condition keys. The ARN and account values are included in the authorization context only when a request comes to Secrets Manager from another AWS service. This combination of conditions avoids a potential confused deputy scenario.

Service principals are not typically used as principals in a policy attached to a secret, but some AWS services require it. For information about resource policies that a service requires you to attach to a secret, see the service's documentation.

Example Allow a service to access a secret using a service principal (attach to a secret)

{

"Version": "2012-10-17", "Statement": [

{

"Effect": "Allow", "Principal": { "Service": [

"service-name.amazonaws.com"

] },

"Action": "secretsmanager:GetSecretValue", "Resource": "*",

"Condition": { "ArnLike": {

"aws:sourceArn": "arn:aws:service-name::123456789012:*"

},

"StringEquals": {

"aws:sourceAccount": "123456789012"

} } } ] }

Permissions reference for Secrets Manager

To see the elements that make up a permissions policy, see JSON policy document structure and IAM JSON policy elements reference.

(33)

Secrets Manager actions

To get started writing your own permissions policy, see the section called “Permissions policy examples” (p. 20).

Secrets Manager actions

Actions Description Access

level Resource types (*required)

Condition

keys Dependent

actions Secret* (p. 34) CancelRotateSecretGrants permission to cancel an

in-progress secret rotation Write

secretsmanager:SecretId (p. 35) secretsmanager:resource/

AllowRotationLambdaArn (p. 36) secretsmanager:ResourceTag/

tagkey (p. 35) aws:ResourceTag/

${TagKey} (p. 35)

secretsmanager:SecretPrimaryRegion (p. 35)

Secret* (p. 34) CreateSecret Grants permission to create a

secret that stores encrypted data that can be queried and rotated

Write

secretsmanager:Name (p. 35) secretsmanager:Description (p. 35) secretsmanager:KmsKeyId (p. 35) aws:RequestTag/

${TagKey} (p. 35) aws:ResourceTag/

${TagKey} (p. 35) aws:TagKeys (p. 35)

secretsmanager:ResourceTag/

tag-key (p. 35)

secretsmanager:AddReplicaRegions (p. 35)

secretsmanager:ForceOverwriteReplicaSecret (p. 35)

Secret* (p. 34) DeleteResourcePolicyGrants permission to delete the

resource policy attached to a secret

Permissions management

tagkey (p. 35)

(34)

Secrets Manager actions

Actions Description Access

level Resource types (*required)

Condition

keys Dependent

actions aws:ResourceTag/

${TagKey} (p. 35)

secretsmanager:SecretPrimaryRegion (p. 35) Secret* (p. 34)

DeleteSecret Grants permission to delete a

secret Write

AllowRotationLambdaArn (p. 36)

secretsmanager:RecoveryWindowInDays (p. 35) secretsmanager:ForceDeleteWithoutRecovery (p. 35) secretsmanager:ResourceTag/

${TagKey} (p. 35)

Secret* (p. 34) DescribeSecret Grants permission to retrieve the

metadata about a secret, but not the encrypted data

Read

${TagKey} (p. 35)

GetRandomPasswordGrants permission to generate a random string for use in password creation

Read

GetResourcePolicy Read Secret* (p. 34)

AWS Secrets Manager

AWS Secrets Manager

User Guide

AWS Secrets Manager: User Guide

Table of Contents

What is AWS Secrets Manager?

Basic AWS Secrets Manager scenario

Note

Features of AWS Secrets Manager

Programmatically retrieve encrypted secret values at runtime

Store diﬀerent types of secrets

Encrypt your secret data

Automatically rotate your secrets

Databases with fully conﬁgured and ready-to-use rotation support

Other services with fully conﬁgured and ready-to-use rotation support

Control access to secrets

Compliance with standards for AWS Secrets Manager

Pricing for AWS Secrets Manager

Support and feedback for AWS Secrets Manager

Access Secrets Manager

Secrets Manager console

Command line tools

AWS SDKs

HTTPS Query API

Get started with AWS Secrets Manager

Secrets Manager concepts

Secret

Rotation

Version

AWS Secrets Manager tutorials

Tutorial: Create and retrieve a secret

Prerequisites

Step 1: Create and store your secret in AWS Secrets Manager

To store your secret by using the console

To store your secret by using the CLI

Step 2: Retrieve your secret from AWS Secrets Manager

To retrieve your secret by using the console

To retrieve your secret by using the CLI

Secrets Manager best practices

Authentication and access control for AWS Secrets Manager

Secrets Manager administrator permissions

Permissions to access secrets

Permissions for Lambda rotation functions

Permissions for encryption keys

Attach a permissions policy to an identity

To add or remove permissions on an identity

Attach a permissions policy to a secret

To view, change, or delete the resource policy for a secret (console)

AWS CLI

Example

Example

Example

AWS SDK

AWS managed policies available for use with AWS Secrets Manager

Determine who has permissions to your secrets

To view the resource-based policy for a secret

To determine who has access through identity-based policies

Permissions for users in a diﬀerent account

Step 1: Attach a resource policy to the secret in Account1

Step 2: Add a statement to the key policy for the KMS key in Account1

Step 3: Attach an identity policy to the identity in Account2

Permissions policy examples

Example: Permission to retrieve secret values

Example Read one secret (attach to a secret)

Example Read one secret (attach to an identity)

Example: Wildcards

Example Access all secrets in a path (attach to identity)

Example Access metadata on all secrets (attach to identity)

Example Match secret name (attach to identity)

Example: Permission to create secrets

Example Create secrets (attach to identity)

Example: Permissions and VPCs

Example Require requests to come through a VPC endpoint (attach to secret)

Example Require requests to come from a VPC (attach to secret)

Example: Control access to secrets using tags

Example Allow access to secrets with a speciﬁc tag (attach to an identity)

Example: Limit access to identities with tags that match secrets' tags

Example Allow access to roles that have the same tags as secrets (attach to a secret)

Example: Service principal

Example Allow a service to access a secret using a service principal (attach to a secret)