View a markdown version of this page

Accesso AWS Secrets Manager segreti di un altro account - AWS Secrets Manager

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Accesso AWS Secrets Manager segreti di un altro account

Per consentire agli utenti in un account di accedere ai segreti in un altro account (accesso tra account), è necessario consentire l'accesso sia in una policy delle risorse che in una policy di identità. Ciò è diverso dalla concessione dell'accesso alle identità nello stesso account del segreto.

Cross-account l'autorizzazione è valida solo per le seguenti operazioni:

È possibile utilizzare il BlockPublicPolicy parametro insieme all'PutResourcePolicyazione per proteggere le risorse impedendo che l'accesso pubblico venga concesso tramite le politiche relative alle risorse direttamente collegate ai segreti. Puoi anche utilizzare IAM Access Analyzer per verificare l'accesso tra account.

È inoltre necessario consentire all'identità di utilizzare la chiave KMS con cui il segreto è crittografato. Questo perché non puoi usare Chiave gestita da AWS (aws/secretsmanager) per l'accesso tra account diversi. È invece necessario crittografare il segreto con una chiave KMS creata e quindi allegare ad esso un criterio chiave. È previsto un addebito per la creazione di chiavi KMS. Per modificare la chiave di crittografia per un segreto, vedere Modificare un AWS Secrets Manager Secret.

Importante

Resource-based le politiche che concedono secretsmanager:PutResourcePolicy l'autorizzazione offrono ai responsabili, anche a quelli di altri account, la possibilità di modificare le politiche basate sulle risorse. Questa autorizzazione consente ai responsabili di aumentare le autorizzazioni esistenti, ad esempio ottenere l'accesso amministrativo completo ai segreti. Ti consigliamo di applicare il principio dell'accesso minimo con privilegi alle tue politiche. Per ulteriori informazioni, consulta Resource-based politiche.

I criteri di esempio seguenti presuppongono di disporre di una chiave segreta e di crittografia in Account1, e un'identità in Account2 che vuoi consentire ad accedere al valore segreto.

Passaggio 1: allega una politica delle risorse al secret in Account 1

  • La seguente politica consente ApplicationRole a In Account2 di accedere al secret inAccount1. Per utilizzare questa policy, consultare Resource-based politiche.

    JSON
    {
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/ApplicationRole"
            },
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "*"
        }
    ]
}
Fase 2: Aggiungere una dichiarazione alla policy chiave per la chiave KMS Account 1

  • La seguente dichiarazione sulla politica chiave consente ApplicationRole di Account2 utilizzare la chiave KMS Account1 per decrittografare il segreto in. Account1 Per utilizzare questa istruzione, aggiungerla al criterio chiave per la chiave KMS. Per ulteriori informazioni, vedere Modifica di una policy delle chiavi. Le autorizzazioni della chiave KMS di cui ha bisogno principalmente dipendono dalle operazioni che esegue sul segreto. Per leggere il valore segreto, il principale deve. kms:Decrypt Se il principale crea o modifica anche il valore segreto (ad esempio, withPutSecretValue,UpdateSecret, orCreateSecret), concedi anchekms:GenerateDataKey. Per le autorizzazioni relative alle chiavi KMS richieste da ciascuna operazione, vedi. Autorizzazioni per la chiave KMS

    {
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::Account2:role/ApplicationRole"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}
Fase 3: Allegare una politica di identità all'identità in Account 2

  • La seguente politica consente di accedere ApplicationRole Account2 all'ingresso segreto Account1 e di decrittografare il valore segreto utilizzando la chiave di crittografia anch'essa presente in. Account1 Per utilizzare questa policy, vedere Identity-based politiche. Puoi trovare l'ARN per il tuo segreto nella console di Secrets Manager nella pagina dei dettagli segreti sotto ARN del segreto. In alternativa, è possibile chiamare describe-secret.

    JSON
    {
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf"
        },
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:aws:kms:us-east-1:123456789012:key/EncryptionKey"
        }
    ]
}