Prácticas recomendadas para usar cuentas de servicio en canalizaciones

Nota interna de Google: jpassing@ escribió esta página

Las canalizaciones de implementación te permiten automatizar el proceso de tomar código o artefactos compilados con anterioridad y, luego, implementarlos en un entorno de Google Cloud, y pueden ser una alternativa al uso de herramientas interactivas como la consola de Google Cloud o Google Cloud CLI.

Las canalizaciones de implementación difieren de las herramientas interactivas como la consola de Google Cloud o la CLI de gcloud en la forma en que interactúan con la administración de identidades y accesos, y debes tener en cuenta estas diferencias cuando protejas tus recursos de Google Cloud.

Antes de que Google Cloud te permita acceder a un recurso, realiza una verificación de acceso. Para realizar esta verificación, IAM suele considerar lo siguiente:

  • Tu identidad
  • El recurso al que intentas acceder y sus políticas de permiso y denegación de IAM
  • El contexto de tu solicitud (posiblemente incluye la hora y la ubicación)

En una canalización de implementación, rara vez se llama directamente a las APIs de Google Cloud. En su lugar, usas herramientas para acceder a los recursos de Google Cloud. Las herramientas como la consola de Google Cloud o la CLI de gcloud requieren que primero autorices el acceso de la herramienta a los recursos por ti. Si proporcionas esta autorización, le otorgas a la herramienta permiso para usar tu identidad cuando realizas llamadas a la API.

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

  1. Como usuario, por lo general, no interactúas directamente con una canalización de implementación. En su lugar, interactúas con un sistema de control de origen (SCM) mediante el envío de los cambios de código a un repositorio de código fuente o la aprobación de revisiones de código.

  2. La canalización de implementación lee los cambios en el código enviado desde el sistema de SCM y los implementa en Google Cloud.

    Para realizar la implementación, por lo general, la canalización de implementación no puede usar tu identidad debido a lo siguiente:

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

    Por lo tanto, la mayoría de las canalizaciones 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 rechaza el acceso solo en función de la identidad de la cuenta de servicio que usa la canalización, no de la cuenta de usuario.

Canalización de implementación

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 se desconecta del ciclo de vida de las cuentas de usuario. Cuando configuras una canalización para usar una cuenta de servicio, te aseguras de que el código se pueda implementar incluso si el autor del código ya no está en tu organización.
  • Cuando administras recursos mediante una canalización de implementación, no necesitas otorgar a los usuarios acceso a los recursos o puedes limitar los permisos a un acceso de solo lectura. Este enfoque puede facilitar la administración de políticas de IAM y te permite forzar a los usuarios a usar la canalización de implementación para realizar todas las modificaciones.

Sin embargo, usar una cuenta de servicio también presenta nuevas amenazas. Estos incluyen los siguientes:

  • Falsificación de identidad: Una persona malintencionada podría intentar falsificar la identidad de la canalización de implementación o robar sus credenciales para obtener acceso a los recursos.
  • Elevación de privilegios: Se puede engañar a la canalización para que realice acciones que no se espera que se realicen, lo que hace que se convierta en una delegada delegada.
  • No repudio: Después de que una canalización realiza una operación, puede ser difícil reconstruir por qué se hizo y qué desarrollador o cambio de código la activo.
  • Manipulación: Se puede abusar de una canalización para socavar los controles de integridad o seguridad de los entornos de nube.
  • Divulgación de información: Las personas malintencionadas podrían intentar usar la canalización de implementación para el robo de datos confidenciales.

Protégete contra amenazas de falsificación de identidad

Para otorgar a una canalización de implementación acceso a Google Cloud, por lo general, debes hacer lo siguiente:

  1. Crea una cuenta de servicio
  2. Otorga a la cuenta de servicio acceso a los recursos necesarios
  3. Configura la canalización de implementación para usar la cuenta de servicio

