Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Accès AWS Secrets Manager secrets provenant d'un autre compte
Pour autoriser les utilisateurs d'un compte à accéder aux secrets d'un autre compte (accès entre comptes), vous devez autoriser l'accès dans une stratégie de ressource et dans une stratégie d'identité. Cela diffère de l'octroi d'accès aux identités dans le même compte que le secret.
Cross-account l'autorisation n'est effective que pour les opérations suivantes :
Vous pouvez utiliser le BlockPublicPolicy paramètre associé à l'PutResourcePolicyaction pour protéger vos ressources en empêchant l'accès public d'être accordé par le biais des politiques de ressources directement associées à vos secrets. Vous pouvez également utiliser IAM Access Analyzer pour vérifier l'accès entre comptes.
Vous devez aussi autoriser l'identité à utiliser la clé KMS avec laquelle le secret est chiffré. Cela est dû au fait que vous ne pouvez pas utiliser le Clé gérée par AWS (aws/secretsmanager) pour accéder à plusieurs comptes. Au lieu de cela, vous devez chiffrer votre secret avec une clé KMS que vous créez, puis y attacher une stratégie de clé. La création de clés KMS engendre des frais. Pour modifier la clé de chiffrement d'un secret, consultez Modifier un AWS Secrets Manager secret.
Important
Resource-based les politiques d'octroi d'secretsmanager:PutResourcePolicyautorisations permettent aux administrateurs, même ceux qui utilisent d'autres comptes, de modifier vos politiques basées sur les ressources. Cette autorisation permet aux mandants d'augmenter les autorisations existantes, telles que l'obtention d'un accès administratif complet aux secrets. Nous vous recommandons d'appliquer le principe de l'accès le moins privilégié à vos politiques. Pour de plus amples informations, veuillez consulter Resource-based politiques.
Les exemples de stratégies suivants partent du principe que vous disposez d'un secret et d'une clé de chiffrement dans le Compte1, et d'une identité dans le Compte2 qui doit être autorisée à accéder à la valeur de secret.
Étape 1 : joindre une politique de ressources au secret dans Compte 1
-
La politique suivante permet
Account2àApplicationRolein d'accéder au secret dansAccount1. Pour utiliser cette stratégie, consultez Resource-based politiques.
Étape 2 : ajouter une déclaration à la politique de clé pour la clé KMS dans Compte 1
-
La déclaration de politique de clé suivante permet
Account2àApplicationRolein d'utiliser la clé KMSAccount1pour déchiffrer le secret dansAccount1. Pour utiliser cette déclaration, ajoutez-la à la stratégie de clé de votre clé KMS. Consultez Modification d'une stratégie de clé pour de plus amples informations.{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::Account2:role/ApplicationRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }
Étape 3 : Associez une politique d'identité à l'identité dans Compte 2
-
La politique suivante permet
Account2àApplicationRolein d'accéder au secretAccount1et de déchiffrer la valeur secrète à l'aide de la clé de cryptage qui se trouve également dansAccount1. Pour utiliser cette stratégie, consultez Identity-based politiques. Vous pouvez trouver l'ARN de votre secret dans la console Secrets Manager sur la page de détails du secret sous ARN du secret. Vous pouvez aussi appelerdescribe-secret.
