Accede a AWS Secrets Manager los secretos desde una cuenta diferente - AWS Secrets Manager

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Accede a AWS Secrets Manager los secretos desde una cuenta diferente

Para permitir que los usuarios de una cuenta de obtengan acceso a otra cuenta (acceso entre cuentas), debe permitir el acceso tanto en una política de recursos como en una política de identidad. Esto es diferente de conceder acceso a identidades en la misma cuenta que el secreto.

El permiso entre cuentas solo es efectivo para las siguientes operaciones:

Puedes usar el BlockPublicPolicy parámetro junto con la PutResourcePolicyacción para proteger tus recursos impidiendo que se conceda el acceso público a través de las políticas de recursos que están directamente asociadas a tus secretos. También puede usar IAM Access Analyzer para verificar el acceso entre cuentas.

También debe permitir que la identidad utilice la clave de KMS con la que está cifrado el secreto. Esto se debe a que no puede usar el Clave administrada de AWS (aws/secretsmanager) para el acceso entre cuentas. En su lugar, debe cifrar su secreto con una clave de KMS que cree y, a continuación, adjuntarle una política de clave. Existe un cargo por la creación de claves de KMS. Para cambiar la clave de cifrado de un secreto, consulte Modificar un AWS Secrets Manager secreto.

importante

Las políticas basadas en recursos que otorgan secretsmanager:PutResourcePolicy permisos permiten a los directores, incluso a los de otras cuentas, modificar sus políticas basadas en recursos. Este permiso permite a los directores ampliar los permisos existentes, por ejemplo, obtener acceso administrativo total a los secretos. Le recomendamos que aplique el principio del acceso menos privilegiado a sus políticas. Para obtener más información, consulte Políticas basadas en recursos.

Las siguientes políticas de ejemplo suponen que tiene un secreto y una clave de cifrado en la Account1, y una identidad en la Account2 a la que desea permitir acceder al valor secreto.

Paso 1: adjunte una política de recursos al secreto de Account1

  • La siguiente política permite ApplicationRole acceder Account2 a la entrada secretaAccount1. Para utilizar esta política, visite Políticas basadas en recursos.

    JSON
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::Account2:role/ApplicationRole"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}
Paso 2: agregue una instrucción a la política clave de la clave de KMS de Account1

  • La siguiente instrucción de política de claves permite que ApplicationRole en Account2 use la clave de KMS en Account1 para descifrar el secreto en Account1. Para utilizar esta instrucción, agréguela a la política de claves de la clave de KMS. Para obtener más información, consulte Cambiar una política de claves.

    {
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::Account2:role/ApplicationRole"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}
Paso 3: adjunte una política de identidad a la identidad de Account2

  • La siguiente política permite que ApplicationRole en Account2 acceda al secreto de Account1 y descifre el valor secreto mediante la clave de cifrado que también está en Account1. Para utilizar esta política, visite Políticas basadas en identidad. Puede encontrar el ARN para su secreto en la consola de Secrets Manager en la página de detalles secretos en ARN del secreto. También puede llamar a 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"
    }
  ]
}