Desde la perspectiva 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 separadas. Si no se protege correctamente, es posible que una persona malintencionada pueda usar la misma cuenta de servicio, lo que le permite "falsificar" la identidad de la canalización de implementación.

En la siguiente sección, se describen las prácticas recomendadas que pueden ayudarte a reducir el riesgo de esas amenazas.

Recomendaciones:

Evita adjuntar cuentas de servicio a instancias de VM que usan los sistemas de CI/CD.
Usa cuentas de servicio dedicadas por canalización de implementación.
Usa la federación de identidades para cargas de trabajo siempre que sea posible.
Usa los Controles del servicio de VPC para reducir el impacto de las credenciales filtradas.

Evita conectar cuentas de servicio a las instancias de VM que usan los sistemas de CI/CD

Para las aplicaciones implementadas en Compute Engine que necesitan acceso a los recursos de Google Cloud, por lo general, es mejor conectar una cuenta de servicio a la instancia de VM subyacente. En los sistemas de CI/CD que usan VM de Compute Engine para ejecutar diferentes canalizaciones de implementación, esta práctica puede ser problemática si la misma instancia de VM se puede usar para ejecutar diferentes canalizaciones de implementación que requieran acceso a recursos diferentes.

En lugar de usar cuentas de servicio conectadas para permitir que las canalizaciones de implementación accedan a los recursos, permite que cada canalización de implementación use una cuenta de servicio separada. Evita conectar una cuenta de servicio a las instancias de VM que usan los sistemas de CI/CD o conecta una cuenta de servicio que esté limitada a acceder a servicios esenciales, como Cloud Logging.

Usa cuentas de servicio dedicadas por canalización de implementación

Cuando permites que varias canalizaciones de implementación usen la misma cuenta de servicio, IAM no puede distinguir entre las canalizaciones: 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 activó un recurso para acceder a él o cambiarlo.

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 dedicada para cada canalización de implementación y asegúrate de realizar las siguientes acciones:

  • Incorpora el nombre o el ID de la canalización de implementación en la dirección de correo electrónico de la cuenta de servicio. Seguir un esquema de nombres coherente te ayuda a determinar la canalización de implementación a partir del nombre de la cuenta de servicio y viceversa.
  • Solo debes otorgar a la cuenta de servicio acceso a los recursos que necesita la canalización de implementación específica.

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

Algunos sistemas de CI/CD, como las acciones de GitHub o GitLab, permiten que las canalizaciones de implementación obtengan tokens compatibles con OpenID Connect que confirman la identidad de la canalización de implementación. Puedes permitir que las canalizaciones de implementación usen estos tokens para actuar en nombre de una cuenta de servicio con el uso de la federación de identidades para cargas de trabajo.

Usar la federación de identidades para cargas de trabajo te ayuda a evitar los riesgos asociados con el uso de claves de cuenta de servicio.

Usa los Controles del servicio de VPC para reducir el impacto de las credenciales filtradas

Si una persona malintencionada logra robar un token de acceso o una clave de cuenta de servicio de una de tus canalizaciones de implementación, es posible que intente usar esta credencial y acceder a tus recursos desde una máquina diferente que controlan.

De forma predeterminada, IAM no tiene en cuenta la ubicación geográfica, la dirección IP de origen o el proyecto de origen de Google Cloud cuando se toman decisiones de acceso. Por lo tanto, una credencial robada se puede usar desde cualquier lugar.

Para imponer restricciones sobre las fuentes desde las que se puede acceder a tus recursos de Google Cloud, coloca tus proyectos en un perímetro de servicio de VPC y usa reglas de entrada:

  • Si tu canalización de implementación se ejecuta en Google Cloud, puedes configurar una regla de entrada para permitir solo el acceso 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 ciertas ubicaciones geográficas o rangos de IP. Luego, crea una regla de entrada que permita el acceso a los clientes que cumplan con este nivel de acceso.

