Prácticas recomendadas para usar cuentas de servicio en las canalizaciones

Las pipelines de despliegue te permiten automatizar el proceso de tomar código o artefactos precompilados y desplegarlos en un Google Cloud entorno. Además, pueden ser una alternativa a las herramientas interactivas, como la Google Cloud consola o la CLI de Google Cloud.

Las pipelines de implementación se diferencian de las herramientas interactivas, como la Google Cloud consola o la CLI de gcloud, en la forma en que interactúan con Gestión de Identidades y Accesos, y debes tener en cuenta estas diferencias al proteger tus recursos Google Cloud.

Antes de Google Cloud permitirte acceder a un recurso, realiza una comprobación de acceso. Para llevar a cabo esta comprobación, la gestión de identidades y accesos suele tener en cuenta lo siguiente:

  • Tu identidad y las políticas de límites de acceso de principales asociadas
  • El recurso al que intentas acceder y sus políticas de permiso y denegación de gestión de identidades y accesos
  • El contexto de tu solicitud (posiblemente, la hora y la ubicación)

En una canalización de implementación, rara vez se llama a las Google Cloud APIs directamente. En su lugar, usa herramientas para acceder a los recursos de Google Cloud . Herramientas como la Google Cloud consola o la CLI de gcloud requieren que primero autorices la herramienta para acceder a los recursos en tu nombre. Al proporcionar esta autorización, das permiso a la herramienta para usar tu identidad al hacer llamadas a la API.

Al igual que la consola o la CLI de gcloud, una canalización de implementación actúa en tu nombre: toma tus cambios, expresados como código fuente, y los implementa en Google Cloud. Google Cloud Sin embargo, a diferencia de la consola o de la interfaz de línea de comandos de gcloud, una canalización de implementación no suele usar tu identidad para realizar la implementación: Google Cloud

  1. Como usuario, normalmente no interactúas directamente con una canalización de implementación. En su lugar, interactúas con un sistema de control de versiones (SCM) enviando cambios de código a un repositorio de origen o aprobando revisiones de código.

  2. El flujo de lanzamiento lee los cambios de código enviados desde el sistema de gestión de control de versiones y los lanza a Google Cloud.

    Para llevar a cabo la implementación, la canalización de implementación normalmente no puede usar tu identidad por los siguientes motivos:

    1. Es posible que el código fuente y sus metadatos no indiquen que eres el autor o que la información del autor no sea a prueba de manipulaciones (como en el caso de las confirmaciones de Git sin firmar).
    2. La identidad que has usado para enviar el código fuente puede ser diferente de tu identidad de Google Cloud, y las dos identidades no se pueden asignar

    Por lo tanto, la mayoría de las pipelines de implementación realizan implementaciones con su propia identidad mediante una cuenta de servicio.

  3. Cuando la canalización de implementación accede a Google Cloud, IAM permite o deniega el acceso únicamente en función de la identidad de la cuenta de servicio que usa la canalización, no de la identidad de tu cuenta de usuario.

Flujo de procesamiento de despliegue

Permitir que una canalización de implementación use una cuenta de servicio para acceder a Google Cloud tiene algunas ventajas:

  • El ciclo de vida de una cuenta de servicio no está vinculado al ciclo de vida de las cuentas de usuario. Si configuras una canalización para que use una cuenta de servicio, te aseguras de que el código se pueda implementar aunque el autor ya no trabaje en tu organización.
  • Cuando gestionas recursos mediante una canalización de implementación, no tienes que conceder acceso a los usuarios a los recursos o puedes limitar los permisos a acceso de solo lectura. Este enfoque puede facilitar la gestión de las políticas de permiso y denegación de IAM, y te permite obligar a los usuarios a utilizar la canalización de implementación para realizar todas las modificaciones.

