En esta guía se presentan algunas prácticas recomendadas cuando se usa Secret Manager. No es una lista exhaustiva de recomendaciones; Recomendamos que revises la descripción general de la plataforma para comprender el panorama general de Google Cloud y la descripción general de Secret Manager antes de leer esta guía.
Control de acceso
IAM protege el acceso a la API de Secret Manager. Sigue el principio de mínimo privilegio cuando otorgues permisos a los secretos.
- Limita la propiedad de la organización a una cuenta de administrador avanzado protegida.
- Segmenta las aplicaciones y los entornos (etapa de pruebas/producción) en proyectos independientes como se describe en Elige una jerarquía de recursos para tu zona de destino de Google Cloud. Esto puede ayudar a aislar entornos con vinculación de IAM a nivel de proyecto y garantiza que las cuotas se apliquen de forma independiente.
- Elige una función seleccionada con los permisos mínimos necesarios o crea una función personalizada si es necesario.
- Cuando los secretos de muchos servicios se encuentran en un solo proyecto, usa vinculaciones de IAM a nivel de secreto o condiciones de IAM para limitar el acceso al subconjunto necesario de secretos.
- El recomendador de IAM puede ayudar a identificar mejor las vinculaciones de IAM privilegiadas.
Se requieren credenciales para autenticarse en la API de Secret Manager. Todas las bibliotecas cliente usan una estrategia similar para buscar credenciales denominadas “credenciales predeterminadas de la aplicación”.
- Cuando desarrolles de forma local, usa
gcloud auth application-default login. Esto crea un archivo con credenciales que las bibliotecas cliente seleccionan de forma automática. - En Compute Engine y otras plataformas de procesamiento de Google Cloud, como Cloud Functions, las bibliotecas cliente obtienen credenciales a través del servidor de metadatos de instancia.
- En GKE, Workload Identity también proporciona credenciales a través de un servicio de metadatos.
- En otras plataformas, como Amazon Web Services o Microsoft Azure, considera configurar la federación de Workload Identity, que usa mecanismos de identidad existentes para autenticarse en las API de Google Cloud.
Se prefiere exportar todos estos métodos para exportar una credencial de cuenta de servicio porque no requieren el almacenamiento y acceso seguros a un secreto adicional fuera de la API de Secret Manager.
Prácticas de codificación
Pasar secretos a tu aplicación a través del sistema de archivos o de las variables de entorno es común, pero se debe evitar cuando sea posible debido a los siguientes motivos:
- Cuando se puede acceder a un secreto en el sistema de archivos, las vulnerabilidades de la aplicación, como los ataques de recorrido del directorio, pueden volverse más graves, ya que el atacante puede obtener la capacidad de leer el material del secreto.
- Cuando un secreto se consume a través de variables de entorno, una configuración incorrecta, como habilitar extremos de depuración o incluir dependencias que registran los detalles del entorno del proceso, puede filtrar secretos.
- Cuando sincronices material de secretos con otro almacén de datos (como los secretos de Kubernetes), ten en cuenta los controles de acceso de ese almacén de datos, por ejemplo:
- ¿El almacén de datos expande el acceso al secreto?
- ¿Es posible auditar el acceso del secreto?
- ¿El almacén de datos cumple con los requisitos de encriptación y regionalización de los datos en reposo?
Recomendamos usar la API de Secret Manager directamente (mediante una de las bibliotecas cliente proporcionadas o seguir la documentación de REST o GRPC).
Sin embargo, para algunas integraciones de productos, como las integraciones sin servidores, puedes pasar secretos a través del sistema de archivos o de las variables de entorno. Para obtener más información, consulta Usa Secret Manager con otros productos.
Administration
Elige la política de replicación automática cuando crees secretos, a menos que la carga de trabajo tenga requisitos de ubicación específicos (aplicables mediante la restricción constraints/gcp.resourceLocations).
Haz referencia a los secretos por su número de versión en lugar de usar el último alias. Implementa actualizaciones en los números de versión mediante tus procesos de actualización existentes. Por lo general, esto significa configurar tu aplicación con una versión secreta específica que se lee en el inicio. Si bien usar el alias más reciente puede ser conveniente, si hay un problema con la versión nueva del secreto, es posible que tu carga de trabajo no pueda usar la versión del secreto. Si fijas un número de versión, la configuración se puede validar y revertir mediante tus procesos de actualización existentes.
Inhabilita las versiones de los secretos antes de destruirlas o borrar los secretos. Esto ayuda a evitar interrupciones, ya que coloca el secreto en un estado que parece igual a destroy, pero que se puede revertir. Es decir, puedes inhabilitar y esperar una semana para asegurarte de que no hay dependencias persistentes antes de borrar datos de forma permanente.
No configures el expiration de los secretos de producción, a menos que estés seguro de que debería borrarse de forma irreversible. La función de vencimiento es más adecuada para la limpieza automática de entornos temporales. Considera las condiciones de IAM basadas en el tiempo como alternativa a los secretos vencidos.
Rota tus secretos periódicamente para lo siguiente:
- Limitar el impacto en el caso de un secreto filtrado.
- Asegúrate de que las personas que ya no requieran acceso a un secreto no puedan continuar usando uno al que se accedió previamente.
- Entrena de manera continua el flujo de rotación para reducir la probabilidad de una interrupción.
Supervisar los secretos de tu organización con Cloud Asset Inventory te permitirá realizar lo siguiente…
- Ayudar a identificar los secretos de tu organización.
- Identificar los requisitos de no cumplimiento de la organización, como la rotación, la configuración de la encriptación y la ubicación.
Habilitar los registros de acceso a los datos para obtener y analizar la información de la solicitud AccessSecretVersion. Habilitar esto a nivel de carpeta o de organización para aplicar el registro sin tener que configurarlo en cada secreto o proyecto.
Además de los controles de IAM, puedes limitar el acceso a la API de Secret Manager con controles basados en la red mediante la configuración de un perímetro de los Controles del servicio de VPC para tu organización.
La política de la organización constraints/iam.allowedPolicyMemberDomains se puede usar con el fin de limitar las identidades que se pueden agregar a las políticas de IAM para secretos.
Calcula el uso máximo de tu secreto (considera una “activación simultánea” que depende de las solicitudes debido a implementaciones de aplicaciones simultáneas o al ajuste de escala automático de tu servicio) y asegúrate de que tu proyecto tenga cuota suficiente para controlar ese evento. Si se necesita más cuota, solicita un aumento.