Prácticas recomendadas para la administración de políticas mediante Anthos Config Management y GitLab

En este documento, se destaca cómo usar Anthos Config Management y GitLab para administrar varios clústeres de Kubernetes en un entorno de producción. Proteger el repositorio de Anthos Config Management es un paso de implementación importante, y este documento puede ayudarte con ese proceso. Este documento, en el que se supone que estás familiarizado con Kubernetes y Git, es útil si implementas Anthos Config Management para su uso en producción.

Si operas una plataforma que aloja apps para tu organización, es importante que tengas implementadas políticas que contribuyan a su protección. Las políticas son reglas que tienen el objetivo de proteger la plataforma, además de las apps y los datos que se encuentran en ella. La plataforma aplica estas políticas en función de los parámetros de configuración que describen las políticas. Cuando se aplican políticas, se pueden mejorar la seguridad y la estabilidad de la plataforma.

Anthos Config Management te ayuda a administrar políticas a gran escala para plataformas se basan en Google Kubernetes Engine (GKE), clústeres de Anthos, o en otras distribuciones de Kubernetes. Anthos Config Management te permite crear y administrar objetos de Kubernetes en varios clústeres a la vez. Puedes administrar cualquier objeto de Kubernetes con Anthos Config Management, pero su utilidad reside, en especial, en la aplicación de políticas como las que se describen a continuación:

  • PodSecurityPolicies: Evita que los Pods usen el usuario raíz de Linux.
  • NetworkPolicies: Controla el tráfico de red dentro de tus clústeres.
  • ClusterRoles y ClusterRoleBindings: Controlan los permisos dentro de un clúster.

Como se muestra en el siguiente diagrama, Anthos Config Management es una herramienta de tipo GitOps, ya que usa un repositorio de Git como su mecanismo de almacenamiento y fuente de información.

Arquitectura de la configuración de Kubernetes en Git.

Con Anthos Config Management, puedes implementar y administrar objetos de Kubernetes mediante la interacción con este repositorio de Git. Obtener acceso de escritura a la rama principal del repositorio de Git de Anthos Config Management implica ser administrador de los clústeres que Anthos Config Management administra. El repositorio de Anthos Config Management contiene información que le resulta útil a un posible atacante, por lo que es importante que el repositorio esté protegido.

En este documento, se usa la Administración del código fuente (SCM) de GitLab como servicio de hosting del repositorio de Git y se describen las prácticas recomendadas para usar Anthos Config Management y GitLab en conjunto a fin de administrar varios clústeres de Kubernetes.

Arquitectura de GitLab y Anthos Config Management

En el siguiente diagrama, se muestra la arquitectura de implementación de Anthos Config Management con GitLab para administrar tres clústeres de Kubernetes: uno en GKE, uno en clústeres de Anthos alojados en VMware y uno en otro proveedor de servicios en la nube.

Arquitectura de implementación de Anthos Config Management con GitLab.

En el diagrama anterior, se ilustran los siguientes pasos en la canalización:

  1. Para realizar un cambio en la configuración de uno de esos clústeres o de todos ellos, un usuario envía una modificación, llamada solicitud de combinación (MR), que debe validarse en GitLab.
  2. La MR activa una canalización automatizada de CI/CD de GitLab, el sistema de integración y entrega continua compilado en GitLab, para probar y validar la configuración.
  3. Un administrador aprueba o rechaza la MR. Después de la aprobación, el cambio se combina en el repositorio de Git.
  4. Después de la aprobación, los agentes de Anthos Config Management que se ejecutan en cada clúster leen esta modificación desde GitLab y la aplican a su clúster.

Prácticas recomendadas para el hosting de GitLab en el contexto de Anthos Config Management

En esta sección, te enseñamos las prácticas recomendadas que debes seguir cuando uses la SCM de GitLab para alojar y administrar repositorios de Anthos Config Management. También se aplican las prácticas recomendadas generales para alojar GitLab, como configurar una arquitectura con alta disponibilidad y copias de seguridad periódicas, pero están fuera del alcance de este documento.

Restringe el acceso de administrador

Cualquier persona con acceso raíz a la máquina virtual (o al clúster de Kubernetes) en la que se aloja GitLab puede omitir las funciones de seguridad de GitLab y, por lo tanto, debe considerarse un administrador de Anthos Config Management. Esta suposición también se aplica a cualquier persona que sea administrador de GitLab o que tenga acceso de escritura a la base de datos de GitLab. Si otorgas privilegios de administrador en GitLab, acceso raíz a la máquina virtual (o al clúster de Kubernetes) en la que se aloja GitLab o acceso a la base de datos de GitLab, quienes reciban esos permisos también podrán realizar cambios en Anthos Config Management. Para obtener más información, consulta la documentación sobre permisos de GitLab.

