Acesse AWS Secrets Manager segredos de uma conta diferente - AWS Secrets Manager

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Acesse AWS Secrets Manager segredos de uma conta diferente

Para permitir que os usuários de uma conta acessem segredos em outra conta (acesso entre contas), você deve permitir o acesso em uma política de recursos e em uma política de identidade. Isso é diferente de conceder acesso a identidades na mesma conta do segredo.

A permissão entre contas é efetiva apenas nas seguintes operações:

Você pode usar o BlockPublicPolicy parâmetro com a PutResourcePolicyação para ajudar a proteger seus recursos, impedindo que o acesso público seja concedido por meio das políticas de recursos diretamente vinculadas aos seus segredos. Você também pode usar o IAM Access Analyzer para verificar o acesso entre contas.

Você também deve permitir que a identidade use a chave do KMS com a qual o segredo está criptografado. Isso ocorre porque você não pode usar o Chave gerenciada pela AWS (aws/secretsmanager) para acesso entre contas. Em vez disso, você precisa criptografar o segredo com uma chave do KMS que criar e, em seguida, anexar uma política de chave a ele. Existe uma cobrança pela criação de chaves do KMS. Para alterar a chave de criptografia de um segredo, consulte Modificar um AWS Secrets Manager segredo.

Importante

Políticas baseadas em recursos que concedem secretsmanager:PutResourcePolicy permissão dão aos diretores, mesmo aqueles em outras contas, a capacidade de modificar suas políticas baseadas em recursos. Essa permissão permite que os diretores escalem as permissões existentes, como obter acesso administrativo total aos segredos. Recomendamos que você aplique o princípio do acesso menos privilegiado às suas políticas. Para obter mais informações, consulte Políticas baseadas em recursos.

Os exemplos de políticas a seguir supõem que você tenha um segredo e uma chave de criptografia na Conta1 e uma identidade na Conta2, à qual você quer permitir acesso ao valor do segredo.

Etapa 1: anexar uma política de recursos ao segredo na Conta1

  • A política a seguir permite que Account2 a ApplicationRole entrada secreta acesse a entrada secretaAccount1. Para usar essa política, consulte Políticas baseadas em recursos.

    JSON
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::Account2:role/ApplicationRole"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}
Etapa 2: adicionar uma instrução à política de chaves para a chave KMS na Conta1

  • A instrução de política de chave a seguir permite que o ApplicationRole na Account2 use a chave do KMS na Account1 para descriptografar o segredo na Account1. Para usar essa declaração, adicione-a à política de chaves para sua chave do KMS. Para obter mais informações, consulte Alterar uma política de chaves.

    {
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::Account2:role/ApplicationRole"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}
Etapa 3: anexar uma política de identidade à identidade na Conta2

  • A política a seguir permite que o ApplicationRole na Account2 acesse o segredo na Account1 e descriptografe o valor do segredo usando a chave de criptografia, que também está na Account1. Para usar essa política, consulte Políticas baseadas em identidade. É possível encontrar o ARN do seu segredo no console do Secrets Manager na página de detalhes do segredo em ARN do segredo. Como alternativa, você pode chamar describe-secret.

    JSON
    {
  "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"
    }
  ]
}