Protégete contra amenazas de manipulación

Para algunos datos que almacenas en Google Cloud, puede que te resulte particularmente importante evitar las modificaciones o eliminaciones no autorizadas. Si una modificación o eliminación no autorizada es particularmente importante, puedes caracterizar los datos como datos de alta integridad.

A fin de mantener la integridad de tus datos, debes asegurarte de que los recursos de Google Cloud que usas para almacenar y administrar esos datos estén configurados de forma segura y debes mantener su integridad.

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

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

Recomendaciones:

Evita permitir que las canalizaciones de implementación administren los controles de seguridad.

Limita el acceso a los controles de seguridad

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

  • Políticas de permiso y denegadas
  • Restricciones de las políticas de la organización
  • Perímetros de Controles del servicio de VPC, niveles de acceso y políticas de entrada

Estos controles de seguridad son recursos por sí mismos. La manipulación de los controles de seguridad pone en riesgo la integridad de los recursos a los que se aplican los controles de seguridad. Como resultado, 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 permites que una canalización de implementación administre los controles de seguridad, depende de la canalización de implementación mantener la integridad de los controles de seguridad. Como resultado, debes considerar que la integridad de la canalización de implementación es al menos tan importante como la integridad de los controles de seguridad que administra y los recursos a los que se aplican estos controles.

Puedes limitar el impacto de una canalización de implementación en la integridad de tus recursos de las siguientes maneras:

  • No otorgando acceso a las canalizaciones de implementación para permitir políticas, rechazar políticas y otros controles de seguridad, y restringir su acceso a otros recursos
  • Otorgagando acceso solo a los controles de seguridad seleccionados, como las políticas de permiso y rechazo de un recurso o proyecto específico, sin otorgar acceso a controles más amplios que afecten varios recursos o proyectos

Si tu canalización de implementación, sus componentes y su infraestructura subyacente no pueden satisfacer las demandas de integridad de ciertos controles de seguridad, es mejor evitar que las canalizaciones de implementación administren estos controles de seguridad.

Protégete contra amenazas de no repudio

En algún momento, es posible que notes actividad sospechosa que afecta a uno de tus recursos en Google Cloud. En ese evento, debes poder obtener más información sobre la actividad e, idealmente, poder reconstruir la cadena de eventos que llevaron a ella.

Los Registros de auditoría de Cloud te permiten saber cuándo se accedió a los recursos o se modificaron, y qué usuarios participaron. Aunque los registros de auditoría de Cloud proporcionan un punto de partida para analizar la actividad sospechosa, es posible que la información proporcionada por estos registros no sea suficiente: si usas canalizaciones de implementación, también debes correlacionar los registros de auditoría de Cloud con los registros producidos por tu canalización de implementación.

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

Recomendaciones:

Asegúrate de que puedas correlacionar los registros de canalización de implementación con los Registros de auditoría de Cloud.
Alinea los períodos de retención de los registros de la canalización de implementación y los Registros de auditoría de Cloud.

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

Los Registros de auditoría de Cloud contienen información y marcas de tiempo del usuario que inició una actividad. Si usas una cuenta de servicio dedicada para cada canalización de implementación, esta información te permite identificar la canalización de implementación que inició la actividad y también puede ayudarte a limitar qué cambios de código y ejecuciones de canalización podrían haber sido responsables. Sin embargo, identificar la ejecución de canalización exacta y el cambio de código que generó la actividad puede ser difícil sin más información que te permita correlacionar los Registros de auditoría de Cloud con los registros de la canalización de implementación.

Puedes enriquecer los Registros de auditoría de Cloud para que contengan más información de las siguientes maneras:

  • Cuando uses Terraform, especifica un motivo de solicitud que indique que se ejecutó la canalización de CI/CD.
  • Agrega un encabezado HTTP X-Goog-Request-Reason a las solicitudes a la API y pasa el ID de ejecución de la canalización de implementación.
  • Usa un User-Agent personalizado que incorpore el ID de la ejecución de canalización de implementación.

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

  • Registra las solicitudes a la API que realiza cada ejecución de canalización de CI/CD.
  • Siempre que la API muestre un ID de operación, registra el ID en los registros del sistema de CI/CD.

