Ejemplos de políticas de permisos para AWS Secrets Manager - 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 AWS KMS clave específica para cifrar los secretosEjemplo: permisos y VPCEjemplo: controlar el acceso a los secretos mediante etiquetasEjemplo: limitar el acceso a identidades con etiquetas que coincidan con las etiquetas de los secretosEjemplo: Entidad principal de servicio

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.

Ejemplos de políticas de permisos para AWS Secrets Manager

Una política de permisos es texto estructurado JSON. Consulte Estructura del documento de política JSON.

Las políticas de permisos que se adjuntan a los recursos e identidades son muy similares. Algunos de los elementos que se incluyen en una política de acceso a los secretos incluyen:

  • Principal: a quién conceder acceso. Consulte Especificación de una entidad principal en la Guía del usuario de IAM. Cuando adjunta una política a una identidad, no incluye un elemento Principal en la política.

  • Action: lo que pueden hacer. Consulte Acciones de Secrets Manager.

  • Resource: a qué secretos pueden acceder. Consulte Recursos de Secrets Manager.

    El carácter comodín (*) tiene un significado diferente dependiendo de a qué adjunte la política:

    • En una política adjunta a un secreto, * significa que la política se aplica a este secreto.

    • En una política adjunta a una identidad, * significa que la política se aplica a todos los recursos, incluidos los secretos, de la cuenta.

Para adjuntar una política a un secreto, consulte Adición de una política de permisos a un secreto de AWS Secrets Manager.

Para adjuntar una política a una identidad, consulte Adjuntar una política de permisos a una identidad.

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 Adición de una política de permisos a un secreto de AWS Secrets Manager y Adjuntar una política de permisos a una identidad.

En los siguientes ejemplos, se muestran dos maneras diferentes de conceder acceso a un secreto. El primer ejemplo es una política basada en recursos que puede adjuntar a un secreto. Este ejemplo es útil cuando desea conceder acceso a un secreto único a varios usuarios o roles. El segundo ejemplo es una política basada en identidades que puede adjuntar a un usuario o rol en IAM. 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 (adjuntar a un secreto)

Puede conceder acceso a un secreto adjuntando la siguiente política al secreto. Para utilizar esta política, visite Adición de una política de permisos a un secreto de AWS Secrets Manager.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}
ejemplo Lea un secreto cifrado mediante una clave administrada por el cliente (adjunte a la identidad)

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. Para utilizar esta política, visite Adjuntar una política de permisos 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 Lea y describa un secreto (adjúntelo a una identidad)

Puede conceder acceso a un secreto adjuntando la siguiente política una identidad. Para utilizar esta política, visite Adjuntar una política de permisos a 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 (adjuntar a la identidad)

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. . Para utilizar esta política, visite Adjuntar una política de permisos a una identidad. 

{
  "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 (adjuntar a la identidad)

La siguiente política otorga acceso para recuperar todos los secretos cuyo nombre comience por "TestEnv/». Para utilizar esta política, visite Adjuntar una política de permisos a una identidad.

{
  "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 (adjuntar a la identidad)

Las siguientes políticas conceden DescribeSecret y permisos comenzando con List: ListSecrets y ListSecretVersionIds. Para utilizar esta política, visite Adjuntar una política de permisos a una identidad.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:DescribeSecret",
      "secretsmanager:List*"
    ],
    "Resource": "*"
  }
}
ejemplo Coincidir el nombre secreto (adjuntar a la identidad)

La siguiente política concede permisos de Secrets Manager para un secreto por su nombre. Para utilizar esta política, visite Adjuntar una política de permisos a una 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 (adjuntar a la identidad)

La siguiente política concede permiso para crear secretos y ver una lista de secretos. Para utilizar esta política, visite Adjuntar una política de permisos a una identidad.

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

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

importante

Para denegar una clave gestionada 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 AWS KMS en la Guía para AWS Key Management Service desarrolladores.

ejemplo Denegar la clave AWS gestionada aws/secretsmanager (adjuntarla a la identidad)

La siguiente política muestra cómo denegar el uso de la clave AWS administrada aws/secretsmanager para crear o actualizar secretos. Esto significa que los secretos se deben cifrar mediante una clave gestionada por el cliente. Si la aws/secretsmanager clave 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 aws/secretsmanager gestionada. La segunda declaración deniega las solicitudes de creación de secretos que no incluyan una clave de KMS, porque Secrets Manager la interpreta como la clave AWS aws/secretsmanager gestionada.

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

Ejemplo: permisos y VPC

Si necesita acceder a Secrets Manager desde una VPC, puede asegurarse de que las solicitudes a Secrets Manager provengan de la VPC mediante la inclusión de una condición en las políticas de permisos. Para obtener más información, consulte Condiciones del punto de enlace de la VPC y Uso de un punto de conexión de VPC de AWS Secrets Manager.

Asegúrese de que las solicitudes de acceso al secreto desde otros AWS servicios también provengan de la VPC; de lo contrario, esta política les negará el acceso.

ejemplo Requerir que las solicitudes lleguen a través de un punto de enlace de la VPC (adjuntar a secreto)

