Este lab se desarrolló junto con nuestro socio HashiCorp. Es posible que tu información personal se comparta con HashiCorp, el patrocinador del lab, si aceptaste recibir actualizaciones, anuncios y ofertas de productos en el perfil de tu cuenta.

GSP1004

Descripción general

Vault usa políticas para determinar el comportamiento de los clientes y aplicar el control de acceso basado en roles (RBAC) especificando privilegios de acceso (autorización). Las políticas proporcionan una forma declarativa de otorgar o prohibir el acceso a ciertas rutas y operaciones. En este lab práctico, aprenderás a escribir y usar políticas de Vault.

Objetivos

En este lab, aprenderás a hacer lo siguiente:

• Crear políticas de Vault
• Administrar políticas de Vault
• Asociar políticas de Vault
• Verificar y probar políticas de Vault

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs cuentan con un temporizador que no se puede pausar. El temporizador, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar. Se recomienda el navegador Chrome.

Nota: Usa una ventana del navegador privada o de incógnito (opción recomendada) para ejecutar el lab. Así evitarás conflictos entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab (recuerda que, una vez que comienzas un lab, no puedes pausarlo).

Nota: Usa solo la cuenta de estudiante para este lab. Si usas otra cuenta de Google Cloud, es posible que se apliquen cargos a esa cuenta.

Cómo iniciar tu lab y acceder a la consola de Google Cloud

1. Haz clic en el botón Comenzar lab. Si debes pagar por el lab, se abrirá un diálogo para que selecciones la forma de pago. A la derecha, se encuentra el panel Configuración del lab y acceso, que tiene los siguientes elementos:

   • El botón Abrir la consola de Google Cloud
   • Las credenciales temporales (nombre de usuario y contraseña) que debes usar para este lab
   • Otra información para completar el lab (si es necesaria)

   Ten en cuenta que el cronómetro del lab se encuentra cerca de la parte superior de la página y muestra el tiempo restante.

2. Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).

   El lab inicia los recursos y abre otra pestaña, en la que se muestra la página de acceso.

   Sugerencia: Ordena las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usa otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Configuración del lab y acceso.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Configuración del lab y acceso.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud. Nota: Usar tu propia cuenta de Google Cloud para este lab podría generar cargos adicionales.

7. Haz clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación ni autenticación de dos factores, ya que esta cuenta es temporal.
   • No te registres para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.

Nota: Para acceder a los productos y servicios de Google Cloud, haz clic en el menú de navegación o escribe el nombre del servicio o producto en el campo Buscar.

Activa Cloud Shell

Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.

2. Haz clic para avanzar por las siguientes ventanas:

   • Continúa en la ventana de información de Cloud Shell.
   • Autoriza a Cloud Shell para que use tus credenciales para realizar llamadas a la API de Google Cloud.

Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu Project_ID, . El resultado contiene una línea que declara el Project_ID para esta sesión:

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.

3. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

4. Haz clic en Autorizar.

Resultado:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Nota: Para obtener toda la documentación de gcloud, en Google Cloud, consulta la guía con la descripción general de gcloud CLI.

Tarea 1: Instala Vault

1. En Cloud Shell, agrega la clave GPG de HashiCorp:

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - Nota: Si aparece una advertencia, ignórala.

2. Agrega el repositorio oficial de Linux de HashiCorp:

sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

3. Actualiza e instala Vault:

sudo apt-get update sudo apt-get install vault

Verifica la instalación

Después de instalar Vault, verifica que la instalación haya funcionado. Para hacerlo, comprueba que el objeto binario de Vault esté disponible.

• Ejecuta el comando vault para verificar la instalación:

vault

Deberías ver un resultado de ayuda similar al siguiente:

Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command kv Interact with Vault's Key-Value storage lease Interact with leases monitor Stream log messages from a Vault server namespace Interact with namespaces operator Perform operator-specific tasks path-help Retrieve API help for paths plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens

Tarea 2: Inicia el servidor de Vault

Con Vault instalado, el próximo paso es iniciar un servidor de Vault.

Vault funciona como una aplicación cliente/servidor. El servidor de Vault es la única parte de la arquitectura de Vault que interactúa con el almacenamiento de datos y los backends. Todas las operaciones realizadas a través de la CLI de Vault interactúan con el servidor por medio de una conexión TLS.

En este lab, iniciarás el servidor de Vault que se ejecuta en modo de desarrollo y, luego, interactuarás con él.

Este servidor en modo de desarrollo no requiere más configuración. Se autenticará tu CLI de Vault local para comunicarse con él. Esto facilita experimentar con Vault o iniciar una instancia de Vault para el desarrollo. Todas las funciones de Vault están disponibles en el modo “dev”. Con la marca -dev, se omite gran parte de la configuración a valores predeterminados no seguros.

Advertencia: Nunca ejecutes un servidor en modo “dev” en producción. No es seguro y perderá datos en cada reinicio (ya que almacena datos en la memoria). Solo se creó para desarrollo o experimentación.

Inicia el servidor de desarrollo

Primero, inicia un servidor de desarrollo de Vault. El servidor de desarrollo es un servidor integrado y preconfigurado que no es muy seguro, pero es útil para probar Vault de forma local.

1. Para iniciar el servidor de desarrollo de Vault, ejecuta lo siguiente:

vault server -dev

