Políticas basadas en identidad - AWS Secrets Manager
Ejemplo: permiso para recuperar valores secretosEjemplo: permiso para leer y describir secretos individualesEjemplo: permiso para recuperar un grupo de valores secretos en un loteEjemplo: comodinesEjemplo: permiso para crear secretosEjemplo: denegar una clave AWS KMS específica para cifrar secretos

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.

Políticas basadas en identidad

Puede adjuntar políticas de permisos a las identidades, usuarios, grupos, roles, servicios y recursos de IAM. En una política basada en la identidad, se especifica a qué secretos tiene acceso la identidad y las acciones que la identidad puede realizar en los secretos. Para obtener más información, consulte Añadir y eliminar permisos de identidad de IAM.

Puede conceder permisos a un rol que representa a una aplicación o usuario en otro servicio. Por ejemplo, una aplicación que se ejecuta en una instancia de Amazon EC2 puede necesitar acceso a una base de datos. Puede crear un rol de IAM asociado al perfil de instancia de EC2 y, a continuación, utilizar una política de permisos para conceder al rol acceso al secreto que contiene las credenciales para la base de datos. Para obtener más información, consulte Uso de un rol de IAM para conceder permisos a aplicaciones que se ejecutan en instancias de Amazon EC2. Otros servicios a los que puede adjuntar roles para incluir Amazon Redshift, AWS Lambda, y Amazon ECS.

Puede conceder permisos a usuarios autenticados por un sistema de identidad distinto de IAM. Por ejemplo, puede asociar roles de IAM a usuarios de aplicaciones móviles que inician sesión con Amazon Cognito. El rol concede credenciales temporales a la aplicación con los permisos en la política de permisos del rol. A continuación, puede utilizar una política de permisos para conceder al rol acceso al secreto. Para obtener más información, consulte Proveedores de identidad y federación.

Puede utilizar políticas basadas en identidad para:

  • Conceder acceso por identidad a varios secretos.

  • Controlar quién puede crear nuevos secretos y quién puede acceder a secretos que aún no se han creado.

  • Conceder a un grupo de IAM acceso a secretos.

Ejemplo: permiso para recuperar valores secretos

Para conceder permiso para recuperar valores secretos, puede adjuntar políticas a secretos o identidades. Para obtener ayuda para determinar el tipo de política que se va a utilizar, consulte Políticas basadas en identidad y políticas basadas en recursos. Para obtener información sobre cómo adjuntar una política a una identidad, consulte Políticas basadas en recursos y Políticas basadas en identidad.

Este ejemplo es útil cuando desea conceder acceso a un grupo de IAM. Para conceder permiso para recuperar un grupo de secretos en una llamada a la API por lotes, consulte Ejemplo: permiso para recuperar un grupo de valores secretos en un lote.

ejemplo Leer un secreto cifrado mediante una clave administrada por el cliente

Si un secreto se cifra con una clave administrada por el cliente, puede conceder acceso para leer el secreto si adjunta la siguiente política a una identidad. \

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "SecretARN"
},
{
  "Effect": "Allow",
  "Action": "kms:Decrypt",
  "Resource": "KMSKeyARN"
}
]
}

Ejemplo: permiso para leer y describir secretos individuales

ejemplo Leer y describir un secreto

Puede conceder acceso a un secreto adjuntando la siguiente política una identidad.

{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:GetSecretValue",
      "secretsmanager:DescribeSecret"
      ],
    "Resource": "SecretARN"
  }
]
}

Ejemplo: permiso para recuperar un grupo de valores secretos en un lote

ejemplo Leer un grupo de secretos en un lote

Puedes otorgar acceso para recuperar un grupo de secretos en una llamada a la API por lotes al adjuntar la siguiente política a una identidad La política restringe a la persona que llama para que solo pueda recuperar los secretos especificados por SecretARN1, SecretARN2 y SecretARN3incluso si la llamada por lotes incluye otros secretos. Si la persona que llama también solicita otros secretos en la llamada a la API por lotes, Secrets Manager no los devolverá. Para obtener más información, consulte BatchGetSecretValue. 

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:BatchGetSecretValue",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
},
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": [
    "SecretARN1",
    "SecretARN2",
    "SecretARN3"
    ]
}
]
}

Ejemplo: comodines

Puede utilizar comodines para incluir un conjunto de valores en un elemento de política.

ejemplo Acceder a todos los secretos de una ruta