Sin embargo, el uso de una cuenta de servicio también conlleva nuevas amenazas. Por ejemplo:

  • Suplantación de identidad: un agente malicioso podría intentar suplantar la identidad de la canalización de implementación o robar sus credenciales para obtener acceso a los recursos.
  • Apropiación de privilegios: se podría engañar a la canalización para que realice acciones que no debería llevar a cabo, lo que la convertiría en un confused deputy.
  • No repudio: después de que una canalización haya realizado una operación, puede que sea difícil reconstruir por qué se hizo y qué desarrollador o cambio de código la activó.
  • Manipulación: se podría hacer un uso inadecuado de una canalización para minar la integridad o los controles de seguridad de tus entornos de nube.
  • Divulgación de información: los agentes malintencionados pueden intentar usar la canalización de implementación para extraer datos confidenciales.

Protegerse frente a las amenazas de suplantación de identidad

Para conceder acceso a Google Clouda una canalización de implementación, normalmente debes hacer lo siguiente:

  1. Crear una cuenta de servicio
  2. Concede a la cuenta de servicio acceso a los recursos necesarios
  3. Configurar la canalización de implementación para que use la cuenta de servicio

Desde el punto de vista de IAM, la cuenta de servicio representa la canalización de implementación, pero la canalización de implementación y la cuenta de servicio son dos entidades independientes. Si no se protege correctamente, un agente malintencionado podría usar la misma cuenta de servicio, lo que le permitiría suplantar la identidad de la canalización de implementación.

En la siguiente sección se describen las prácticas recomendadas que pueden ayudarle a reducir el riesgo de que se produzcan este tipo de amenazas.

Prácticas recomendadas:

No adjuntes cuentas de servicio a las instancias de VM que usen los sistemas de CI/CD.
Usa cuentas de servicio específicas para cada flujo de implementación.
Utiliza la federación de identidades de cargas de trabajo siempre que sea posible.
Usa Controles de Servicio de VPC para reducir el impacto de las credenciales filtradas.

Evita asociar cuentas de servicio a instancias de VM que utilicen sistemas de integración continua y entrega continua

En el caso de las aplicaciones desplegadas en Compute Engine que necesiten acceder a recursos de Google Cloud, lo más recomendable es asociar una cuenta de servicio a la instancia de VM subyacente. En los sistemas de CI/CD que usan máquinas virtuales de Compute Engine para ejecutar diferentes flujos de procesamiento de despliegue, esta práctica puede ser problemática si se usa la misma instancia de máquina virtual para ejecutar diferentes flujos de procesamiento de despliegue que requieren acceso a distintos recursos.

En lugar de usar cuentas de servicio asociadas para que las canalizaciones de implementación accedan a los recursos, permite que cada canalización de implementación use una cuenta de servicio independiente. No adjuntes una cuenta de servicio a las instancias de VM que usen los sistemas de integración continua y entrega continua, o bien adjunta una cuenta de servicio que solo tenga acceso a servicios esenciales, como Cloud Logging.

Usar cuentas de servicio específicas para cada canalización de implementación

Si permites que varias pipelines de implementación usen la misma cuenta de servicio, IAM no podrá diferenciar entre las pipelines. Las canalizaciones tienen acceso a los mismos recursos y es posible que los registros de auditoría no contengan información suficiente para determinar qué canalización de implementación ha activado el acceso o el cambio de un recurso.

Para evitar esta ambigüedad, mantén una relación 1:1 entre las canalizaciones de implementación y las cuentas de servicio. Crea una cuenta de servicio específica para cada pipeline de implementación y asegúrate de hacer lo siguiente:

  • Incluye el nombre o el ID de la canalización de implementación en la dirección de correo de la cuenta de servicio. Si sigues un esquema de nomenclatura coherente, podrás determinar qué cuentas de servicio están conectadas a qué pipelines de implementación.
  • Solo debes conceder acceso a la cuenta de servicio a los recursos que necesite la canalización de implementación específica.

Usar la federación de identidades de cargas de trabajo siempre que sea posible

Algunos sistemas de integración continua y entrega continua, como GitHub Actions o GitLab, permiten que las pipelines de implementación obtengan tokens compatibles con OpenID Connect que afirmen la identidad de la pipeline de implementación. Puedes permitir que las canalizaciones de implementación usen estos tokens para suplantar la identidad de una cuenta de servicio mediante la federación de identidades de cargas de trabajo.

