Cómo aplicar seguridad en la fuente usando GitOps

Si su modelo de implementación de GitOps tiene problemas de seguridad (por ejemplo, un permiso mal configurado debido a un error tipográfico), esto se propagará hasta que se descubra en tiempo de ejecución , donde se analizan o encuentran la mayoría de los eventos de seguridad.

¿Qué sucede si puede solucionar posibles problemas de seguridad en su infraestructura en la fuente?

Empecemos con lo básico.

¿Qué es Git?

Git es un sistema de control de versiones distribuido de código abierto . Realiza un seguimiento de los cambios realizados en los archivos (normalmente archivos de texto como el código fuente) permitiendo y fomentando un modelo de trabajo colaborativo . Es el estándar de facto en los sistemas de control de versiones hoy en día.

Puede tener su propio repositorio git localmente en su computadora portátil, alojarlo en su propio servidor o usar algún proveedor como GitLab o GitHub.

Hay diferentes "flujos" sobre cómo administrar un repositorio (git-flow, github-flow, etc.), pero un ejemplo básico sobre cómo se usa git es algo como esto: Los cambios en los archivos son "comprometidos" por los usuarios por "bifurcar" el repositorio y hacer los cambios adecuados en una "rama".

Luego, el usuario crea una solicitud (ya sea "solicitud de extracción", "solicitud de combinación" o simplemente "enviar un parche") para incluir esos cambios en el repositorio.

Después de eso, generalmente ocurre una discusión entre el "propietario" y el usuario que crea la solicitud, y si todo va bien, el cambio se acepta y se agrega al repositorio.

NOTA: Si desea obtener más información, aquí hay información mucho más detallada sobre el mecanismo de solicitud de extracción de git.

Para ver un ejemplo del mundo real, simplemente explore su repositorio GitLab o GitHub de código abierto favorito y explore la pestaña Solicitud de extracción (o Solicitud de combinación) (o vea esto para ver uno divertido). Puede ver los cambios propuestos, comentarios, etiquetas, quién propuso los cambios, herramientas que ejecutan validaciones contra los cambios propuestos, notificaciones enviadas a las personas que miran el repositorio, etc.

¿Qué es GitOps?

En pocas palabras, GitOps es solo una metodología que utiliza un repositorio de git como la única fuente de verdad para sus activos de software para que pueda aprovechar el modelo de implementación de git (solicitudes de extracción, reversiones, aprobaciones, etc.) para su software.

Hay libros ( The Path to GitOps , GitOps and Kubernetes o GitOps Cloud-native Continuous Deployment ), documentos técnicos y más publicaciones de blog de las que podemos contar , pero permítanos profundizar en el propósito de GitOps echando un vistazo rápido a cómo evolucionaron las cosas. en los últimos años.

Antes de la nube, agregar un nuevo servidor para alojar su aplicación tomaba semanas. Tenías que pedir permisos, comprarlo y realizar muchas tareas manuales. Entonces, la virtualización hizo las cosas mucho más fáciles. Solicita una máquina virtual con algunas especificaciones y después de unos minutos, tiene acceso a ella.

Luego, la nube. Solicitar servidores, redes, almacenamiento e incluso bases de datos, colas de mensajería, contenedores, cosas de aprendizaje automático, sin servidor... ¡está a solo una llamada de API! Lo pides y unos segundos después lo obtienes, así de simple. Solo tienes que pagar por lo que usas. Esto también significa que la infraestructura se puede administrar como código que realiza llamadas a la API... y ¿dónde almacena su código? En un repositorio git (o cualquier otro sistema de versión de contenido).

El término GitOps fue acuñado en 2017 por Weaveworks y, parafraseando a OpenGitOps , un sistema GitOps se basa en los siguientes principios:

• Declarativa : define “qué”.
• Versionado e inmutable : de ahí "git".
• Tirado automáticamente : un agente observa el estado deseado y los cambios que ocurren en el código.
• Continuamente reconciliado : ¿alguien mencionó Kubernetes?

La esencia de la metodología de GitOps es básicamente un controlador o controladores (o agentes) de Kubernetes que se ejecutan en su clúster y observan los objetos de Kubernetes que se ejecutan sobre él (definidos por un CustomResource ) comparando el estado actual con el estado especificado en el repositorio de Git . Si no coincide, corrige la aplicación aplicando los manifiestos que se encuentran en el repositorio.

NOTA: Hay enfoques ligeramente diferentes para GitOps, por ejemplo, push vs pull, cómo manejar la administración de la configuración, etc. Esos son temas avanzados, pero por ahora, centrémonos en lo básico.