La siguiente política concede acceso para recuperar todos los secretos con un nombre que comience con “TestEnv/”.

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:Region:AccountId:secret:TestEnv/*"
}
}
ejemplo Acceder a metadatos en todos los secretos

Las siguientes políticas conceden DescribeSecret y permisos comenzando con List: ListSecrets y ListSecretVersionIds.

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
  "secretsmanager:DescribeSecret",
  "secretsmanager:List*"
],
"Resource": "*"
}
}
ejemplo Coincidir el nombre del secreto

La siguiente política concede permisos de Secrets Manager para un secreto por su nombre. Para utilizar esta política, visite Políticas basadas en identidad.

Para que coincida con un nombre secreto, cree el ARN para el secreto juntando la región, el ID de cuenta, el nombre secreto y el comodín (?) para que coincida con caracteres aleatorios individuales. Secrets Manager agrega seis caracteres aleatorios a nombres secretos como parte de su ARN, por lo que puede usar este comodín para hacer coincidir esos caracteres. Si utiliza la sintaxis "another_secret_name-*", Secrets Manager coincide con no solo el secreto previsto con los 6 caracteres aleatorios, sino que también coincide con "another_secret_name-<anything-here>a1b2c3".

Debido a que puede predecir todas las partes del ARN de un secreto, excepto por los 6 caracteres aleatorios, utilizando el carácter comodín '??????' le permite conceder permisos de forma segura a un secreto que no existe todavía. Tenga en cuenta, no obstante, que si elimina el secreto y vuelve a crearlo con el mismo nombre, el usuario recibe automáticamente permiso para el nuevo secreto, incluso aunque los seis caracteres han cambiado. 

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": "secretsmanager:*",
  "Resource": [
    "arn:aws:secretsmanager:Region:AccountId:secret:a_specific_secret_name-a1b2c3",
    "arn:aws:secretsmanager:Region:AccountId:secret:another_secret_name-??????"
  ]
}
]
}

Ejemplo: permiso para crear secretos

Para conceder permisos a un usuario para crear un secreto, recomendamos adjuntar una política de permisos a un grupo de IAM al que pertenezca el usuario. Consulte Grupos de usuarios de IAM.

ejemplo Crear secretos

La siguiente política concede permiso para crear secretos y ver una lista de secretos. Para utilizar esta política, visite Políticas basadas en identidad.

{
"Version": "2012-10-17",
"Statement": [
{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:CreateSecret",
    "secretsmanager:ListSecrets"
  ],
  "Resource": "*"
}
]
}

Ejemplo: denegar una clave AWS KMS específica para cifrar secretos

importante

Para denegar una clave administrada por el cliente, le recomendamos que restrinja el acceso mediante una política de claves o una concesión de claves. Para obtener más información, consulte Autenticación y control de acceso para AWS KMS en la Guía del desarrollador de AWS Key Management Service.

ejemplo Denegar la clave AWS administrada por aws/secretsmanager

La siguiente política muestra cómo denegar el uso de la clave de aws/secretsmanager administrada por AWS para crear o actualizar secretos. Esto significa que los secretos deben cifrarse con una clave administrada por el cliente. Si la clave aws/secretsmanager existe, también debe incluir su ID de clave. También incluye la cadena vacía porque Secrets Manager la interpreta como la clave aws/secretsmanager administrada por AWS. La segunda afirmación deniega las solicitudes de creación de secretos que no incluyan una clave de KMS, porque Secrets Manager la interpreta como la clave de aws/secretsmanager administrada por AWS.

{
"Version": "2012-10-17",
"Statement": [
  {
      "Sid": "RequireCustomerManagedKeysOnSecrets",
      "Effect": "Deny",
      "Action": [
          "secretsmanager:CreateSecret",
          "secretsmanager:UpdateSecret"
      ],
      "Resource": "*",
      "Condition": {
          "ForAnyValue:StringLikeIfExists": {
              "secretsmanager:KmsKeyId": [
                  "*alias/aws/secretsmanager",
                  "*<key_ID_of_the_AWS_managed_key>",
                  ""
              ]
          }
      }
  },
  {
      "Sid": "RequireKmsKeyIdParameterOnCreate",
      "Effect": "Deny",
      "Action": "secretsmanager:CreateSecret",
      "Resource": "*",
      "Condition": {
          "Null": {
              "secretsmanager:KmsKeyId": "true"
          }
      }
  }
]
}