Usar la federación de identidades de cargas de trabajo te ayuda a evitar los riesgos asociados al uso de claves de cuentas de servicio.

Usar Controles de Servicio de VPC para reducir el impacto de las credenciales filtradas

Si un agente malintencionado consigue robar un token de acceso o una clave de cuenta de servicio de una de tus pipelines de implementación, podría intentar usar esta credencial y acceder a tus recursos desde otra máquina que controle.

De forma predeterminada, IAM no tiene en cuenta la geolocalización, la dirección IP de origen ni el proyecto de origen Google Cloud a la hora de tomar decisiones sobre el acceso. Por lo tanto, una credencial robada se puede usar desde cualquier lugar.

Puedes imponer restricciones en las fuentes desde las que se puede acceder a tus Google Cloud recursos colocando tus proyectos en un perímetro de servicio de VPC y usando reglas de entrada:

  • Si tu flujo de procesamiento de despliegue se ejecuta en Google Cloud, puedes configurar una regla de entrada para permitir el acceso solo desde el proyecto que contiene tu sistema de CI/CD.
  • Si tu canalización de implementación se ejecuta fuera de Google Cloud, puedes crear un nivel de acceso que solo permita el acceso desde determinadas ubicaciones geográficas o intervalos de IP. A continuación, crea una regla de entrada que permita el acceso a los clientes que cumplan este nivel de acceso.

Protección contra amenazas de manipulación

En el caso de algunos datos que almacenas en Google Cloud, puede que sea especialmente importante evitar que se modifiquen o eliminen sin autorización. Si te preocupa especialmente que se modifiquen o eliminen datos sin autorización, puedes caracterizar los datos como datos de alta integridad.

Para mantener la integridad de sus datos, debe asegurarse de que los Google Cloudrecursos que utiliza para almacenar y gestionar esos datos estén configurados de forma segura y de que mantengan su integridad.

Las canalizaciones de implementación pueden ayudarte a mantener la integridad de tus datos y recursos, pero también pueden suponer un riesgo: si la canalización de uno de sus componentes no cumple los requisitos de integridad de los recursos que gestiona, la canalización de implementación se convierte en un punto débil que puede permitir que agentes malintencionados manipulen tus datos o recursos.

En la siguiente sección se describen las prácticas recomendadas que pueden ayudarle a reducir el riesgo de sufrir amenazas de manipulación.

Prácticas recomendadas:

No permitas que las canalizaciones de implementación gestionen los controles de seguridad.

Limitar el acceso a los controles de seguridad

Para garantizar la seguridad y la integridad de tus datos y recursos en Google Cloud, utiliza controles de seguridad como los siguientes:

  • Políticas de permiso y políticas de denegación
  • Restricciones de las políticas de organización
  • Perímetros, niveles de acceso y políticas de entrada de Controles de Servicio de VPC

Estos controles de seguridad son recursos por sí mismos. La manipulación de los controles de seguridad pone en peligro la integridad de los recursos a los que se aplican. Por lo tanto, debes considerar que la integridad de los controles de seguridad es al menos tan importante como la integridad de los recursos a los que se aplican.

Si dejas que una canalización de despliegue gestione los controles de seguridad, será la canalización de despliegue la que se encargue de mantener la integridad de los controles de seguridad. Por lo tanto, debes considerar que la integridad de la propia canalización de implementación es al menos tan importante como la integridad de los controles de seguridad que gestiona y los recursos a los que se aplican estos controles.

Para limitar el impacto de una canalización de implementación en la integridad de tus recursos, haz lo siguiente:

  • No conceder acceso a las canalizaciones de implementación para permitir políticas, denegar políticas y otros controles de seguridad, así como restringir su acceso a otros recursos
  • Conceder acceso solo a determinados controles de seguridad, como las políticas de permiso y las políticas de denegación de un recurso o proyecto específico, sin conceder acceso a controles más amplios que afecten a varios recursos o proyectos