Deberías ver un resultado relacionado con la configuración de tu servidor de Vault. Observa que se muestran los valores de clave para anulación de sello y token raíz:

==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled") Log Level: info Mlock: supported: false, enabled: false Recovery Mode: false Storage: inmem Version: Vault v1.4.1 WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault. You may need to set the following environment variable: $ export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. Unseal Key: 1+yv+v5mz+aSCK67X6slL3ECxb4UDL8ujWZU/ONBpn0= Root Token: s.XmpNPoi9sRhYtdKHaQhkHP6x Development mode should NOT be used in production installations! Nota: El servidor de desarrollo almacena todos sus datos en la memoria (pero encriptados), escucha en localhost sin TLS y automáticamente anula los sellos y te muestra la clave para anulación de sello y la clave de acceso raíz. Nota: Operación no segura

No ejecutes un servidor de desarrollo de Vault en producción. Este enfoque solo se usa aquí para simplificar el proceso de anulación del sello para esta demostración.

Ahora que tienes el servidor de desarrollo de Vault en ejecución, puedes seguir configurando el acceso a él.

2. Abre una pestaña nueva de Cloud Shell.

3. Copia y ejecuta el comando de exportación VAULT_ADDR ... desde el resultado de la terminal. Esto configurará el cliente de Vault para que se comunique con el servidor de desarrollo:

export VAULT_ADDR='http://127.0.0.1:8200'

La CLI de Vault determina a qué servidores de Vault enviar solicitudes con la variable de entorno VAULT_ADDR.

Verifica que el servidor esté en ejecución

• Ejecuta el comando vault status para verificar que el servidor esté en ejecución:

vault status

Si se ejecutó correctamente, el resultado debería ser similar al siguiente:

$ vault status Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 1 Threshold 1 Version 1.13.2 Build Date 2023-04-25T13:02:50z Storage Type inmem Cluster Name vault-cluster-e2392b81 Cluster ID 48d7aba0-5416-a36b-2c27-0b256b222f57 HA Enabled false

¡Genial! Iniciaste tu primer servidor de desarrollo de Vault. Ahora puedes continuar con la próxima sección, en la que aprenderás a escribir políticas de Vault.

Tarea 3: Políticas de Vault

Vault crea una política raíz durante la inicialización. La política raíz puede realizar todas las operaciones para todas las rutas. Esta política se asigna al token raíz que se muestra cuando se completa la inicialización. Esto proporciona un superusuario inicial para habilitar motores de Secrets, definir políticas y configurar métodos de autenticación.

Vault también crea una política predeterminada. La política predeterminada define un conjunto común de capacidades que habilitan que un token se refleje y se administre a sí mismo. Esta política también se asigna al token raíz y se adjunta a todos los tokens de forma predeterminada.

Sintaxis de la política

Las políticas se escriben en HCL o JSON, y describen a qué rutas de Vault puede acceder un usuario o una máquina. Una política define una lista de rutas. Cada ruta expresa las capacidades que se permiten. Las capacidades de una ruta deben otorgarse, ya que Vault deniega de forma predeterminada las capacidades a las rutas para garantizar que sea seguro de forma predeterminada.

El formato básico de una política es el siguiente:

path "<path>" { capabilities = ["list of capabilities"] }

Esta es una política muy simple que otorga capacidades de lectura a la ruta "secret/foo":

path "secret/foo" { capabilities = ["read"] }

Cuando esa política se asigna a un token, el token puede leer de "secret/foo". Sin embargo, el token no puede actualizar ni borrar "secret/foo", ya que no lo permiten las capacidades. Como las políticas deniegan accesos de forma predeterminada, el token no tendría ningún otro acceso en Vault. Esto significa que una política de Vault vacía no otorga permisos en el sistema.

Capacidades

Una política define una o más rutas de acceso, y una lista de capacidades permitidas. Cada ruta debe definir una o más capacidades que proporcionen un control detallado sobre las operaciones permitidas (o denegadas). Como verás en los ejemplos incluidos a continuación, las capacidades siempre se especifican como una lista de cadenas, incluso si solo hay una capacidad. La mayoría de las capacidades se asignan a los verbos HTTP compatibles con la API de Vault. Las capacidades son las siguientes:

Capacidad de la política	Verbos HTTP asociados
create	POST/PUT
read	GET
update	POST/PUT
delete	DELETE
list	LIST
patch	PATCH
sudo	-
deny	-

La capacidad sudo permite acceder a rutas protegidas por raíz (consulta la sección del instructivo Extremos protegidos por raíz). La capacidad deny inhabilita el acceso a la ruta. Cuando se combina con otras capacidades, siempre tiene prioridad.

Ejemplos de políticas

Una política más detallada para otorgar acceso ilimitado en "secret/*" podría definirse de la siguiente manera:

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] }

Si quieres definir más restricciones, puedes agregar la siguiente capacidad de deny:

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/super-secret" { capabilities = ["deny"] }

