Prácticas recomendadas para Secret Manager

En esta guía se presentan algunas prácticas recomendadas cuando se usa Secret Manager. No es una lista exhaustiva de recomendaciones; Te recomendamos revisar la Descripción general de Platform para comprender el panorama general de Google Cloud y la descripción general conceptual 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.

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

Pasa secretos a la aplicación a través del sistema de archivos o las variables de entorno es común, pero debe evitarse cuando sea posible:

  • 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?

Por estos motivos, cuando sea posible, recomendamos usar directamente la API de Secret Manager (mediante una de las bibliotecas cliente proporcionadas o seguir la documentación REST o GRPC).

Administración

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 borrarlas. Esto ayuda a evitar interrupciones, ya que coloca el secreto en un estado similar al de destruir, pero es reversible. Es decir, puedes inhabilitar y esperar una semana para estar seguro de que no haya dependencias persistentes antes de borrar los datos de forma permanente.

No configures el vencimiento 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.

Rotar tus secretos de forma periódica te permitirá realizar 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.