Si tu canalización de implementación, sus componentes y la infraestructura subyacente no pueden cumplir los requisitos de integridad de determinados controles de seguridad, es mejor que no permitas que las canalizaciones de implementación gestionen estos controles de seguridad.

Protegerse frente a amenazas de no repudio

En algún momento, puede que detectes actividad sospechosa que afecte a uno de tus recursos en Google Cloud. En ese caso, debes poder obtener más información sobre la actividad y, lo ideal, es que puedas reconstruir la cadena de eventos que ha llevado a ella.

Los registros de auditoría de Cloud te permiten saber cuándo se ha accedido a los recursos o se han modificado, así como qué usuarios han participado. Aunque los registros de auditoría de Cloud proporcionan un punto de partida para analizar la actividad sospechosa, es posible que la información que ofrecen no sea suficiente. Si usas las canalizaciones de implementación, también debes poder correlacionar los registros de auditoría de Cloud con los registros que genera tu canalización de implementación.

En esta sección se incluyen prácticas recomendadas que pueden ayudarte a mantener un registro de auditoría en Google Cloud y en tus pipelines de implementación.

Prácticas recomendadas:

Asegúrate de que puedes correlacionar los registros de la canalización de implementación con los registros de auditoría de Cloud.
Ajusta los periodos de conservación de los registros de la canalización de implementación y los registros de auditoría de Cloud.

Asegúrate de que puedes correlacionar los registros de la canalización de implementación con los registros de auditoría de Cloud

Los registros de auditoría de Cloud contienen marcas de tiempo e información sobre el usuario que ha iniciado una actividad. Si usas una cuenta de servicio específica para cada canalización de implementación, esta información te permite identificar la canalización de implementación que ha iniciado la actividad y también puede ayudarte a acotar qué cambios de código y ejecuciones de canalización podrían haber sido los responsables. Sin embargo, identificar la ejecución exacta de la canalización y el cambio de código que han provocado la actividad puede ser difícil si no se dispone de más información que permita correlacionar los registros de auditoría de Cloud con los registros de la canalización de implementación.

Puede enriquecer los registros de auditoría de Cloud para que contengan más información de varias formas, entre las que se incluyen las siguientes:

  • Cuando uses Terraform, especifica un motivo de la solicitud que indique que se está ejecutando una canalización de CI/CD.
  • Añade un X-Goog-Request-Reason encabezado HTTP a las solicitudes de la API y envía el ID de la ejecución de la canalización de implementación.
  • Usa un User-Agent personalizado que incluya el ID de la ejecución de la canalización de implementación.

También puedes enriquecer los registros emitidos por tu canalización de implementación:

  • Registra las solicitudes a la API realizadas por cada ejecución del flujo de procesamiento de CI/CD.
  • Cada vez que la API devuelva un ID de operación, registra el ID en los registros del sistema de integración continua y entrega continua.

Alinear los periodos de conservación de los registros de la canalización de implementación y los registros de auditoría de Cloud

Para analizar la actividad sospechosa relacionada con una canalización de implementación, normalmente necesitas varios tipos de registros, como los registros de auditoría de actividad de administrador, los registros de auditoría de acceso a datos y los registros de tu canalización de implementación.

Cloud Logging solo conserva los registros durante un periodo determinado. De forma predeterminada, este periodo de conservación es más corto para los registros de auditoría de acceso a los datos que para los registros de auditoría de actividad de administrador. El sistema que ejecuta tu canal de implementación también puede descartar sus registros después de un periodo determinado. En función de la naturaleza de tu flujo de implementación y de la importancia de los recursos que gestiona, es posible que estos periodos de conservación predeterminados no sean suficientes o no se ajusten a tus necesidades.

Para asegurarte de que los registros estén disponibles cuando los necesites, comprueba que los periodos de conservación de registros que utilizan los diferentes sistemas estén alineados y sean lo suficientemente largos.