Aunque permitiste secret/*, esta línea adicional anterior deniega de forma explícita secret/super-secret. La denegación prevalece sobre el resto.

Las políticas también pueden especificar parámetros permitidos, no permitidos y obligatorios. Aquí, la clave "secret/restricted" solo puede contener "foo" (cualquier valor) y "bar" (uno de “zip” o “zap”).

path "secret/restricted" { capabilities = ["create"] allowed_parameters = { "foo" = [] "bar" = ["zip", "zap"] } }

Las políticas usan la coincidencia basada en rutas para probar el conjunto de capacidades en una solicitud. Una política path puede especificar una ruta exacta para que coincida, o bien un patrón glob que le indique a Vault que use una coincidencia de prefijo.

Por ejemplo, esta política solo permite leer "secret/foo" o "secret/foo/bar".

path "secret/foo" { capabilities = ["read"] }

Además, la política permite leer todo lo que se encuentra en "secret/bar". Un token adjunto podría leer "secret/bar/zip", "secret/bar/zip/zap", pero no "secret/bars/zip".

path "secret/bar/*" { capabilities = ["read"] }

Además, esta política permitiría leer todo lo que tenga el prefijo "zip-". Un token adjunto podría leer "secret/zip-zap" o "secret/zip-zap/zong", pero no "secret/zip/zap.

path "secret/zip-*" { capabilities = ["read"] }

Por último, se puede usar un + para denotar cualquier cantidad de caracteres delimitados en un solo segmento de ruta. Lo siguiente permitiría leer la ruta "teamb" debajo de cualquier ruta de nivel superior en secret/.

path "secret/+/teamb" { capabilities = ["read"] }

Esta regla permitiría leer secret/foo/bar/teamb, secret/bar/foo/teamb, etcétera.

path "secret/+/+/teamb" { capabilities = ["read"] }

Como puedes ver, la arquitectura de Vault es similar a la de un sistema de archivos. Cada acción en Vault tiene una ruta de acceso y una capacidad correspondientes; hasta los extremos de configuración interna de Vault se encuentran pertenecen a la ruta de acceso "sys/". Las políticas definen el acceso a estas rutas y capacidades, lo que controla el acceso de un token a las credenciales en Vault.

Políticas basadas en plantillas

La sintaxis de la política permite reemplazar variables en algunas cadenas de políticas por valores disponibles para el token. Actualmente, se puede insertar información de identity y las claves de path en las políticas permiten la inserción. Por ahora, no tienes que preocuparte por las entidades ni los alias. Esto se incluye solo como referencia para más adelante.

Parámetros

Nombre	Descripción
identity.entity.id	El ID de la entidad
identity.entity.name	El nombre de la entidad
identity.entity.metadata.<metadata key>	Metadatos asociados con la entidad para la clave dada
identity.entity.aliases.<mount accessor>.id	El ID del alias de la entidad para la activación determinada
identity.entity.aliases.<mount accessor>.name	Nombre del alias de la entidad para el montaje dado
identity.entity.aliases.<mount accessor>.metadata.<metadata key>	Metadatos asociados con el alias para la clave de activación y metadatos en cuestión
identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key>	Metadatos personalizados asociados con el alias para la clave de metadatos personalizados y activación en cuestión
identity.groups.ids.<group id>.name	El nombre del grupo para el ID de grupo en cuestión
identity.groups.names.<group name>.id	El ID del grupo para el nombre de grupo en cuestión
identity.groups.ids.<group id>.metadata.<metadata key>	Metadatos asociados con el grupo para la clave en cuestión
identity.groups.names.<group name>.metadata.<metadata key>	Metadatos asociados con el grupo para la clave en cuestión

Ejemplos

La siguiente política crea una sección del motor de Secrets KVv2 para un usuario específico:

path "secret/data/{{identity.entity.id}}/*" { capabilities = ["create", "update", "read", "delete"] } path "secret/metadata/{{identity.entity.id}}/*" { capabilities = ["list"] }

Para obtener más información sobre las políticas basadas en plantillas, puedes consultar la documentación de políticas basadas en plantillas.

Nota: Cuando desarrolles políticas basadas en plantillas, usa IDs siempre que sea posible. Cada ID es único para el usuario, mientras que los nombres pueden cambiar con el tiempo y se pueden reutilizar. Esto garantiza que, si se cambia un nombre de usuario o grupo determinado, la política se asignará a la entidad o el grupo deseado.

Verifica las capacidades integradas de las políticas

Ahora que viste cómo se escriben las políticas, veamos rápidamente las capacidades de las políticas raíz y predeterminada.

1. En la pestaña de Cloud Shell que abriste, ejecuta el siguiente comando para acceder a Vault con tu token raíz:

vault login token=<your root token>

Deberías ver el siguiente resultado:

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.mCWmZyVNi6ZDU7HSq7vQXwvj token_accessor nFDgTnm7FYCHNLSERwiVsbWf token_duration ∞ token_renewable false token_policies ["root"] identity_policies [] policies ["root"] Nota: Observa que la política adjunta es la política raíz.

2. Como la política raíz te permite hacer lo que quieras en Vault, ejecuta un comando básico para verificar que así sea:

vault secrets list

El resultado debería ser similar al siguiente:

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_f0f2e28e per-token private secret storage identity/ identity identity_a554d41f identity store secret/ kv kv_ca28f047 key/value secret storage sys/ system system_1a7dcf93 system endpoints..

Ahora intentarás ejecutar el mismo comando como un usuario que solo tiene adjunta la política predeterminada.

3. Comienza por habilitar el método de autenticación userpass y crear un usuario nuevo:

vault auth enable userpass vault write auth/userpass/users/example-user password=password!

4. Luego, accede a Vault con el usuario nuevo que creaste:

vault login -method=userpass username=example-user password=password!

Deberías recibir lo siguiente:

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.Ov9GkScxp5AYDjzmbdHNN4r0 token_accessor UewGCCotUMjccmD1EjssgHqf token_duration 768h token_renewable true token_policies ["default"] identity_policies [] policies ["default"] token_meta_username example-user Nota: Ten en cuenta que la política adjunta es la política predeterminada.

5. Ejecuta el mismo comando que antes para verificar las capacidades de la política:

vault secrets list

Deberías recibir el siguiente error:

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

Como puedes ver aquí, Vault está haciendo una solicitud a la API GET de la ruta sys/mounts. Como recibes un error de permiso denegado, no puedes acceder a la ruta y enumerar los motores de Secrets. Ahora es momento de escribir tu primera política para obtener acceso a esta ruta y enumerar los motores de Secrets.

Tarea 4: Crea una política

Dado que Vault protege, almacena y controla de forma centralizada el acceso a los Secrets en infraestructuras y aplicaciones distribuidas, es fundamental controlar los permisos antes de que un usuario o una máquina pueda obtener acceso.

La solución para esto es restringir el uso de la política raíz y escribir políticas detalladas para implementar el privilegio mínimo. Por ejemplo, si una app obtiene credenciales de Google Cloud de Vault, escribe permisos de política para leer desde el motor de Secrets de Google Cloud, pero no para borrar, etcétera.

Las políticas se adjuntan a los tokens y roles para aplicar los permisos del cliente en Vault. Ahora que viste cómo se definen las políticas de forma sintáctica, es hora de escribir tu primera política de Vault.

Accede a la IU web de Vault

1. Primero, haz clic en el ícono de vista previa en la Web de la barra de herramientas de Cloud Shell.

2. Haz clic en Cambiar puerto.

3. Cambia el número de puerto a 8200 y haz clic en Cambiar y obtener vista previa.

4. Se te debería redireccionar a la página de acceso de Vault.

5. Ingresa el token raíz que guardaste antes en el lab y haz clic en Acceder.

Tu servidor de desarrollo de Vault debe parecerse al siguiente ejemplo.

Ahora que accediste a la IU web del servidor de desarrollo, puedes continuar con la próxima sección.

Crea una política nueva

1. Haz clic en Control de acceso en la página principal. Deberías ver las políticas predeterminada y raíz de ACL.

2. Haz clic en Create ACL policy.

3. Para comenzar, asígnale el nombre demo-policy a tu política.

Ahora puedes comenzar a escribir tu política. Recuerda que, en la sección anterior, no pudiste acceder a la ruta de acceso sys/mounts para leer los motores de Secrets. Ahora agregarás esa información.

4. En Reglas de políticas, selecciona Editor de código y agrega el siguiente código de marcador de posición:

path "path" { capabilities = [""] }

5. Ahora, primero hay que actualizar path a la ruta sys/mounts a la que intentabas acceder antes:

path "sys/mounts" { capabilities = [""] }

6. A continuación, agregarás una capacidad. Como Vault intenta hacer una llamada a la API GET en esta ruta, necesitarás la capacidad read. Agrega read a la lista de capacidades:

path "sys/mounts" { capabilities = ["read"] }

La política debería ser similar a la siguiente:

7. Haz clic en Crear política.

Ahora deberás asociar esa política con el example-user que creaste anteriormente.

8. Haz clic en Back to main navigation.

9. Haz clic en Acceso > Métodos de autenticación en el panel izquierdo y, luego, en userpass.

10. Haz clic en los tres puntos junto al usuario example-user y selecciona Editar usuario.

11. En el campo de contraseña, haz clic en Tokens para abrir el submenú.

12. En Políticas del token generado, agrega la política que acabas de crear (demo-policy) y haz clic en Agregar.

13. Haz clic en Guardar.

¡Genial! Creaste una política nueva y la asociaste con example-user.

14. Vuelve a Cloud Shell y ejecuta el siguiente comando de nuevo:

vault secrets list

Verás el mismo error que antes:

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

¿Por qué se produjo un error después de agregar la política al usuario? Esto se debe a que, una vez que asocias una nueva política con un usuario, esa política no se asociará con el token existente para ese usuario. Para solucionar ese problema, deberás generar un token nuevo para ese usuario, de modo que la política nueva se pueda adjuntar a ese token.

15. Ejecuta el siguiente comando para acceder y generar un token nuevo para example-user:

vault login -method=userpass username=example-user password=password! Nota: Deberías recibir un token nuevo en el resultado. Observa que ahora tienes la política default y la política demo-policy adjuntas. Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.7AVelOPORi1zhjH5iLototw7 token_accessor H1ee2gTXzTXUU9ptpU3ailnJ token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username example-user

16. Ahora intenta enumerar los motores de Secrets una vez más:

vault secrets list

Tu resultado ahora debería verse de la siguiente manera:

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_76cb59ae per-token private secret storage identity/ identity identity_7fa27e52 identity store secret/ kv kv_f6e83366 key/value secret storage sys/ system system_414d50aa system endpoints..

17. También puedes verificar las capacidades del token con el comando vault token capabilities. Ejecuta lo siguiente para verificar tu política en la ruta sys/mounts:

vault token capabilities <your token> sys/mounts

Deberías obtener el siguiente resultado:

read

18. Luego, verifica las capacidades del token para la ruta sys/policies/acl:

vault token capabilities <your token> sys/policies/acl

Deberías obtener el siguiente resultado:

deny

19. Para verificarlo, intenta ejecutar el siguiente comando para enumerar las políticas:

vault policy list

Deberías recibir el siguiente error:

Error listing policies: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/policies/acl?list=trueCode: 403. Errors: * 1 error occurred: * permission denied

Como puedes ver aquí, recibes un error de permiso denegado para una solicitud a la API GET en la ruta sys/policies/acl. Además, observa el list=true adicional en la ruta; también deberás agregar esta capacidad. Para solucionar el problema, actualiza la política existente.

20. Vuelve a la demo-policy que creaste en la IU de Vault.

21. Haz clic en Editar política.

22. En el cuadro Política, agrega el siguiente código de marcador de posición debajo de la política existente que escribiste:

path "path" { capabilities = [""] }

23. De nuevo, primero hay que actualizar path a la ruta sys/policies/acl a la que intentabas acceder:

path "sys/policies/acl" { capabilities = [""] }

24. Ahora agregarás la capacidad. Como Vault intenta realizar una llamada a la API GET en esta ruta, deberás volver a agregar la capacidad read. Además, el intento pasó en list=true a la URL, por lo que también deberás agregar esta capacidad.

path "sys/policies/acl" { capabilities = ["read", "list"] }

Tu política actualizada ahora debería ser similar a la siguiente:

25. Haz clic en Guardar.

26. Vuelve a Cloud Shell y ejecuta el siguiente comando de nuevo:

vault policy list

El resultado ahora debería ser similar al siguiente:

default default-ceiling demo-policy root

27. Ejecuta el siguiente comando para copiar los valores de las políticas en un archivo de texto:

vault policy list > policies.txt

28. Por último, vuelve a verificar las capacidades del token de la ruta sys/policies/acl:

vault token capabilities <your token> sys/policies/acl

Deberías obtener el siguiente resultado:

list, read

29. Ejecuta el siguiente comando para copiar los valores de las políticas en un archivo de texto. Asegúrate de reemplazar <your token> por el valor de tu token:

vault token capabilities <your token> sys/policies/acl > token_capabilities.txt

30. Ejecuta los siguientes comandos para copiar los archivos de texto policies y token_capabilities en un bucket de Cloud Storage creado previamente para hacer un seguimiento del progreso:

export PROJECT_ID=$(gcloud config get-value project) gcloud storage cp *.txt gs://$PROJECT_ID

Como puedes ver, cuando modificaste la política existente asociada al usuario, los cambios se reflejaron sin generar un token nuevo. Esto se debe a que el contenido de las políticas se analiza en tiempo real cada vez que se usa el token. Como resultado, si se modifica una política, se aplicarán las reglas modificadas la próxima vez que se use un token con esa política adjunta para hacer una llamada a Vault.

¡Genial! Creaste correctamente una política que otorgó acceso de lectura a la ruta sys/mounts y la asociaste a un usuario. Luego, agregaste una política adicional para otorgar acceso de lectura y enumeración a la ruta de acceso sys/policies.

Haz clic en Revisar mi progreso para verificar el objetivo. Crear políticas

Tarea 5: Administra políticas

Las políticas se crean (escriben) en el editor que elijas. Se pueden crear en HCL o JSON, y la sintaxis se describe en detalle más arriba. Una vez guardadas, las políticas deben subirse a Vault para poder usarlas.

En la sección anterior, usaste la IU para escribir y administrar una política. En esta sección, veremos los comandos de la CLI para administrar políticas.

• Primero, asegúrate de ejecutar lo siguiente en Cloud Shell para acceder a Vault con tu token raíz:

vault login <your root token>

Enumera las políticas

• Ejecuta el siguiente comando para enumerar todas las políticas registradas en Vault:

vault read sys/policy

Deberías ver el siguiente resultado:

Key Value --- ----- keys [default demo-policy root] policies [default demo-policy root

Crea políticas

Las políticas se pueden crear (subir) a través de la CLI, IU o API. En la sección anterior, usaste la IU para crear el archivo HCL.

Para crear una nueva política en Vault, usarías el siguiente comando:

vault policy write policy-name policy-file.hcl

1. Para probarlo, primero crea un archivo de política básico con el siguiente comando:

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } EOF

2. Verifica que el archivo se haya creado correctamente:

cat example-policy.hcl

3. Ahora crea una nueva política llamada example-policy con el comando vault policy write:

vault policy write example-policy example-policy.hcl

Si se ejecutó correctamente, deberías ver el siguiente resultado:

Success! Uploaded policy: example-policy

En este ejemplo, el nombre de la política es “example-policy”. Puedes considerar este nombre como un puntero o un symlink a las ACL de la política. Los tokens son políticas adjuntas por nombre, que, luego, se asignan al conjunto de reglas que corresponde a ese nombre.

Cómo actualizar políticas

Las políticas existentes se pueden actualizar para cambiar los permisos a través de la CLI o API. Para actualizar una política existente en Vault, seguirás los mismos pasos que para crear una, pero usarás el nombre de una política existente.

1. Primero, ejecuta el siguiente comando para actualizar y reemplazar tu archivo de política existente y enumerar los métodos de autenticación:

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List auth methods path "sys/auth" { capabilities = ["read"] } EOF

2. Verifica que el archivo se haya creado correctamente:

cat example-policy.hcl

3. Actualiza tu política:

vault write sys/policy/example-policy policy=@example-policy.hcl

¡Genial! Actualizaste correctamente una política con la CLI.

4. Ejecuta el siguiente comando para copiar el archivo de política en un bucket de Cloud Storage creado previamente y hacer un seguimiento del progreso:

gcloud storage cp example-policy.hcl gs://$PROJECT_ID

Haz clic en Revisar mi progreso para verificar el objetivo. Crear y administrar políticas con comandos de la CLI

Borra políticas

Las políticas existentes se pueden borrar a través de la CLI, IU o API. Para borrar una política, tendrías que ejecutar lo siguiente:

vault delete sys/policy/policy-name

1. Pongamos esto en práctica. Ejecuta el siguiente comando para borrar la política que acabas de crear:

vault delete sys/policy/example-policy

Si se ejecutó correctamente, deberías haber visto el siguiente resultado:

Success! Data deleted (if it existed) at: sys/policy/example-policy

2. Enumera tus políticas con el siguiente comando:

vault policy list

Deberías ver el siguiente resultado:

default default-ceiling demo-policy root

¡Genial! Borraste correctamente la example-policy.

Nota: Esta es una operación idempotente. Vault no devolverá un error cuando se borre una política que no existe.

Tarea 6: Cómo asociar políticas

Vault puede asociar automáticamente un conjunto de políticas a un token según una autorización. Esta configuración varía significativamente entre los backends de autenticación. Para mayor simplicidad, en este ejemplo se usará el método integrado de autenticación userpass de Vault.

1. Ejecuta el siguiente comando para crear el usuario firstname-lastname en Vault con una lista de políticas asociadas:

vault write auth/userpass/users/firstname-lastname \ password="s3cr3t!" \ policies="default, demo-policy" Success! Data written to: auth/userpass/users/firstname-lastname

Esto crea una asignación de autenticación a la política, de modo que, cuando el usuario se autentica correctamente en Vault, se le otorga un token que tiene la lista de políticas adjunta.

2. Realiza la autenticación con Vault ejecutando lo siguiente:

vault login -method="userpass" username="firstname-lastname" password="s3cr3t!"

Deberías ver el siguiente resultado:

Key Value --- ----- token s.XnRsinhsokVUiN7XbsnyCOEC token_accessor JFErk5Rgb7vtW47CJjY2OCsF token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username firstname-lastname

Como la información proporcionada es correcta, Vault generará un token, le asignará la lista de políticas configuradas y lo devolverá al usuario autenticado.

Tokens

Los tokens tienen dos conjuntos de políticas: las políticas de identidad, que se procesan en función de la entidad y sus grupos, y las políticas de tokens, que se definen según el método de acceso o, en el caso de la creación explícita de tokens a través de la API, son una entrada para la creación de tokens. Lo que sigue se refiere exclusivamente a las políticas de tokens: las políticas de identidad de un token no se pueden controlar, excepto con la modificación de las entidades, los grupos y las membresías de grupos subyacentes.

1. Primero, vuelve a acceder a Vault con tu token raíz:

vault login <your root token>

2. Los tokens se asocian con sus políticas en el momento de la creación. Ejecuta lo siguiente para crear un token con las políticas dev-readonly y logs:

vault token create -policy=dev-readonly -policy=logs

Deberías ver el siguiente resultado:

Key Value --- ----- token s.gKRV6vzFmpdJ9iwvPfzNjAuI token_accessor S4jfdYvy8jQP7GGDa947CBlT token_duration 768h token_renewable true token_policies ["default" "dev-readonly" "logs"] identity_policies [] policies ["default" "dev-readonly" "logs"] Nota: Puedes ignorar las advertencias de que las políticas no existen, ya que no las creaste.

En general, las únicas políticas que se pueden especificar son las que están presentes en las políticas de token del token actual (es decir, el token superior del nuevo token). Sin embargo, los usuarios raíz pueden asignar cualquier política.

Una vez que se emitió, no hay forma de modificar las políticas asociadas con un token. Se debe revocar el token y adquirir uno nuevo para recibir un conjunto nuevo de políticas.

Sin embargo, el contenido de las políticas se analiza en tiempo real cada vez que se usa el token. Como resultado, si se modifica una política, se aplicarán las reglas modificadas la próxima vez que se use un token con esa política adjunta para hacer una llamada a Vault.

Tarea 7: Políticas para Secrets

En esta sección, crearás y probarás políticas de Vault para otorgar a los usuarios diferentes niveles de acceso dentro de Vault.

• En Cloud Shell, comienza por crear un par de usuarios diferentes con distintas políticas:

vault write auth/userpass/users/admin \ password="admin123" \ policies="admin" vault write auth/userpass/users/app-dev \ password="appdev123" \ policies="appdev" vault write auth/userpass/users/security \ password="security123" \ policies="security"

Ahora que creaste algunos usuarios nuevos, crearás las políticas que ya asociaste con ellos. Primero, comenzarás con la política del administrador, que debería tener acceso completo a todos los Secrets en Vault.

Crea la política del administrador

Para este lab, un usuario administrador debe poder hacer lo siguiente:

• Leer la verificación de estado del sistema
• Crear y administrar políticas de ACL de forma general en Vault
• Habilitar y administrar métodos de autenticación de forma general en Vault
• Administrar el motor de Secrets de par clave-valor habilitado en la ruta de acceso secret/

1. Navega a Políticas de ACL desde el panel izquierdo en la IU de Vault. Deberías ver las políticas default, default-ceiling, demo-policy y root.

2. Haz clic en Create ACL policy.

3. Para comenzar, asigna el nombre admin a tu política.

4. En Reglas de políticas, selecciona Editor de código y agrega el siguiente código de política:

# Read system health check path "sys/health" { capabilities = ["read", "sudo"] } # Create and manage ACL policies broadly across Vault # List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Enable and manage authentication methods broadly across Vault # Manage auth methods broadly across Vault path "auth/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, update, and delete auth methods path "sys/auth/*" { capabilities = ["create", "update", "delete", "sudo"] } # List auth methods path "sys/auth" { capabilities = ["read"] } # Enable and manage the key/value secrets engine at `secret/` path # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

La política debería ser similar a la siguiente:

5. Haz clic en Crear política.

Crea la política appdev

Para este lab, un usuario appdev debe poder hacer lo siguiente:

• Crear, leer y actualizar motores de Secrets
• Administrar el motor de Secrets de par clave-valor habilitado en la ruta secret/appdev/

1. Navega otra vez a la página Políticas de ACL.

2. Haz clic en Create ACL policy.

3. Para comenzar, asigna el nombre appdev a tu política.

4. En Reglas de políticas, selecciona Editor de código y agrega el siguiente código de política:

# List, create, update, and delete key/value secrets path "secret/+/appdev/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, read, and update secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

5. Haz clic en Crear política.

Crea la política de seguridad

Para este lab, un usuario de seguridad debe poder hacer lo siguiente:

• Crear y administrar políticas de ACL de forma general en Vault
• Administrar motores de Secrets
• Administrar el motor de Secrets de par clave-valor habilitado en la ruta de acceso secret/
• No tener acceso para leer o enumerar Secrets en la ruta secret/admin

1. Navega otra vez a la página Políticas de ACL.

2. Haz clic en Create ACL policy.

3. Para comenzar, asigna el nombre security a tu política.

4. En Reglas de políticas, selecciona Editor de código y agrega el siguiente código de política:

# List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Deny access to secret/admin path "secret/data/admin" { capabilities = ["deny"] } path "secret/data/admin/*" { capabilities = ["deny"] } # Deny list access to secret/admin path "secret/metadata/admin" { capabilities = ["deny"] } path "secret/metadata/admin/*" { capabilities = ["deny"] }

5. Haz clic en Crear política.

Crea Secrets

Ahora que creaste las diferentes políticas, es hora de crear algunos Secrets.

1. Vuelve a Cloud Shell y ejecuta los siguientes comandos para crear algunos Secrets en la ruta secret/security:

vault kv put secret/security/first username=password vault kv put secret/security/second username=password

2. Crea algunos Secrets en la ruta de acceso secret/appdev:

vault kv put secret/appdev/first username=password vault kv put secret/appdev/beta-app/second username=password

3. Crea algunos Secrets en la ruta secret/admin:

vault kv put secret/admin/first admin=password vault kv put secret/admin/supersecret/second admin=password

Verifica la seguridad de appdev

Ahora que creaste algunos Secrets, verifiquemos que se apliquen estas políticas. Primero, accederás como el usuario app-dev y verás a qué tienes acceso.

1. Ejecuta el siguiente comando para acceder como el usuario app-dev:

vault login -method="userpass" username="app-dev" password="appdev123"

2. Ahora intenta recuperar el Secret appdev/first:

vault kv get secret/appdev/first

Deberías ver el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. Recupera el Secret ubicado en secret/appdev/beta-app/second:

vault kv get secret/appdev/beta-app/second

Deberías ver el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Crea un Secret nuevo:

vault kv put secret/appdev/appcreds credentials=creds123

5. Destruye el Secret:

vault kv destroy -versions=1 secret/appdev/appcreds

6. Intenta obtener un Secret de secret/security:

vault kv get secret/security/first

Deberías recibir el siguiente error:

Error reading secret/data/security/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/security/first Code: 403. Errors: * 1 error occurred: * permission denied

7. Intenta enumerar todos los Secrets en secret/:

vault kv list secret/

Deberías recibir un error de nuevo:

Error listing secret/metadata: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata?list=true Code: 403. Errors: * 1 error occurred: * permission denied

¡Genial! Pudiste recuperar y crear Secrets en la ruta de acceso secret/appdev, y verificaste que no pudiste acceder a los Secrets fuera de ella.

Verifica la política de seguridad

1. Ejecuta el siguiente comando para acceder como usuario de security:

vault login -method="userpass" username="security" password="security123"

2. Ahora intenta recuperar el Secret security/first:

vault kv get secret/security/first

Deberías ver el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. Recupera el Secret ubicado en secret/security/second:

vault kv get secret/security/second

Deberías ver el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Crea un nuevo Secret en secret/security/supersecure:

vault kv put secret/security/supersecure/bigsecret secret=idk

5. Destruye el Secret:

vault kv destroy -versions=1 secret/security/supersecure/bigsecret

6. Intenta leer un Secret de secret/appdev:

vault kv get secret/appdev/first

Deberías recibir el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. Intenta enumerar todos los Secreto en secret/:

vault kv list secret/

Deberías recibir el siguiente resultado:

Keys ---- admin/ appdev/ security/

8. Habilita un nuevo motor de Secrets:

vault secrets enable -path=supersecret kv Success! Enabled the kv secrets engine at: supersecret/

9. Intenta ver el Secret secret/admin/first:

vault kv get secret/admin/first

Deberías recibir el siguiente error:

Error reading secret/data/admin/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/admin/first Code: 403. Errors: * 1 error occurred: * permission denied

10. Intenta enumerar los Secrets en secret/admin:

vault kv list secret/admin

De nuevo, deberías recibir un error:

Error listing secret/metadata/admin: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata/admin?list=true Code: 403. Errors: * 1 error occurred: * permission denied

¡Genial! Puedes recuperar y crear Secrets en la ruta de acceso secret/, y habilitar un motor de Secrets. Además, se te denegó el acceso a la ruta secret/admin como se especifica en la política.

Verifica la política para el administrador

1. Ejecuta el siguiente comando para acceder como usuario admin:

vault login -method="userpass" username="admin" password="admin123"

2. Ahora intenta recuperar el Secret admin/first:

vault kv get secret/admin/first

Deberías ver el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:18.521925218Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ==== Data ==== Key Value --- ----- admin password

3. Recupera un Secret ubicado en secret/security/first :

vault kv get secret/security/first

Deberías ver el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Crea un Secret nuevo:

vault kv put secret/webserver/credentials web=awesome

5. Destruye el Secret:

vault kv destroy -versions=1 secret/webserver/credentials

6. Intenta obtener Secrets de secret/appdev:

vault kv get secret/appdev/first

Deberías recibir el siguiente resultado:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. Intenta enumerar todos los Secrets en secret/appdev:

vault kv list secret/appdev/

Deberías recibir el siguiente resultado:

Keys ---- appcreds beta-app/ first

8. Enumera todas las políticas:

vault policy list

Deberías recibir el siguiente resultado:

admin appdev default default-ceiling demo-policy security root

9. Ejecuta el siguiente comando para copiar los valores de las políticas en un archivo de texto y subirlo al bucket de Cloud Storage:

vault policy list > policies-update.txt gcloud storage cp policies-update.txt gs://$PROJECT_ID

10. Habilita el método de autenticación gcp:

vault auth enable gcp

11. Por último, enumera los métodos de autenticación habilitados:

vault auth list Path Type Accessor Description ---- ---- -------- ----------- gcp/ gcp auth_gcp_faa3d15f n/a token/ token auth_token_066c5ebd token based credentials userpass/ userpass auth_userpass_929fe9bd n/a

Genial, ya verificaste que tienes los privilegios de administrador asociados con la política que escribiste.

Haz clic en Revisar mi progreso para verificar el objetivo. Políticas para Secrets

Rutas de acceso

Como pudiste ver en el código de la política que se proporcionó para el usuario security, se ingresaron un par de temas que no habías visto antes: data/ y metadata/.

El extremo de la ruta metadata/ devuelve una lista de nombres de claves en la ubicación especificada. Además, los valores en sí no son accesibles con este comando. Las versiones de escritura y lectura tienen el prefijo data/. Las operaciones de enumeración, lectura y destrucción son las siguientes:

• Versiones de lectura y escritura: data/
• Enumeración de claves: metadata/
• Lectura de versiones: metadata/
• Destrucción de versiones de Secret: destroy/
• Destrucción de todas las versiones de metadatos de una clave: metadata/

Por ejemplo, si intentas denegar el acceso a un Secret en secret/example, deberás formatearlo con los siguientes data/:

path "secret/data/example" { capabilities = ["deny"] }

Si quieres denegar el acceso a la lista secret/examples, necesitarás el formato con los siguientes metadata/:

path "secret/metadata/examples/*" { capabilities = ["deny"] }

Tarea 8: Control detallado

Además del conjunto estándar de capacidades, Vault ofrece un control más detallado sobre los permisos en una ruta determinada. Las capacidades asociadas a una ruta tienen prioridad sobre los permisos de los parámetros.

Restricciones de parámetros

En Vault, los datos se representan como pares key=value. Las políticas de Vault pueden, de manera opcional, restringir aún más las rutas según las claves y los datos de esas claves cuando se evalúan los permisos de una ruta. Las opciones de control más detalladas opcionales son las siguientes:

• required_parameters: Una lista de parámetros que deben especificarse.
• allowed_parameters: Una lista de claves y valores que se permiten en la ruta determinada.
• denied_parameters: Crea una lista de bloqueo de parámetros y valores prohibidos. Todos los valores especificados aquí tienen prioridad sobre allowed_parameters.

Para obtener más información, puedes consultar la documentación sobre el control detallado.

¡Felicitaciones!

Como puedes ver, las políticas son una parte importante de Vault. Si bien usar el token raíz es la forma más fácil de empezar a trabajar, querrás restringir el acceso a Vault muy rápido, y el sistema de políticas es la forma de hacerlo.

La sintaxis y la función de las políticas son fáciles de entender y usar, y como todos los métodos de autenticación deben asignarse al sistema de políticas central, solo tienes que aprender este sistema.

En este lab, creaste y administraste políticas, las asociaste con usuarios y tokens, y verificaste sus permisos.

Próximos pasos y más información

Consulta los siguientes recursos para obtener más información sobre Vault:

• Instructivos para comenzar a usar Vault
• Documentación de Vault
• Documentación de las políticas de Vault
• Instructivo de las políticas de Vault

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 4 de junio de 2026

Prueba más reciente del lab: 4 de junio de 2026

Copyright 2026 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.