Si usas Compute Engine, usa la administración de identidades y accesos (IAM) y el servicio de Acceso al SO para controlar quién tiene acceso a la instancia. En particular, la función de acceso de administrador del SO de Compute otorga acceso raíz a la instancia.

Si usas GKE, usa IAM y RBAC para controlar quién puede acceder al clúster.

Sé cuidadoso con las actualizaciones

GitLab lanza una versión por mes y varias versiones de parche entre cada lanzamiento. Como cualquier software, GitLab proporciona parches de seguridad en algunas de estas versiones. Por esta razón, debes mantener tu instancia de GitLab lo más actualizada posible. Para obtener más información, consulta Updating GitLab (Actualiza GitLab).

Sigue las prácticas recomendadas específicas de Google Cloud para alojar GitLab en Google Cloud

Si alojas GitLab en Google Cloud, debes dedicar un proyecto de Cloud a GitLab. Debes colocar este proyecto de Cloud directamente en tu nodo de organización, no en una carpeta. Estas recomendaciones pueden reducir la probabilidad de que se generen los siguientes errores en la configuración de IAM:

  • Si GitLab comparte un proyecto de Cloud con otras apps, corres el riesgo de otorgar acceso de administrador a GitLab de manera accidental cuando otorgas acceso a las otras apps.
  • Si colocas ese proyecto de Cloud en una carpeta, corres el riesgo de otorgar acceso a él de forma accidental si otorgas acceso a la carpeta.

Si implementas GitLab en Google Cloud, también te recomendamos que aproveches los siguientes servicios administrados:

  • Usa Cloud SQL para PostgreSQL a fin de alojar la base de datos de GitLab. Cloud SQL se encarga de la alta disponibilidad y las copias de seguridad por ti.
  • Usa Memorystore para Redis como el servidor de Redis de GitLab. Memorystore se encarga de la alta disponibilidad por ti.
  • Usa Cloud Storage para almacenar copias de seguridad, artefactos de compilación y cargas de usuarios.

Si deseas obtener más información, consulta Implementa GitLab listo para la producción en Google Kubernetes Engine.

Autenticación y control de acceso para GitLab

Para fines de auditoría o depuración, es importante que puedas identificar quién hizo un cambio en la política, y que el personal de TI también use esas identidades para administrar distintos recursos.

Usa identidades unificadas

Según el diseño, interactúas con Anthos Config Management a través de un repositorio de Git en el que creas, actualizas y borras recursos. En el repositorio de Git, controlas qué pueden hacer los usuarios y dónde puedes auditar todas las actividades. Implementar el control de acceso y la auditoría es más fácil si las identidades que usan los empleados son las mismas en todas partes: en Google Cloud, en GitLab y en los sistemas locales. Las identidades unificadas te permiten realizar referencias cruzadas de permisos y registros de auditoría en diferentes sistemas.

En GitLab, puedes auditar eventos en grupos, instancias y proyectos, además de consultar los registros del sistema en busca de eventos a nivel de servicio de GitLab. Las funciones de los eventos de auditoría de GitLab abarcan los niveles con licencia empresarial.

Opciones en caso de que no uses Google como proveedor de identidad

Puedes federar Google Cloud con muchos de los IdP populares, como Okta, Active Directory o Azure Active Directory. Puedes configurar GitLab para usar Okta o Active Directory.

Opciones en caso de que uses Google como proveedor de identidad

Si usas Google como proveedor de identidad, puedes usar el proveedor de OmniAuth de OAuth 2.0 de Google o el LDAP seguro. Sin embargo, si deseas sincronizar grupos con GitLab, como se recomienda en la siguiente sección, debes usar el LDAP seguro. LDAP seguro está disponible con Cloud Identity Premium y Google Workspace Enterprise. Para obtener más información, consulta About the Secure LDAP service (Información sobre el servicio del LDAP seguro).

Sincroniza grupos con GitLab

Sin importar la tecnología que se use para identificar a los usuarios, es útil agruparlos a fin de configurar su acceso. Los grupos te permiten pensar en estos usuarios en un nivel superior cuando otorgas permisos. Por ejemplo, puedes pensar “Otorgo acceso de administrador a los entornos de producción a mi grupo de operaciones”, en lugar de “Otorgo acceso de administrador a los entornos de producción a Bob, Alice, Claudia y Dinesh”. Si tus procesos de Recursos Humanos están bien integrados en tus sistemas de TI, la membresía del grupo también se administra de forma automática cuando se contrata un empleado, o bien cuando un empleado abandona la empresa o cambia de función. Si usas grupos, esta integración implica que, por lo general, no tienes que actualizar la configuración del control de acceso.