La siguiente política permite a un usuario realizar operaciones de Secrets Manager solo cuando la solicitud llega a través del punto de enlace de la VPC vpce-1234a5678b9012c. Para utilizar esta política, visite Adición de una política de permisos a un secreto de AWS Secrets Manager.

{
  "Id": "example-policy-1",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictGetSecretValueoperation",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-1234a5678b9012c"
        }
      }
    }
  ]
}
ejemplo Requerir que las solicitudes provengan de una VPC (adjuntar al secreto)

La siguiente política permite utilizar comandos para crear y administrar secretos sólo cuando proceden de vpc-12345678. Además, la política permite operaciones que utilizan el acceso al valor cifrado del secreto solo cuando las solicitudes proceden de vpc-2b2b2b2b. Podría utilizar una política como esta en caso de que ejecute una aplicación en una VPC, pero utiliza una segunda VPC aislada para funciones de administración. Para utilizar esta política, visite Adición de una política de permisos a un secreto de AWS Secrets Manager.

{
  "Id": "example-policy-2",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAdministrativeActionsfromONLYvpc-12345678",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:Create*",
        "secretsmanager:Put*",
        "secretsmanager:Update*",
        "secretsmanager:Delete*",
        "secretsmanager:Restore*",
        "secretsmanager:RotateSecret",
        "secretsmanager:CancelRotate*",
        "secretsmanager:TagResource",
        "secretsmanager:UntagResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-12345678"
        }
      }
    },
    {
      "Sid": "AllowSecretValueAccessfromONLYvpc-2b2b2b2b",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpc": "vpc-2b2b2b2b"
        }
      }
    }
  ]
}

Ejemplo: controlar el acceso a los secretos mediante etiquetas

Puede usar etiquetas para controlar el acceso a sus secretos. Usar etiquetas para controlar los permisos es útil en entornos que están creciendo rápidamente y ayuda con situaciones en las que la administración de políticas resulta engorrosa. Una estrategia consiste en adjuntar etiquetas a los secretos y luego conceder permisos a una identidad cuando un secreto tiene una etiqueta específica.

ejemplo Permitir el acceso a los secretos con una etiqueta específica (adjuntar a una identidad)

La siguiente política permite DescribeSecret los secretos con una etiqueta con la clave "" y el valor ServerName"ServerABC». Para utilizar esta política, visite Adjuntar una política de permisos a una identidad.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "secretsmanager:DescribeSecret",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "secretsmanager:ResourceTag/ServerName": "ServerABC"
      }
    }
  }
}

Ejemplo: limitar el acceso a identidades con etiquetas que coincidan con las etiquetas de los secretos

Una estrategia es adjuntar etiquetas tanto a los secretos como a las identidades de IAM. A continuación, creará políticas de permisos para permitir operaciones cuando la etiqueta de la identidad coincida con la etiqueta del secreto. Para ver un tutorial completo, consulte Defina permisos para acceder a los secretos basados en las etiquetas.

Usar etiquetas para controlar los permisos es útil en entornos que están creciendo rápidamente y ayuda con situaciones en las que la administración de políticas resulta engorrosa. Para obtener más información, consulte ¿Qué es ABAC para AWS?

ejemplo Permitir el acceso a roles que tienen las mismas etiquetas que los secretos (adjuntar a un secreto)

La siguiente política concede GetSecretValue a la cuenta 123456789012 solo si la etiqueta AccessProject tiene el mismo valor para el secreto y el rol. Para utilizar esta política, visite Adición de una política de permisos a un secreto de AWS Secrets Manager.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "123456789012"
    },
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/AccessProject": "${ aws:PrincipalTag/AccessProject }"
      }
    },
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "*"
  }
}

Ejemplo: Entidad principal de servicio

Si la política de recursos adjunta a su secreto incluye un principal de AWS servicio, le recomendamos que utilice las claves de condición SourceAccount global aws: SourceArn y aws:. Los valores del ARN y de la cuenta se incluyen en el contexto de la autorización solo cuando Secrets Manager recibe una solicitud procedente de otro servicio de AWS . Esta combinación de condiciones evita un potencial escenario de suplente confuso.

Si un ARN de recurso incluye caracteres que no están permitidos en una política de recursos, no puede utilizar ese ARN de recurso en el valor de la aws:SourceArn clave de condición. En cambio, utilice la clave de condición aws:SourceAccount. Para obtener más información, consulte los requisitos IAM.

Los directores de servicio no suelen utilizarse como principales en una política asociada a un secreto, pero algunos AWS servicios sí lo exigen. Para obtener información sobre las políticas de recursos que un servicio requiere que se adjunten a un secreto, consulte la documentación del servicio.

ejemplo Permitir que un servicio acceda a un secreto mediante una entidad principal de servicio (adjuntar a un secreto)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "service-name.amazonaws.com"
        ]
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:sourceArn": "arn:aws:service-name::123456789012:*"
        },
        "StringEquals": {
          "aws:sourceAccount": "123456789012"
        }
      }

    }
  ]
}