Si es necesario, personaliza el periodo de conservación de los registros de auditoría de acceso a datos o configura un receptor personalizado para enrutar los registros a una ubicación de almacenamiento personalizada.

Prácticas recomendadas:

Evita conceder acceso directo a datos confidenciales.
Usa Controles de Servicio de VPC para evitar la filtración externa de datos.

Protegerse frente a las amenazas de divulgación de información

Si la cuenta de servicio de una canalización de implementación tiene acceso a datos confidenciales, un agente malicioso podría intentar usar la canalización de implementación para extraer esos datos. El acceso de un flujo de implementación a los datos puede ser directo o indirecto:

  • Directo: la cuenta de servicio de la canalización de implementación puede tener permiso para leer datos confidenciales de Cloud Storage, BigQuery u otras ubicaciones. Es posible que se haya concedido este acceso de forma intencionada, pero también puede ser el resultado accidental de haber concedido demasiado acceso.

    Si un agente malicioso obtiene acceso a una canalización de implementación con acceso directo a datos confidenciales, puede intentar usar el token de acceso de la cuenta de servicio para acceder a los datos y extraerlos.

  • Indirecto: para desplegar configuraciones o nuevas versiones de software, la cuenta de servicio de una canalización de despliegue puede tener permiso para crear o volver a desplegar recursos de computación, como instancias de máquina virtual de Compute Engine. Algunos de estos recursos pueden tener una cuenta de servicio asociada que conceda acceso a datos confidenciales.

    En esta situación, un agente malicioso podría intentar vulnerar la canalización de implementación para que implemente código malicioso en uno de los recursos de computación y permitir que este código filtre datos confidenciales.

En esta sección se incluyen prácticas recomendadas que pueden ayudarte a limitar el riesgo de revelar datos confidenciales.

Evita conceder acceso directo a datos confidenciales

Para desplegar infraestructura, configuración o nuevas versiones de software, una canalización de despliegue no suele requerir acceso a los datos. En su lugar, suele ser suficiente con limitar el acceso a los recursos que no contengan datos o, al menos, que no contengan datos confidenciales.

Para minimizar el acceso a datos que ya existen y que pueden ser confidenciales, puedes hacer lo siguiente:

  • En lugar de conceder acceso a toda la cuenta de servicio de una canalización de implementación, concede acceso solo a recursos específicos.
  • Concede acceso de creación sin permitir el acceso de lectura. Por ejemplo, si asignas el rol Creador de objetos de almacenamiento (roles/storage.objectCreator), puedes permitir que una cuenta de servicio suba objetos nuevos a un segmento de Cloud Storage sin concederle permiso para leer los datos que ya haya.
  • Limita la infraestructura como código (IaC) a los recursos menos confidenciales. Por ejemplo, usa IaC para gestionar instancias de máquinas virtuales o redes, pero no para gestionar conjuntos de datos confidenciales de BigQuery.

Usar Controles de Servicio de VPC para evitar la filtración externa de datos

Puedes reducir el riesgo de filtración externa de datos indirecta desplegando tus Google Cloud recursos en un perímetro de Controles de Servicio de VPC.

Si tu canalización de implementación se ejecuta fuera de Google Cloudo forma parte de otro perímetro, puedes conceder acceso a la cuenta de servicio de la canalización al perímetro configurando una regla de entrada. Si es posible, configura la regla de entrada para que solo permita el acceso desde las direcciones IP que usa la canalización de implementación y solo permita el acceso a los servicios que realmente necesita la canalización de implementación.

Protección contra amenazas de escalada de privilegios

Cuando una canalización de implementación usa una cuenta de servicio para acceder a recursos, lo hace independientemente del desarrollador o del usuario que haya creado un cambio en el código o en la configuración. Google CloudLa desconexión entre la cuenta de servicio de la canalización y la identidad del desarrollador hace que las canalizaciones de implementación sean propensas a ataques de confused deputy, en los que un agente pernicioso engaña a la canalización para que realice una acción que el agente pernicioso no tiene permiso para hacer y que la canalización ni siquiera debería realizar.