Debido a que Anthos Config Management es un sistema delicado, es importante recurrir a los grupos de usuarios para controlar el acceso a Anthos Config Management. En GitLab, puedes compartir un proyecto con un grupo de usuarios y especificar el nivel de acceso que obtendrán los miembros de este grupo.

Aplica la autenticación de dos factores

Debes usar la autenticación de dos factores (2FA), también conocida como verificación en dos pasos, para mejorar la seguridad de la organización. Las credenciales robadas y los ataques de suplantación de identidad son dos vectores de ataque comunes, y la 2FA ayuda a establecer protección contra ambos. Debido a la naturaleza confidencial del repositorio de Git de Anthos Config Management, las cuentas de los usuarios que interactúan con Anthos Config Management deben estar lo más protegidas posible, lo que implica habilitar la 2FA para esos usuarios.

Si configuras el inicio de sesión único (SSO) para GitLab, debes aplicar la 2FA mediante tu proveedor de SSO. Si usas Google como proveedor de SSO, puedes habilitar la 2FA.

Si no configuraste el SSO para GitLab, puedes aplicar la 2FA en GitLab directamente.

Usa tokens o claves de implementación para conectar agentes de Anthos Config Management a GitLab

Como se describe en el documento Instala Anthos Config Management, puedes conectar agentes de Anthos Config Management al repositorio mediante los métodos habituales de Git: HTTP(s) o SSH. Si usas HTTP(s) para acceder a los repositorios alojados en GitLab, no uses una cuenta de usuario, ya que esto puede causar problemas de licencia y usuarios que usan sus propias cuentas para configurar Anthos Config Management. Las claves y los tokens de implementación de GitLab son una mejor alternativa. Una clave de implementación es una clave SSH que no está vinculada a un usuario específico, pero que los sistemas automatizados pueden usar para realizar operaciones de Git. Este es el tipo de acceso seguro que necesita Anthos Config Management. Un token de implementación tiene el mismo uso que una clave de implementación, pero puedes usarlo para autenticarte a través de HTTP(s) en lugar de SSH.

Las claves y los tokens de implementación únicos te permiten controlar y revocar el acceso de los agentes de Anthos Config Management al repositorio de Git por clúster. Evita usar las claves de implementación <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="opBB/mAJqPUFZffWWDKJfMvOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwlKMkBQSfMxp5fl+Mc9AjFx4o6T+DhcfK0B6wN+3j0FU=" track-metadata-position="body" track-name="externalLink" track-type="solution">global para Anthos Config Management y las claves de tokens <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="EVE38A1n4riTbiBLnLIE18vOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwnjars0LTR/vDhAa2T615gjvG0B0C/P1DzOlB98jatvw=" track-metadata-position="body" track-name="externalLink" track-type="solution">group. Puedes usarlas para fines diferentes a Anthos Config Management, lo que genera efectos secundarios no deseados si se cambia la configuración.</atarget="external"></atarget="external">

Administra quién puede aprobar solicitudes de combinación

De forma predeterminada, GitLab usa funciones para otorgar permisos en los proyectos de GitLab. Por ejemplo, un usuario con la función de desarrollador puede abrir una solicitud de combinación, y un usuario con la función de encargado de mantenimiento puede aprobarla. Es posible que, al principio, este sistema de permisos funcione bien para Anthos Config Management, pero que tengas problemas a medida que crezca tu huella de Anthos Config Management y Kubernetes. Es posible que los encargados de mantenimiento del repositorio de Anthos Config Management se vean sobrecargados por la cantidad de solicitudes de combinación que deben procesar y aprobar.

Puedes aprovechar las funciones premium de GitLab para resolver este problema:

  • Puedes usar los propietarios de código para delegar permisos de aprobación según los archivos o los directorios. Esta característica es útil porque Anthos Config Management usa una estructura de directorio para describir clústeres y espacios de nombres. Mediante los propietarios de código, puedes delegar permisos de aprobación en un espacio de nombres específico en todos tus clústeres, por ejemplo.
  • Puedes usar las aprobaciones de solicitudes de combinación para requerir que diferentes personas de equipos distintos aprueben una solicitud antes de que se combine. Por ejemplo, puedes exigir que dos responsables de aprobación, uno del equipo de operaciones y otro del equipo de seguridad, aprueben una solicitud de combinación.

En el siguiente diagrama, se ilustra la división técnica de una organización y se muestra un ejemplo de cómo la delegación de aprobación puede funcionar en un entorno de producción.

Arquitectura de ejemplo de la jerarquía en una organización.

En el diagrama anterior, hay un director de tecnología con varios equipos que le brindan información: un equipo de seguridad, un equipo de la plataforma y varios equipos de apps.

El repositorio de Git de Anthos Config Management de esta organización tiene la siguiente estructura (solo se muestran directorios, no archivos):

