Si su (por ejemplo, un permiso mal configurado debido a un error tipográfico), , donde se analizan o encuentran la mayoría de los eventos de seguridad. modelo de implementación de GitOps tiene problemas de seguridad esto se propagará hasta que se descubra en tiempo de ejecución ¿Qué sucede si puede solucionar posibles problemas de seguridad en su infraestructura en la fuente? Empecemos con lo básico. ¿Qué es Git? . Realiza un seguimiento de los cambios realizados en los archivos (normalmente archivos de texto como el código fuente) . Es el estándar de facto en los sistemas de control de versiones hoy en día. es un sistema de control de versiones distribuido de código abierto Git permitiendo y fomentando un modelo de trabajo colaborativo 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, hay información mucho más detallada sobre el mecanismo de solicitud de extracción de git. aquí 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 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. esto ¿Qué es GitOps? En pocas palabras, para que pueda aprovechar el modelo de implementación de git (solicitudes de extracción, reversiones, aprobaciones, etc.) para su software. GitOps es solo una metodología que utiliza un repositorio de git como la única fuente de verdad para sus activos de software Hay libros ( , o ), y publicaciones de las , pero permítanos profundizar en el propósito de echando un vistazo rápido a cómo evolucionaron las cosas. en los últimos años. The Path to GitOps GitOps and Kubernetes GitOps Cloud-native Continuous Deployment documentos técnicos más blog de que podemos contar GitOps 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 y, parafraseando , un sistema GitOps se basa en los siguientes principios: 2017 por Weaveworks a OpenGitOps : define “qué”. Declarativa : de ahí "git". Versionado e inmutable : un agente observa el estado deseado y los cambios que ocurren en el código. Tirado automáticamente : ¿alguien mencionó Kubernetes? Continuamente reconciliado La (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 ) . Si no coincide, la aplicación aplicando los manifiestos que se encuentran en el repositorio. esencia de la metodología de GitOps es básicamente un controlador o controladores CustomResource comparando el estado actual con el estado especificado en el repositorio de Git corrige 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 o , ambos . Flux ArgoCD 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 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 , , o , entre otros. Infraestructura como código terraform crossplane pulumi Los beneficios son enormes. Puede administrar su infraestructura como si fuera un código (ahora 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. es Hay toneladas de información sobre este tema, pero el es un buen punto de partida. siguiente recurso 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 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. 2021 GitOps ayuda a reducir los cambios manuales al aquellos con el estado deseado en el repositorio de Git, pero . remediar 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 y el 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 (y aplicando un poco de creatividad). patrón de controlador modelo declarativo los principios de GitOps se pueden aplicar sin Kubernetes 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 “ ”. Desde solucionar el problema cuando es demasiado tarde hasta solucionarlo antes de que suceda. Shift Security Left 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: . 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. Evitar/Rechazar cambios manuales (evitando Drift) . 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. Reversión de cambios 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. Respuesta rapida. 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 . Trazabilidad. de auditoría gratis 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í). Recuperación de desastres. 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". Control de acceso. 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 o 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: acciones canalizaciones La definición de la aplicación , ¿qué sucede si se verifica la definición en busca de una sintaxis incorrecta, parámetros faltantes y más? Hay herramientas (como el ) que se pueden ejecutar contra los cambios que has realizado para evitar sorpresas más adelante. pelusa es código megalinter Incluso puede automatizar la para ejecutar su aplicación con los cambios y ejecutar algunas pruebas en su contra. Pruebas. creación de un clúster de Kubernetes temporal . Comprobando las que está utilizando en busca de vulnerabilidades antes de que se implementen en su entorno. Escaneo de vulnerabilidades imágenes de contenedor Aprovechando , incluso puede aplicar políticas a sus manifiestos para verificar posibles problemas o políticas personalizadas Política como código. OPA Pensamientos finales La y . metodología GitOps trae algunas mejoras al modelo de implementación beneficios de seguridad a la mesa sin tener que agregar otra herramienta 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. Mejora la postura de seguridad al agregar una capa de "desplazamiento a la izquierda" directamente al código fuente También publicado . aquí