Alinea los períodos de retenció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, por lo general, necesitas varios tipos de registros, incluidos los Registros de auditoría de actividad del administrador, los registros de auditoría de acceso a los datos y los registros de tu canalización de implementación.

Cloud Logging solo conserva los registros durante un período determinado. De forma predeterminada, este período de retención es más corto para los registros de auditoría de acceso a los datos que para los registros de auditoría de la actividad del administrador. El sistema que ejecuta la canalización de implementación también puede descartar sus registros después de un período determinado. Según la naturaleza de tu canalización de implementación y la importancia de los recursos que administra tu canalización de implementación, estos períodos de retención predeterminados pueden ser insuficientes o estar mal alineados.

Para garantizar que los registros estén disponibles cuando los necesites, asegúrate de que los períodos de retención de registros que usan los diferentes sistemas estén alineados y sean lo suficientemente largos.

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

Recomendaciones:

Evita otorgar acceso directo a datos confidenciales.
Usa los Controles del servicio de VPC para ayudar a evitar el robo de datos.

Protégete contra las amenazas de divulgación de información

Cuando la cuenta de servicio de una canalización de implementación tiene acceso a datos confidenciales, un actor malicioso puede intentar usar la canalización de implementación para robar esos datos. El acceso de una canalización de implementación a los datos puede ser directo o indirecto:

  • Directo: Es posible que la cuenta de servicio de la canalización de implementación tenga permiso para leer datos confidenciales de Cloud Storage, BigQuery o de otras ubicaciones. Es posible que este acceso se haya otorgado de forma intencional, pero también podría ser un resultado accidental de otorgar demasiado acceso.

    Si una persona malintencionada obtiene acceso a una canalización de implementación con acceso directo a los datos confidenciales, podría intentar usar el token de acceso de la cuenta de servicio para acceder a los datos y robarlos.

  • Indirecta: Para implementar la configuración o versiones nuevas de software, es posible que la cuenta de servicio de una canalización de implementación tenga permiso para crear o volver a implementar instancias de VM, aplicaciones de Cloud Run o algún otro recurso de procesamiento. Algunos de estos recursos de procesamiento pueden tener una cuenta de servicio adjunta que otorgue acceso a los datos confidenciales.

    En esta situación, una persona malintencionada podría intentar poner en riesgo la canalización de implementación a fin de que implemente código malicioso en uno de los recursos de procesamiento y dejar que este código robe datos confidenciales.

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

Evita otorgar acceso directo a datos confidenciales

Para implementar infraestructura, configuración o versiones de software nuevas, una canalización de implementación a menudo no requiere acceso a los datos existentes. En general, a menudo es suficiente limitar el acceso a los recursos que no contienen datos o que al menos no contienen datos confidenciales.

Estas son algunas formas de minimizar el acceso a los datos existentes y potencialmente confidenciales:

  • En lugar de otorgar a la cuenta de servicio de una canalización de implementación acceso a un proyecto completo, solo otorga acceso a recursos específicos.
  • Otorga acceso de creación sin permitir acceso de lectura. Por ejemplo, si otorgas la función Creador de objetos de almacenamiento (roles/storage.objectCreator), puedes permitir que una cuenta de servicio suba objetos nuevos a un bucket de Cloud Storage sin otorgarle permiso para leer datos existentes.
  • Limita la infraestructura como código (IaC) a recursos menos confidenciales. Por ejemplo, usa IaC para administrar instancias de VM o redes, pero no para administrar conjuntos de datos de BigQuery confidenciales.

Usa los Controles del servicio de VPC para ayudar a evitar el robo de datos