.
├─ system
├─ clusterregistry
├─ cluster
└─ namespaces
   ├─ cicd
   ├─ audit
   └─ applications
      ├─ team-a
      └─ team-b

Para obtener más información sobre cada directorio, consulta Usa el repositorio de Anthos Config Management.

Con esta estructura, la organización puede usar las funciones de GitLab que se mencionaron antes para implementar el siguiente proceso:

  • El director de tecnología debe aprobar cualquier modificación en la raíz del repositorio o en el directorio de system.
  • Un miembro del equipo de la plataforma debe aprobar cualquier modificación en el directorio de clusterregistry.
  • Un miembro del equipo de la plataforma y un miembro del equipo de seguridad deben aprobar cualquier modificación en el directorio de cluster.
  • Un miembro del equipo de la plataforma debe aprobar cualquier modificación en el directorio de namespaces.
  • Los siguientes equipos deben aprobar cualquier modificación en los subdirectorios del directorio de namespaces:

    • El subdirectorio de cicd representa un espacio de nombres dedicado a las herramientas de integración continua y entrega continua (CI/CD). Un miembro del equipo de la plataforma debe aprobar cualquier cambio.
    • El subdirectorio de audit representa un espacio de nombres dedicado a las herramientas de auditoría. Un miembro del equipo de seguridad debe aprobar cualquier cambio.
    • El subdirectorio de applications contiene todos los recursos creados para cada espacio de nombres de la app. Un miembro del equipo de la plataforma y un miembro del equipo de seguridad deben aprobar cualquier cambio.
    • Los subdirectorios de team-a y team-b representan los espacios de nombres dedicados al equipo A y al equipo B. Quien está a cargo de ese equipo debe aprobar cualquier cambio.

Implementar este proceso es más fácil si los grupos del proveedor de identidad están sincronizados con GitLab que si no lo están. Puedes requerir varias aprobaciones de grupos diferentes para una solicitud de combinación. Para obtener más información, consulta Sincroniza grupos mediante GitLab y Editing approvals (Edita aprobaciones).

Inhabilita ejecutores compartidos

Puedes usar la CI de GitLab para probar de forma automática tus políticas de Anthos Config Management antes de implementarlas. La CI de GitLab usa ejecutores para realizar los trabajos que deseas. Esos ejecutores pueden compartirse con toda la instancia de GitLab, en cuyo caso son mantenidos por el mismo equipo que mantiene la instancia de GitLab, o estar dedicados a grupos o proyectos de GitLab.

Debido a la naturaleza confidencial del repositorio de Anthos Config Management, debes evitar usar ejecutores compartidos para probar el código de Anthos Config Management. En su lugar, usa ejecutores dedicados a los proyectos de Anthos Config Management mantenidos por las personas que pueden aprobar solicitudes de combinación.

Resumen de las recomendaciones

En esta sección, se resumen las recomendaciones de las secciones anteriores. Si usas GitLab para alojar el repositorio de Git de Anthos Config Management, te recomendamos las siguientes acciones:

  • Establece el control sobre quién tiene acceso de administrador a GitLab, ya que esas personas también obtienen acceso de administrador a Anthos Config Management.
  • Actualiza GitLab de manera periódica y cada vez que se lance un parche de seguridad.
  • Dedica un proyecto de Cloud a GitLab en tu nodo de organización si alojas GitLab en Google Cloud.
  • Configura todos tus sistemas, incluido GitLab, para usar el mismo proveedor de identidad.
  • Si es posible, sincroniza tus grupos de usuarios existentes con GitLab mediante la función de sincronización de grupos de LDAP, que es una función con licencia de GitLab Enterprise.
  • Aplica la 2FA a los usuarios que interactúan con Anthos Config Management para establecer protección contra los problemas que pueden surgir por el robo de credenciales y la suplantación de la identidad de una credencial.
  • Cuando configures los agentes de Anthos Config Management, realiza las siguientes acciones:
    • Configura los agentes de Anthos Config Management a fin de que usen SSH y claves de implementación o HTTPS y tokens de implementación para conectarse a GitLab.
    • Evita usar HTTP sin encriptar.
    • Crea una clave o un token de implementación únicos para cada clúster de Kubernetes en el repositorio de Anthos Config Management.
    • Configura las claves y los tokens de implementación directamente en el repositorio de Anthos Config Management y evita el uso de claves de implementación global y tokens de implementación de grupo para Anthos Config Management.
  • Ten cuidado con las demoras en la aprobación de solicitudes de combinación en el repositorio de Anthos Config Management. Si notas un aumento irracional, usa los propietarios de código o las aprobaciones de solicitudes de combinación avanzadas para delegar permisos de aprobación a más personas de la organización.
  • Inhabilita los ejecutores compartidos en el proyecto de Anthos Config Management y usa solo los ejecutores dedicados a este proyecto.

¿Qué sigue?