Los secretos son lo último que hay que proteger : contraseña, claves API, claves privadas, certificados raíz,… Hay varios tipos de secretos, pero todos deben mantenerse seguros y privados . En Google Cloud, el servicio Secret Manager ayuda a lograr esto al mantener los secretos encriptados y protegidos por IAM .
Protección secreta de IAM
Fuera de la caja, Secret Manager ofrece una política detallada para otorgar acceso a secretos individuales para hacer cumplir el principio de privilegio mínimo. De esta manera, solo las cuentas (cuenta de usuario o cuenta de servicio) que necesitan acceder a algunos secretos pueden acceder a ellos, pero no pueden acceder a los otros secretos, incluso dentro del mismo proyecto.
Es cierto para el rol de acceso (leer el secreto), pero también para crear nuevas versiones secretas, por ejemplo.
Seth Vargo ha lanzado un gran video sobre ese tema.
Sin embargo, las dificultades comienzan cuando varios grupos de usuarios necesitan administrar los secretos . Digamos :
- Un equipo de DevOps que gestiona los recursos de certificados, la base de datos y los secretos relacionados con ellos.
- Un equipo de desarrollo que usa claves API para acceder a servicios de terceros y necesita mantener este secreto a salvo.
Todo el proyecto anhela, algunos secretos ya no existen y deben ser creados por cada equipo, en su perímetro. Y debido a que los secretos ya no existen , no puede otorgarles el rol de IAM y lograr el mínimo privilegio como se describió anteriormente.
Por lo tanto, los equipos tienen una función de administrador de Secret Manager a nivel de proyecto y, por lo tanto, pueden ver y eliminar cualquier secreto del proyecto .
¿Cómo lograr el principio de privilegio mínimo cuando 2 equipos trabajan en el mismo proyecto?
Hay soluciones, como “ Crear un nuevo proyecto ” o “ Dejar que la creación de todos los secretos la haga el equipo de DevOps ”.
Sí, pero hay otra forma: condiciones de IAM .
Condiciones de IAM en Secret Manager
El servicio IAM tiene una función denominada "condición". Obviamente explícito, puede otorgar rol solo si se cumple la condición .
Para aplicar eso en nuestro caso de uso, hay 2 requisitos
- La cuenta de los usuarios (o grupos) no tiene roles heredados (Visor, Propietario, Editor). Las condiciones de IAM no se pueden aplicar a funciones heredadas.
- Cada grupo de usuarios utiliza una convención de nomenclatura y antepone todos los secretos con el mismo valor. Por ejemplo, devops, para el equipo de devops y dev, para el equipo de desarrollo.
Luego, use la condición de IAM para configurar el acceso.
- Las cuentas de devops solo tienen acceso a los secretos con prefijo de devops
- Las cuentas de desarrollador solo tienen acceso a los secretos con prefijo dev
Vaya a la página de IAM y haga clic en el botón Agregar. Para el equipo de desarrollo, puede tener eso
Haga clic en Agregar condición. Seleccione el recurso -> Nombre tipo de condición
Luego, el operador comienza con y finalmente el prefijo secreto
!!! DETENER !!!
No funcionará . Muchas rasones
- El valor debe ser el nombre completo del secreto con este patrón.
proyectos // secretos / dev-
Tenga en cuenta que se requiere el número de proyecto , no el ID del proyecto.
- La regla significa " Usted tiene el rol de administrador de administrador secreto cuando el nombre completo del secreto comienza con ... ". Pero, cuando quieras crear un secreto , el nombre secreto ya no existe , ¡lo vas a crear! Entonces también necesitas el rol cuando no existe ningún secreto
Expresión de condición de IAM correcta
Para resolver eso, necesitas expresar lo contrario:
- Las cuentas de desarrollador no tienen acceso a los secretos con prefijo de devops
Para eso, debe ir a la pestaña Editor de condiciones e ingresar esta condición
! (resource.name.startsWith ("proyectos / / secretos / devops- ")) 
Nombra la condición, guárdala y valida los roles de IAM.
Si prefiere la CLI, puede hacerlo así
proyectos de gcloud add-iam-policy-binding\
--condition = expression = '! (resource.name.startsWith ("proyectos // secrets / devops ")) ', \
title = 'sin acceso secreto devops' \
--role = roles / secretmanager.admin \
--miembro = grupo: dev-accounts @ gblaquiere. dev
Ahora, las cuentas de desarrollador no tienen acceso a los secretos de DevOps , con la condición de que los equipos de DevOps nombren correctamente los secretos.
Y las cuentas de desarrollador también pueden crear nuevos secretos.
Proteja sus secretos, en cualquier momento
Con Secret Manager, sus secretos están a salvo y puede confiar en este servicio.
Sin embargo, debe configurar inteligentemente sus roles y permisos en su proyecto para evitar filtraciones secretas y, por lo tanto, brechas de seguridad, incluso desde adentro.
La condición IAM es una forma elegante de lograr este caso de uso y puede hacer mucho más.
Secret Manager: protege tus secretos de amenazas internas se publicó originalmente en Google Cloud - Community on Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.