Acesso a segredos do AWS Secrets Manager a partir de uma conta diferente - AWS Secrets Manager

Acesso a segredos do AWS Secrets Manager a partir de uma conta diferente

Para permitir que os usuários de uma conta acessem segredos em outra conta (acesso entre contas), é necessário 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:

É possível usar o parâmetro BlockPublicPolicy com a ação PutResourcePolicy para ajudar a proteger seus recursos impedindo que o acesso público seja concedido por meio de políticas de recursos diretamente vinculadas aos seus segredos. Você também pode usar o analisador de acesso do IAM 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 Modificação de um segredo do AWS Secrets Manager.

Importante

Políticas baseadas em recursos que concedem a permissão secretsmanager:PutResourcePolicy dão às entidades principais, mesmo aquelas em outras contas, a capacidade de modificar suas políticas baseadas em recursos. Essa permissão permite que as entidades principais escalem as permissões existentes, como obter acesso administrativo total aos segredos. Recomendamos que você aplique o princípio do acesso de privilégio mínimo à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 seguinte política permite que ApplicationRole da Conta2 acesse o segredo da Conta1. Para usar essa política, consulte Políticas baseadas em recursos.

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ApplicationRole" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] }
Etapa 2: adicionar uma instrução à política de chaves para a chave KMS na Conta1
  • A seguinte declaração de política de chave permite que ApplicationRole da Conta2 use a chave KMS da Conta1 para descriptografar o segredo da Conta1. 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 seguinte política permite que ApplicationRole da Conta2 acesse o segredo da Conta1 e descriptografe o valor do segredo usando a chave de criptografia que também está na Conta1. 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, é possível chamar 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" } ] }