En esta sección se incluyen prácticas recomendadas que pueden ayudarte a reducir el riesgo de que se haga un uso inadecuado de tu canalización de implementación para transferir privilegios.

Prácticas recomendadas:

Limitar el acceso a la canalización de implementación y a todas las entradas.
Evita que una canalización de implementación modifique las políticas.
No reveles las credenciales de la cuenta de servicio en los registros.

Limitar el acceso a la canalización de implementación y a todas las entradas

La mayoría de las canalizaciones de implementación usan un repositorio de código fuente como fuente principal de entrada y pueden activarse automáticamente en cuanto detectan un cambio de código en determinadas ramas (por ejemplo, la rama main). Por lo general, las canalizaciones de implementación no pueden verificar si el código y la configuración que encuentran en el repositorio de código fuente son auténticos y fiables. Por lo tanto, la seguridad de esta arquitectura depende de lo siguiente:

  • Controlar quién puede enviar código y configuración al repositorio y a las ramas que usa la canalización de implementación.
  • Aplicar criterios que deben cumplirse antes de que se puedan confirmar los cambios (por ejemplo, revisiones de código correctas, análisis estáticos o pruebas automatizadas).

Para que estos controles sean eficaces, también debes asegurarte de que los infractores no puedan eludirlos de las siguientes formas:

  • Modificar la configuración del repositorio de código fuente o del flujo de implementación.
  • Manipulación de la infraestructura (como las máquinas virtuales y el almacenamiento) en la que se basa la canalización de implementación.
  • Modificar o sustituir entradas fuera del repositorio de código fuente, como paquetes, imágenes de contenedor o bibliotecas.

Cuando los gestiona una canalización de implementación, tus recursos en Google Cloud solo pueden ser tan seguros como tu canalización de implementación, su configuración, su infraestructura y sus entradas. Por lo tanto, debes proteger estos componentes si quieres que tus recursos estén protegidos.Google Cloud

Evitar que una canalización de implementación modifique las políticas

En la mayoría de los tipos de recursos, la gestión de identidades y accesos define un RESOURCE_TYPE.setIamPolicypermiso. Este permiso permite a un usuario modificar la política de acceso de un recurso, ya sea para conceder acceso a otros usuarios o para modificar y ampliar su propio acceso. A menos que se vea limitado por una política de denegación, conceder a un usuario o a una cuenta de servicio un permiso *.setIamPolicy les da acceso completo al recurso.

Siempre que sea posible, evita que una canalización de implementación modifique el acceso a los recursos. Cuando concedas acceso a los Google Cloud recursos Google Cloud a la cuenta de servicio de la canalización, usa roles que no incluyan ningún permiso *.setIamPolicy y evita usar los roles básicos Editor y Propietario.

En algunos flujos de procesamiento de implementaciones, es posible que sea inevitable conceder permiso para modificar las políticas de permiso o las políticas de denegación. Por ejemplo, el objetivo de un flujo de procesamiento de implementaciones puede ser crear recursos o gestionar el acceso a recursos. En estos casos, puedes limitar el grado en que la implementación puede modificar el acceso de las siguientes formas:

No reveles las credenciales de la cuenta de servicio en los registros

Los registros generados por una canalización de implementación suelen ser accesibles para un grupo de usuarios más amplio, incluidos los que no tienen permiso para modificar la configuración de la canalización. Es posible que estos registros revelen credenciales por error al mostrar lo siguiente:

  • Contenido de las variables de entorno
  • Argumentos de línea de comandos
  • Salida de diagnóstico

Si los registros revelan accidentalmente credenciales, como tokens de acceso, los agentes maliciosos podrían abusar de ellas para aumentar sus privilegios. Para evitar que los registros revelen credenciales, puedes hacer lo siguiente:

  • No envíes tokens de acceso ni otras credenciales como argumentos de línea de comandos
  • Evita almacenar credenciales en variables de entorno
  • Configura tu sistema de CI/CD para que detecte y oculte automáticamente tokens y otras credenciales, si es posible

Siguientes pasos