El siguiente diagrama muestra un sistema GitOps simplificado:

• El usuario envía un cambio de código al repositorio de Git.
• Luego, se activa un proceso en el repositorio para incorporar esos cambios en la propia aplicación, incluida la ejecución de herramientas de automatización contra ese nuevo código para validarlo.
• Una vez que todo está en su lugar, el agente de GitOps que se ejecuta en el clúster de Kubernetes, que está observando el repositorio, realiza la reconciliación entre el estado deseado (el código en el repositorio) y el estado actual (los objetos que se ejecutan en el propio clúster de Kubernetes).

Estar basado en Git significa que no hay fricciones para los desarrolladores. No necesitan preocuparse por una nueva herramienta con la que interactuar, sino que deben aplicar las mismas prácticas que se usan para administrar el código en el repositorio de Git.

Hablando de herramientas GitOps, ya hay algunas disponibles, incluidas herramientas de código abierto como Flux o ArgoCD , ambos proyectos de CNCF en incubación .

Para tener una idea de cómo se ve la definición de una aplicación a través de GitOps, este es un ejemplo de una aplicación simple (almacenada en un repositorio de GitHub) administrada por Flux o ArgoCD.

Con flujo:

 --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-example-app namespace: hello-world spec: interval: 30s ref: branch: master url: https://github.com/xxx/my-example-apps.git --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: my-example-app namespace: hello-world spec: interval: 5m0s path: ./myapp prune: true sourceRef: kind: GitRepository name: my-example-app targetNamespace: hello-world

Con ArgoCD:

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-example-app namespace: hello-world spec: destination: namespace: my-example-app server: https://kubernetes.default.svc project: default source: path: myapp/ repoURL: https://github.com/xxx/my-example-apps.git targetRevision: HEAD syncPolicy: automated: {} syncOptions: - CreateNamespace=true

Ambos hacen referencia al repositorio de Git donde se almacenan los manifiestos de la aplicación (implementaciones), los espacios de nombres y algunos detalles más.

GitOps frente a IaC

Infraestructura como código es una metodología para tratar los componentes básicos de su infraestructura como código utilizando diferentes técnicas y herramientas. Esto significa que, en lugar de crear manualmente su infraestructura, como máquinas virtuales, contenedores, redes o almacenamiento a través de la interfaz web de su proveedor de infraestructura favorito, los define como código y luego se crean/actualizan/administran con las herramientas que elija, como como terraform , crossplane , o pulumi , entre otros.

Los beneficios son enormes. Puede administrar su infraestructura como si fuera un código (ahora es un código) y aprovechar sus mejores prácticas de desarrollo (automatización, pruebas, trazabilidad, control de versiones, etc.) para sus activos de infraestructura. De hecho, existe una tendencia a usar "Infraestructura como software" como término porque es mucho más que solo código.

Hay toneladas de información sobre este tema, pero el siguiente recurso es un buen punto de partida.

Como probablemente se haya dado cuenta, GitOps aprovecha la infraestructura como código como modelo declarativo para definir la infraestructura. De hecho, IaC es uno de los pilares de GitOps. Pero es mucho más, ya que IaC no exige el resto de los principios de GitOps.

GitOps frente a DevOps

Hay muchas definiciones del término "DevOps". Depende de a quién le pregunte, pero en pocas palabras, "DevOps es la combinación de prácticas y herramientas para crear y entregar software reduciendo la fricción y a alta velocidad".

Las metodologías de DevOps pueden aprovechar GitOps, ya que GitOps proporciona un marco que coincide con las prácticas de DevOps, pero no es estrictamente necesario.

¿Qué pasa con NoOps?

NoOps fue acuñado por Forrester en 2021 y es un enfoque radical para manejar operaciones en el que el entorno de TI se abstrae y automatiza hasta el punto de que no es necesario administrarlo manualmente.

GitOps ayuda a reducir los cambios manuales al remediar aquellos con el estado deseado en el repositorio de Git, pero aplicar un NoOps real a todo el entorno de TI es una meta aspiracional más que una meta real a partir de hoy .

¿GitOps es solo para Kubernetes?

No. Kubernetes, el patrón de controlador y el modelo declarativo para definir objetos de Kubernetes son una combinación perfecta para una metodología de GitOps, pero eso no significa que las metodologías de GitOps no se puedan aplicar sin Kubernetes. Hay algunos desafíos si se usa GitOps fuera de Kubernetes, como el manejo de la idempotencia, la eliminación/creación de activos, la gestión de secretos, etc. Pero los principios de GitOps se pueden aplicar sin Kubernetes (y aplicando un poco de creatividad).