Puedes reducir el riesgo de robo de datos indirectos si implementas tus recursos de Google Cloud en un perímetro de Controles del servicio de VPC.

Si tu canalización de implementación se ejecuta fuera de Google Cloud o es parte de un perímetro diferente, puedes otorgar a la cuenta de servicio de la canalización acceso al perímetro mediante la configuración de 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 que solo permita el acceso a los servicios que la canalización de implementación realmente necesita.

Protégete contra amenazas de elevación de privilegios

Cuando una canalización de implementación usa una cuenta de servicio para acceder a los recursos de Google Cloud, lo hace sin importar el desarrollador o el usuario que autorizó un cambio de código o configuración. La 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 los ataques de engaño de aplicación delegada, en los que una persona malintencionada engaña el canalización para realizar una acción que no puede hacer por sí misma la persona que actúa de mala fe y que la canalización no debería realizar.

En esta sección, se brindan prácticas recomendadas que pueden ayudarte a reducir el riesgo de que se abuse de la canalización de implementación para la elevación de privilegios.

Recomendaciones:

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

Limita 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 su fuente principal de entrada y pueden activarse de forma automática en cuanto detecten un cambio de código en ciertas 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 confiables. Por lo tanto, la seguridad de esta arquitectura depende de lo siguiente:

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

Para que estos controles sean eficaces, también debes asegurarte de que las personas malintencionadas no puedan evitarlos, lo que puedes lograr mediante estos pasos:

  • Modifica la configuración del repositorio de código fuente o la canalización de implementación.
  • Manipula la infraestructura (como las VMs y el almacenamiento) que sustenta la canalización de implementación.
  • Modifica o reemplaza entradas fuera del repositorio de código fuente, como paquetes, imágenes de contenedores o bibliotecas.

Cuando los administra una canalización de implementación, tus recursos de Google Cloud solo pueden alcanzar el nivel de seguridad de tu canalización de implementación, su configuración, su infraestructura y sus entradas. Por lo tanto, debes proteger estos componentes tanto como deseas que estén protegidos tus recursos de Google Cloud.

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

Para la mayoría de los tipos de recursos, IAM define un permiso RESOURCE_TYPE.setIamPolicy. Con este permiso, un usuario puede modifcar la política de permiso de IAM de un recurso, ya sea para otorgar acceso a otros usuarios o modificar y extender su propio acceso. A menos que esté restringido por una política de denegación, otorgar a un usuario o cuenta de servicio un permiso *.setIamPolicy tiene el efecto de otorgarles acceso completo al recurso.

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

En el caso de algunas canalizaciones de implementación, es inevitable otorgar permisos para modificar las políticas de permiso o de denegación: por ejemplo, el propósito de una canalización de implementación podría ser crear recursos nuevos o administrar el acceso a los recursos existentes. En estos casos, puedes limitar en qué medida la implementación puede modificar el acceso. Para esto, haz lo siguiente:

No reveles credenciales de cuenta de servicio en registros

Los registros que genera una canalización de implementación suelen ser accesibles para un grupo más grande de usuarios, incluidos los que no tienen permiso para modificar la configuración de la canalización. Es posible que estos registros revelen credenciales por accidente mediante la repetición:

  • Contenido de las variables de entorno
  • Argumentos de la línea de comandos
  • Resultado del diagnóstico

Si los registros revelan credenciales como tokens de acceso por accidente, las personas que actúan de mala fe podrían abusar de estas credenciales para escalar sus privilegios. Algunas formas de evitar que los registros revelen las credenciales son las siguientes:

  • Evita pasar tokens de acceso o cualquier otra credencial como argumentos de la línea de comandos
  • Evita almacenar credenciales en variables de entorno
  • Configura el sistema de CI/CD para detectar y enmascarar los tokens y otras credenciales de forma automática, si es posible

¿Qué sigue?