Skip to main content
Cada endpoint de secretos comprueba una acción de IAM antes de hacer cualquier cosa. Esta es la lista completa, no hay otros, y ningún punto final se salta la comprobación.
La referencia de la API muestra la acción en la página propia de cada punto final, por lo que no tiene que volver aquí para buscar una. Ambos provienen del mismo lugar: la llamada de autorización en el servicio, leída en el momento de la compilación.

Las acciones

Las operaciones en un secreto específico se autorizan contra CRN de ese secreto, con las etiquetas del secreto disponibles como contexto de condición. Solo las dos operaciones a nivel de colección no lo son.

Describir un secreto no lo lee

secrets:GetSecretValue es una acción diferente de secrets:DescribeSecret, y la división se ejecuta a través de la API: la respuesta describe no tiene ningún campo de valor, por lo que no hay forma en la que los metadatos y el texto plano viajen juntos. Concede la acción de leer por sí misma, a los pocos principales que la necesitan, en los pocos secretos que necesitan. La misma división aparece en KMS con kms:Decrypt y en certificates con certificate:GetCertificateMaterial.

Escribir no implica leer

secrets:PutSecretValue añade una versión sin devolver nada de la antigua, por lo que un trabajo de rotación puede mantenerla sola. Eso vale la pena hacerlo: un componente que solo escribe material nuevo no tiene razón para ser capaz de leer lo que ya está allí.

El listado no se puede restringir

secrets:ListSecrets está autorizado contra la colección en lugar de contra secretos individuales, por lo que restringirlo por CRN o etiqueta no tiene efecto. Scope secrets:GetSecretValue — esa es la concesión que importa.

Recursos

Las acciones de secretos se comprueban en una forma de recurso:
La ranura de región está poblada: un secreto vive en una región y se lee desde allí. El nombre de un secreto puede contener /, y eso es lo que hace que el CRN valga la pena analizar. Nombrar los secretos prod/payments/stripe-key en lugar de prod-payments-stripe-key permite que una declaración cubra los secretos de todo un servicio y nada más. Los nombres coinciden con ^[a-zA-Z0-9][a-zA-Z0-9._/-]{0,255}$.

Condiciones

Create lleva las etiquetas de la solicitud; cada acción con ámbito secreto lleva las etiquetas que ya están en el secreto:
  • basalt:RequestTag/<key> — lo que un llamador puede etiquetar un secreto como, en create.
  • basalt:ResourceTag/<key> — que secretos existentes una acción puede tocar.

Escribir una póliza

Un servicio que lee exactamente los secretos bajo su propio prefijo de ruta:
Un trabajo de rotación que puede escribir pero nunca leer:
secrets:* incluye la lectura de todos los valores. Un comodín en la acción otorga secrets:GetSecretValue junto con todo lo demás, que rara vez es lo que se quiere decir con “dejar que este equipo administre secretos”. Enumerar las acciones cuando la credencial pertenece a una persona o a un trabajo de CI.
Vea writing policies para el formato del documento, las claves de condición de etiquetas, y cómo un guardrail deny sobrevive a un broad allow.

Qué aspecto tiene una negación

Una comprobación fallida responde 403:
No le dice qué acción faltaba, deliberadamente — el mensaje es el mismo para cada denegación, por lo que no se puede usar para mapear lo que una credencial puede y no puede alcanzar. Busca la llamada que hiciste en la tabla anterior, y la acción que necesita es la que debes agregar.
Un 404 no es un 403 disfrazado. La propiedad se resuelve antes de la autorización: un secreto perteneciente a otra cuenta responde 404 porque no es tuyo para ver, y uno que eres dueño pero carece de la acción para respuestas 403. Un secreto dentro de su ventana de recuperación es un tercer caso de nuevo — responde 409 SECRET_DELETED, lo que significa que el secreto está allí y la credencial está bien.