GitOps y seguridad

Hablemos ahora de los aspectos de seguridad. La mayoría de las herramientas de seguridad detectan posibles vulnerabilidades y problemas en tiempo de ejecución (demasiado tarde). Para solucionarlos, se debe realizar un proceso manual reactivo (p. ej., modificar directamente un parámetro en su objeto k8s con kubectl edit) o, idealmente, la solución se realizará en el origen y se propagará a lo largo de su cadena de suministro. Esto es lo que se llama “ Shift Security Left ”. Desde solucionar el problema cuando es demasiado tarde hasta solucionarlo antes de que suceda.

Esto no significa que todos los problemas de seguridad se puedan solucionar en la fuente, pero agregar una capa de seguridad directamente en la fuente puede evitar algunos problemas.

En primer lugar, se aplican las recomendaciones generales de seguridad.

• Reducir la superficie de ataque
• Cifre los secretos (usando Secretos externos o Secretos sellados)
• Segmentación de red
• RBAC
• Mantenga el software actualizado
• Hacer cumplir el privilegio mínimo
• Supervisar y medir
• …

Veamos algunos escenarios donde la metodología GitOps puede mejorar su seguridad en general:

• Evitar/Rechazar cambios manuales (evitando Drift) . El repositorio Git es la fuente de la verdad. Si intenta modificar la definición de la aplicación, la herramienta GitOps revertirá esos cambios aplicando la versión almacenada en el repositorio de Git.

• Reversión de cambios . Imagine que introdujo un posible problema de seguridad en una confirmación específica al modificar algún parámetro en la implementación de su aplicación. Al aprovechar las capacidades de Git, puede revertir el cambio si es necesario directamente en la fuente y la herramienta GitOps volverá a implementar su aplicación sin la interacción del usuario.

• Respuesta rapida. Si descubre que está usando una imagen de contenedor vulnerable en su aplicación (por ejemplo, MariaDB), solo necesita crear un PR para actualizar la etiqueta en el archivo de implementación y la herramienta GitOps usará la nueva etiqueta en una nueva implementación.

• Trazabilidad. Usando las capacidades de Git, puede verificar fácilmente cuándo se modificó un archivo, los cambios en sí mismos y el usuario que promovió los cambios. Tienes un registro de auditoría gratis .

• Recuperación de desastres. Una vez más, el repositorio de Git es la fuente de la verdad. Si necesita volver a implementar su aplicación porque sucedió algo, la definición está ahí (por supuesto, debe tener un plan de recuperación ante desastres para otras cosas, como los datos en sí).
• Control de acceso. Puede aplicar diferentes permisos a diferentes usuarios en sus repositorios de Git e incluso políticas como "solo fusionar un cambio después de dos revisiones positivas".

Esos beneficios son lo suficientemente buenos como para justificar el uso de metodologías de GitOps para mejorar su postura de seguridad y salieron de la caja, pero GitOps es una combinación de algunas cosas más. Podemos hacer mucho más. GitHub, GitLab y otros proveedores de repositorios de Git le permiten ejecutar acciones o canalizaciones en función de los cambios que realice en su repositorio de Git, incluso mediante una solicitud de extracción, por lo que las posibilidades son infinitas. Algunos ejemplos:

• pelusa La definición de la aplicación es código , ¿qué sucede si se verifica la definición en busca de una sintaxis incorrecta, parámetros faltantes y más? Hay herramientas (como el megalinter ) que se pueden ejecutar contra los cambios que has realizado para evitar sorpresas más adelante.

• Pruebas. Incluso puede automatizar la creación de un clúster de Kubernetes temporal para ejecutar su aplicación con los cambios y ejecutar algunas pruebas en su contra.

• Escaneo de vulnerabilidades . Comprobando las imágenes de contenedor que está utilizando en busca de vulnerabilidades antes de que se implementen en su entorno.

• Política como código. Aprovechando OPA , incluso puede aplicar políticas a sus manifiestos para verificar posibles problemas o políticas personalizadas

Pensamientos finales

La metodología GitOps trae algunas mejoras al modelo de implementación y beneficios de seguridad a la mesa sin tener que agregar otra herramienta .

Mejora la postura de seguridad al agregar una capa de "desplazamiento a la izquierda" directamente al código fuente y, gracias a la flexibilidad del modelo de solicitud de extracción, puede agregar fácilmente controles de seguridad adicionales sin afectar o modificar el tiempo de ejecución.

También publicado aquí .