# Using AWS Secrets Manager managed external secrets to manage Third Party secrets Managed external secrets is a new secret type in AWS Secrets Manager that enables you to store and automatically rotate credentials from integration partners. This feature eliminates the need to create and maintain custom AWS Lambda functions for rotating integration partner secrets. For a complete list of all onboarded partners see [Integration Partners](mes-partners.md). When you build applications on AWS, your workloads often need to interact with third-party applications through secure credentials such as API keys, OAuth tokens, or credential pairs. Previously, you had to develop custom approaches to secure and manage these credentials, including building complex rotation Lambda functions that were unique to each application and required ongoing maintenance. Managed external secrets provides a standardized approach for storing third-party credentials in a predefined format prescribed by each partner. The feature includes automatic rotation that is enabled (by default on the console) during secret creation, complete transparency and user controls for secret management workflows, and the full feature set offered by Secrets Manager including fine-grained permissions management, observability, governance, compliance, disaster recovery, and monitoring controls. ## Key features Managed external secrets offers several key capabilities that simplify third-party credential management: + **Lambda-free managed rotation** eliminates the overhead of creating and managing custom rotation functions. When you create an external, rotation is automatically enabled with no Lambda functions deployed in your account. + **Predefined secret formats** ensure that secrets can be properly associated with the integration partner and include the metadata needed for rotation. Each partner defines the required format. + **Integrated partner ecosystem** provides support for multiple partners through a standardized onboarding process. Partners integrate directly with Secrets Manager to offer programmatic guidance for secret creation and managed rotation capabilities. + **Complete auditability** maintains full transparency through AWS CloudTrail logging for all rotation activities, secret value updates, and management operations. # Managed external secrets Partners Secrets Manager natively integrates with third party applications to rotate secrets held by the partner. Each partner defines the metadata and secret value fields required to rotate the secrets. The secret value contains fields that are required for connecting with your third party client and are stored during the [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) call. The rotation metadata holds the fields that are used to update the secret during rotation and are used in the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call. These fields will be defined by the integration partner to allow managed rotation flows. For rotation to function properly, you must provide Secrets Manager with specific permissions to manage the secret lifecycle. For more information see [Security and Permissions](mes-security.md) The following topics include a description of each of the metadata fields required to rotate the secret as well as a description of each of the fields required in the Secrets Manager secret to rotate. **Topics** | Integration Partner | Secret type | | --- | --- | | Salesforce | [SalesforceClientSecret](mes-partner-salesforce.md) | | BigID | [BigIDClientSecret](mes-partner-BigId.md) | | Snowflake | [SnowflakeKeyPairAuthentication](mes-partner-Snowflake.md) | | MongoDB Atlas | [MongoDBAtlasServiceAccount](mes-partner-MongoDBAtlasServiceAccount.md) | | MongoDB Atlas | [MongoDBAtlasDatabaseUser](mes-partner-MongoDBAtlasDatabaseUser.md) | | Confluent Cloud | [ConfluentCloudApiKey](mes-partner-ConfluentCloudApiKey.md) | # Salesforce Client Secret ## Secret Value Fields The following are the fields that must be contained in the Secrets Manager secret: ``` { "consumerKey": "client ID", "consumerSecret": "client secret", "baseUri": "https://domain.my.salesforce.com", "appId": "app ID", "consumerId": "consumer ID" } ``` consumerKey The consumer key, also known as the client ID, is the credential identifier for the OAuth 2.0 credentials. You can retrieve the consumer key directly from the Salesforce External Client App Manager OAuth settings. consumerSecret The consumer secret, also known as the client secret, is the private password used with the consumer key to authenticate using the OAuth 2.0 client credentials flow. You can retrieve the consumer secret directly from the Salesforce External Client App Manager OAuth settings.. baseUri The base URI is your Salesforce Org's base URL used to interact with Salesforce APIs. This takes the form of the following example: `https://domainName.my.salesforce.com`. appId The App ID is the identifier for your Salesforce External Client Application (ECA). You can retrieve this by calling the Salesforce OAuth Usage endpoint. It must begin with `0x` and contain only alphanumeric characters. This field refers to the external\$1client\$1app\$1identifier in the [Salesforce rotation guide](https://help.salesforce.com/s/articleView?id=xcloud.eca_stage_oauth_credentials.htm&type=5). consumerId The consumer ID is the identifier for your Salesforce External Client Application (ECA) consumer. You can retrieve this by calling the Salesforce OAuth Credentials by App ID endpoint. This field refers to the consumer\$1id in the [Salesforce rotation guide](https://help.salesforce.com/s/articleView?id=xcloud.eca_stage_oauth_credentials.htm&type=5). ## Secret Metadata Fields The following are the metadata fields required to rotate a secret held by Salesforce. ``` { "apiVersion": "v65.0", "adminSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:SalesforceClientSecret" } ``` apiVersion The Salesforce API version is your Salesforce organization's API version. The version should be at least v65.0. It must be in the format `vXX.X` where `X` is a numeric character. adminSecretArn (Optional) The admin secret ARN is the Amazon Resource Name (ARN) for the secret that contains the administrative OAuth credentials that are to used to rotate this Salesforce client secret. At a minimum the admin secret should contain a consumerKey and consumerSecret value within the secret structure. It is an optional field and if omitted, during rotation Secrets Manager will use the OAuth credentials within this secret to authenticate with Salesforce. ## Usage Flow Customers storing Salesforce Secrets in AWS Secrets Manager have an option to rotate a secret with the credentials stored in the same secret or use the credentials in the Admin secret for rotation. You can create your secret using the [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) call with the secret value containing the fields mentioned above and secret type as SalesforceClientSecret. The rotation configurations can be set using a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call. This call requires the specification of the metadata fields as in the example above - If you opt for a rotation using credentials in the same secret, you can skip the adminSecretArn field. Additionally, customers must provide a role ARN in the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call which grants the service the required permissions to rotate the secret. For an example of a permissions policy see [Security and Permissions](mes-security.md). For customers opting to rotate their secrets using a seperate set of credentials (stored in an Admin Secret), be sure to create the Admin Secret in AWS Secrets Manager following the exact same steps as your consumer secret. You must provide the ARN of this Admin Secret in the rotation metadata in a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call for your consumer secret. The rotation logic follows the guidance provided by Salesforce. # Big ID Refresh Token ## Secret Value Fields The following are the fields that must be contained in the Secrets Manager secret: ``` { "hostname": "Host Name", "refreshToken": "Refresh Token" } ``` hostname This is the hostname where your BigID instance is hosted. You must enter the fully qualified domain name of your instance. refreshToken The JWT user refresh token generated in the BigID Console via Administration → Access Management → Select User → Generate Token → Save ## Usage Flow You can create your secret using the [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) call with the secret value containing the fields mentioned above and secret type as BigIDClientSecret. The rotation configurations can be set using a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call. You must also provide a role ARN in the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call which grants the service the required permissions to rotate the secret. For example of a permissions policy see [Security and Permissions](mes-security.md). Note that the rotation metadata field can be left empty for this partner. # Snowflake Key Pair ## Secret Value Fields The following are the fields that must be contained in the Secrets Manager secret: ``` { "account": "Your Account Identifier", "user": "Your user name", "privateKey": "Your private Key", "publicKey": "Your public Key", "passphrase": "Your Passphrase" } ``` user The Snowflake username associated with this key-pair authentication. This user must be configured in Snowflake to accept key-pair authentication, and the public key must be assigned to this user's profile. account Your Snowflake account identifier used to establish the connection. This can be extracted from your Snowflake URL (the portion before .snowflakecomputing.com) privateKey The RSA private key in PEM format used for authentication. The BEGIN/END markers are optional. publicKey The public key counterpart in PEM format corresponding to the private key. The BEGIN/END markers are optional. passphrase (Optional) This field refers to the passphrase used to decrypt the encrypted private key. ## Secret Metadata Fields The following are the metadata fields for Snowflake: ``` { "cryptographicAlgorithm": "Your Cryptographic algorithm", "encryptPrivateKey": "True/False" } ``` cryptographicAlgorithm (Optional) This refers to the algorithm used for key generation. You have a choice of 3 algorithms: `RS256|RS384|RS512` . This field is optional and the default algorithm chosen is RS256. encryptPrivateKey (Optional) This field can be used to choose if you want to encrypt your private key. It is false by default. The passphrase for encryption is randomly generated. ## Usage Flow You can create your secret using the [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) call with the secret value containing the fields mentioned above and secret type as SnowflakeKeyPairAuthentication. The rotation configurations can be set using a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call. You can optionally provide the secret metadata field(s) based on your requirement. You must also provide a role ARN in the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call which grants the service the required permissions to rotate the secret. For example of a permissions policy see [Security and Permissions](mes-security.md). Note that the rotation metadata field can be left empty for this partner. # MongoDB Atlas Service Account Credentials ## Secret Value Fields The following are the fields that must be contained in the Secrets Manager secret: ``` { "clientId": "service account OAuth client ID", "clientSecret": "service account OAuth client secret", "orgId": "Atlas Organization ID" } ``` clientId The MongoDB Atlas service account OAuth client ID. This must start with `mdb_sa_id_` followed by a 24-character hexadecimal string. clientSecret The MongoDB Atlas service account OAuth client secret used for authentication. orgId The 24-character hexadecimal Atlas Organization ID. You can find this in your Atlas Organization Settings. ## Secret Metadata Fields The following are the metadata fields for MongoDB Atlas Service Account: ``` { "adminSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:MongoDBAtlasServiceAccount", "apiVersion": "2025-03-12" } ``` adminSecretArn (Optional) The Amazon Resource Name (ARN) for the secret that contains the administrative service account OAuth credentials used to rotate this service account secret. The admin secret should contain a `clientId` and `clientSecret` value within the secret structure. If omitted, the service account will use its own credentials for self-rotation. apiVersion (Optional) The Atlas Admin API version date in `yyyy-mm-dd` format. This value is used in the `Accept` header as `application/vnd.atlas.{apiVersion}+json`. Defaults to `2025-03-12` if not specified. ## Usage Flow The rotation supports two authentication modes. In self-rotation mode (default), the service account uses its own credentials to create and delete its secrets. This requires the service account to have permissions to manage its own secrets. In admin-assisted rotation mode, a separate admin service account credential stored in another secret is used. This is required when the service account lacks self-management permissions. You can create your secret using the [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) call with the secret value containing the fields mentioned above and secret type as MongoDBAtlasServiceAccount. The rotation configurations can be set using a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call. If you opt for self-rotation, you can omit the optional `adminSecretArn` field. You must provide a role ARN in the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call which grants the service the required permissions to rotate the secret. For an example of a permissions policy see [Security and Permissions](mes-security.md). For customers opting to rotate their secrets using a separate set of credentials (stored in an Admin Secret), create the Admin Secret in AWS Secrets Manager containing the admin service account's `clientId` and `clientSecret`. You must provide the ARN of this Admin Secret in the rotation metadata in a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call for your service account secret. During rotation, the driver creates a new secret for the service account via the Atlas Admin API, verifies the new secret by generating an OAuth token, updates the secret with new credentials, and deletes the old secret. # MongoDB Atlas Database User ## Secret Value Fields The following are the fields that must be contained in the Secrets Manager secret: ``` { "username": "database username", "password": "database password", "clusterUrl": "cluster hostname", "databaseName": "authentication database", "groupId": "Atlas Project ID" } ``` username The MongoDB database username (SCRAM-authenticated). This user must be configured in MongoDB Atlas to accept SCRAM authentication. password The current password for the MongoDB Atlas database user. clusterUrl The MongoDB Atlas cluster hostname, for example `cluster0.abc123.mongodb.net`. Do not include the `mongodb+srv://` prefix. This is used for verifying the new password during rotation. databaseName The authentication database where the user's credentials are stored. Typically `admin` for SCRAM users or `$external` for X.509/LDAP. groupId The 24-character hexadecimal Atlas Project ID (also known as Group ID). You can find this in your Atlas Project Settings. ## Secret Metadata Fields The following are the metadata fields for MongoDB Atlas Database User: ``` { "adminSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:MongoDBAtlasServiceAccount", "apiVersion": "2025-03-12" } ``` adminSecretArn The Amazon Resource Name (ARN) for the secret that contains the Atlas service account OAuth credentials (type: MongoDBAtlasServiceAccount) with Project Database Access Admin permissions. This admin secret is used to authenticate to the Atlas Admin API for password updates. apiVersion (Optional) The Atlas Admin API version date in `yyyy-mm-dd` format. This value is used in the `Accept` header as `application/vnd.atlas.{apiVersion}+json`. Defaults to `2025-03-12` if not specified. ## Usage Flow This rotation type uses a two-secret architecture. An admin secret containing Atlas service account OAuth credentials (`clientId`, `clientSecret`, `serviceAccountId`) is required to authenticate to the Atlas Admin API. The admin secret should be of type MongoDBAtlasServiceAccount. You can create your secret using the [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) call with the secret value containing the fields mentioned above and secret type as MongoDBAtlasDatabaseUser. The rotation configurations can be set using a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call. You must provide the `adminSecretArn` in the rotation metadata. You must also provide a role ARN in the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call which grants the service the required permissions to rotate the secret. For an example of a permissions policy see [Security and Permissions](mes-security.md). Because the admin secret is of a different type (MongoDBAtlasServiceAccount) than the user secret (MongoDBAtlasDatabaseUser), the default rotation role policy scoped by `secretsmanager:resource/Type` will not grant access to the admin secret. You must explicitly provide the rotation role access to the admin secret by adding a statement scoped to the MongoDBAtlasServiceAccount type or by specifying the admin secret ARN directly in the role policy. During rotation, the driver generates a new password, calls the Atlas Admin API to update the database user's password, and verifies the new password by opening a real MongoDB connection to the cluster. Note that there is a propagation delay of 5-10 seconds after the password update before the new password is accepted by the cluster's authentication layer. # Confluent Cloud API Key ## Secret Value Fields The following are the fields that must be contained in the Secrets Manager secret: ``` { "apiKey": "API Key ID", "apiSecret": "API Secret", "serviceAccountId": "Service Account ID", "resourceId": "Resource ID", "environmentId": "Environment ID" } ``` apiKey The Confluent Cloud API Key ID used for authentication. apiSecret The Confluent Cloud API Secret used for authentication. serviceAccountId The ID of the Service Account principal that this API key represents, for example `sa-abc123`. The rotation logic uses this to create new keys for the correct principal. resourceId (Optional) The resource ID for scoping the API key. This can be a Kafka cluster (`lkc-xxxxx`), ksqlDB cluster (`lksqlc-xxxxx`), Schema Registry (`lsrc-xxxxx`), Flink region (`aws.us-west-2`, `azure.centralus`, `gcp.us-central1`), or `Tableflow`. Omit this field for cloud resource management API keys. environmentId (Optional) The Confluent Cloud Environment ID, for example `env-abcde`. Used when creating cluster-scoped keys. ## Secret Metadata Fields The following are the metadata fields for Confluent Cloud API Key: ``` { "adminSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:ConfluentCloudApiKey" } ``` adminSecretArn (Optional) The Amazon Resource Name (ARN) for the secret that contains the administrative Confluent Cloud API Key credentials used to rotate this secret. The admin API key must have CloudClusterAdmin or OrganizationAdmin role to create and delete API keys for Service Accounts. If omitted, the user secret's own credentials are used for self-rotation. ## Usage Flow The rotation supports two modes. In self-rotation mode (default), the user secret's own `apiKey`/`apiSecret` are used to authenticate Confluent API calls for key creation and deletion. The user secret's API key must have sufficient permissions to manage its own Service Account's keys. In admin-secret mode, a separate admin secret containing `apiKey`/`apiSecret` with admin permissions is used instead. You can create your secret using the [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html) call with the secret value containing the fields mentioned above and secret type as ConfluentCloudApiKey. The rotation configurations can be set using a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call. If you opt for self-rotation, you can omit the optional `adminSecretArn` field. You must provide a role ARN in the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call which grants the service the required permissions to rotate the secret. For an example of a permissions policy see [Security and Permissions](mes-security.md). For customers opting to rotate their secrets using a separate set of admin credentials, create the Admin Secret in AWS Secrets Manager containing the admin `apiKey` and `apiSecret`. You must provide the ARN of this Admin Secret in the rotation metadata in a [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) call for your API key secret. During rotation, the driver creates a new API key for the target Service Account via the Confluent Cloud API, verifies the new key, updates the secret with new credentials, and deletes the old API key. # Security and permissions Managed external secrets does not require you to share admin-level privileges of your third party application accounts with AWS. Instead, the rotation process uses credentials and metadata you provide to make authorized API calls to the third party application for credential updates and validation. Managed external secrets maintain the same security standards as other Secrets Manager secret types. Secret values are encrypted at rest using your KMS keys and in transit using TLS. Access to secrets is controlled through IAM policies and resource-based policies. When using a Customer Managed Key to encrypt your secret, you will need to update the IAM policy of the rotation role and CMK trust policy to provide the required permissions to ensure successful rotation. For rotation to function properly, you must provide Secrets Manager with specific permissions to manage the secret lifecycle. These permissions can be scoped to individual secrets and follow the principle of least privilege. The rotation role you provide is validated during setup and used exclusively for rotation operations. You can restrict the IP ingress to your external resource by only allowing the [AWS IP ranges](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) for EC2 in the region where your secret exists. This list of IP ranges can change so you should refresh your ingress rules periodically. AWS Secrets Manager also offers single touch solutions to create the IAM policy with the permissions necessary to manage the secret when creating the secret through the Secrets Manager console. The permissions for this role are scoped down for each integration partner in each region. **Example Permissions Policy:** ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowRotationAccess", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage" ], "Resource": "*", "Effect": "Allow", "Condition": { "StringEquals": { "secretsmanager:resource/Type": "SalesforceClientSecret" } } }, { "Sid": "AllowPasswordGenerationAccess", "Action": [ "secretsmanager:GetRandomPassword" ], "Resource": "*", "Effect": "Allow" } ] } ``` Note: The list of secret types that are available for secretsmanager:resource/Type can be found in [Integration Partners](mes-partners.md). **Example Trust Policy:** ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "SecretsManagerPrincipalAccess", "Effect": "Allow", "Principal": { "Service": "secretsmanager.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "ArnLike": { "aws:SourceArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:*" } } } ] } ``` # Monitor and troubleshoot managed external secrets Managed external secrets provide comprehensive monitoring capabilities through AWS CloudTrail logs and Amazon CloudWatch metrics. All rotation activities are logged with detailed information about success, failure, and any errors encountered during the process. Common issues in the rotation workflow include an incorrect configuration of role permissions or the secret value. Failure to set these fields is the format specified by the integration partners can cause rotation failures, as the service will be unable to access the secret or connect with the integration partner client to update the secret. Other issues could be network connectivity problems, credential expiration, or partner service availability. The managed rotation service includes retry logic and error handling to maximize reliability You can monitor rotation schedules, success rates, and performance metrics through Amazon CloudWatch. You can configure custom alarms through [event bridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-pattern.html) to alert you of rotation failures or other issues that require attention. # Migrating existing secrets You have an option to migrate your existing partner secrets to managed external secrets. This can be done with an [UpdateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_UpdateSecret.html) call. You must update the secret value and metadata as mentioned in the guide. If you already have custom rotation logic set up for these secrets, you must first cancel the rotation using a [CancelRotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CancelRotateSecret.html) call. # Limitations and considerations Managed external secrets does not support ephemeral secrets with lifespans less than four hours. Secrets associated with public key infrastructure certificates are also not supported. The managed external secrets are supported only for partners that have onboarded with AWS Secrets Manager. For a complete list, see [Integration Partners](mes-partners.md). Don't see your partner on the list? [Tell them to Onboard to AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/mes-onboarding/secrets-manager-mes-onboarding.html) If you update or rotate secret values directly from the partner client service outside of the Secrets Manager rotation engine, the synchronization between systems may break. While Secrets Manager provides console warnings and programmatic prevention for manual secret value updates, you can still modify values directly in your third party application. To re-establish synchronization after out-of-band updates, you must update the secret value to reflect the correct secret and then invoke the [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html) API to ensure continued successful rotations.