SUSE Security Admission Controller vs OPA Gatekeeper

Tanto OPA Gatekeeper como Kubernetes pueden escribir directivas de validación y mutación.

Estas directivas pueden dirigirse a cualquier tipo de recurso de Kubernetes, incluyendo Recursos Personalizados.

Escribes directivas de OPA Gatekeeper utilizando Rego. Rego es un lenguaje de consulta creado por el proyecto Open Policy Agent.

Puedes escribir Admission Controller directivas utilizando diferentes paradigmas. Los autores de directivas pueden usar tanto lenguajes de programación tradicionales (como Go, Rust y otros) como Lenguajes Específicos de Dominio (por ejemplo, Rego y CEL). En Admission Controller se escriben directivas de validación y mutación de la misma manera.

A veces, una política necesita datos sobre el estado actual del clúster para tomar una decisión de validación o mutación. Por ejemplo, una política que valida recursos de Ingress podría necesitar conocer otros recursos de Ingress ya definidos en el clúster para asegurar que no ocurran conflictos. Admission Controller llama a estas directivas "conscientes del contexto".

Tanto OPA Gatekeeper como Admission Controller admiten estos tipos de directivas.

Al desplegar OPA Gatekeeper, un administrador de Kubernetes decide qué tipo de datos del clúster poner a disposición de las directivas en el momento de la evaluación.

Es importante destacar cómo estos datos son accesibles por todas las directivas desplegadas.

Por ejemplo, si una directiva de OPA Gatekeeper requiere acceso a Secrets de Kubernetes, todas las demás directivas desplegadas también pueden leer estos datos.

Por el contrario, Admission Controller proporciona un acceso granular a los recursos del clúster. Cada directiva tiene acceso solo a los recursos que el administrador de Kubernetes especifica. Intentar leer datos no autorizados es bloqueado de inmediato y reportado a los administradores del clúster.

OPA Gatekeeper tiene un Recurso Personalizado a nivel de clúster, que permite la definición de directivas y cómo y dónde hacerlas cumplir.

Admission Controller tiene dos tipos diferentes de Recursos Personalizados utilizados para declarar directivas. Uno funciona a nivel de clúster, el otro está en un espacio de nombres. El nombre del Recurso Personalizado en un espacio de nombres es AdmissionPolicy.

Las directivas desplegadas a través de un recurso AdmissionPolicy afectan solo a los recursos creados dentro del espacio de nombres al que pertenecen. Debido a eso, puedes permitir que los usuarios de Kubernetes que no son administradores tengan los privilegios de RBAC necesarios para gestionar recursos AdmissionPolicy, en los espacios de nombres a los que pueden acceder.

Esto permite a los administradores de Kubernetes delegar el trabajo relacionado con las directivas.

OPA Gatekeeper y las directivas Admission Controller tienen el código fuente de la directiva (Rego para OPA Gatekeeper, CEL para Admission Controller) en el Recurso Personalizado que define una directiva en Kubernetes.

Además, las directivas Admission Controller pueden tener el código fuente de la directiva gestionado como imágenes de contenedor (para Rego, Go, Rust, …​). Una vez construidas, se envían a los registros de contenedores como artefactos OCI.

Puedes firmar y verificar las directivas Admission Controller utilizando herramientas de imágenes de contenedor como cosign, del proyecto Sigstore project.

Puedes distribuir las directivas Admission Controller entre registros de contenedores distribuidos geográficamente utilizando las herramientas y procesos tradicionales adoptados para imágenes de contenedor.

Tanto OPA Gatekeeper como Admission Controller se gestionan utilizando metodologías GitOps.

Sin embargo, para OPA Gatekeeper, hay un acoplamiento entre el código Rego de la directiva y el Recurso Personalizado utilizado para desplegarlo en Kubernetes. Esto introduce pasos adicionales en las canalizaciones CI/CD.

Rego tiene herramientas de prueba que permiten la creación de suites de pruebas de unidad. Escribir pruebas y ejecutarlas en una canalización CI/CD es esencial para asegurar que las directivas se comporten como se espera.

Para utilizar estas herramientas de prueba, el código fuente de la directiva debe estar disponible en archivos de texto dedicados. Es imposible leer el código fuente de los archivos YAML utilizados para declarar la directiva de OPA Gatekeeper. La canalización CI/CD debe sincronizar el código fuente Rego para probarlo con el código definido en el Recurso Personalizado del OPA Gatekeeper. Puedes hacer esto utilizando herramientas de terceros.

Las directivas Admission Controller tienen canalizaciones CI/CD como los microservicios tradicionales. Normalmente, su código fuente reside en un repositorio de Git y luego, utilizando sistemas tradicionales de CI/CD, se ejecutan pruebas unitarias en él. Escribes pruebas unitarias utilizando los marcos de prueba del lenguaje empleado para escribir la directiva.
Una vez que todas las pruebas pasan, compilas la directiva a WebAssembly y la subes a un registro de contenedores.
Puedes realizar la prueba utilizando la herramienta CLI , sin requerir un clúster de Kubernetes en funcionamiento.
Define estos servidores mediante un Recurso Personalizado llamado . Una vez que todas las pruebas pasan, compilas la directiva a WebAssembly y la subes a un registro de contenedores. Este tipo de canalización suele ser mantenido por el autor de la política.

Los administradores de Kubernetes suelen mantener otras canalizaciones de automatización que reaccionan a nuevas versiones de la política (utilizando herramientas de automatización como Dependabot, Renovate bot, updatecli y otras), o a cambios en la configuración de la política.

La canalización prueba la política contra diferentes tipos de solicitudes. Puedes realizar la prueba utilizando la herramienta CLI kwctl, sin requerir un clúster de Kubernetes en funcionamiento. La herramienta CLI kwctl utiliza el mismo motor de evaluación que utiliza la pila Admission Controller desplegada en un clúster de Kubernetes.

Tanto OPA Gatekeeper como Admission Controller pueden desplegar directivas utilizando dos modos de operación diferentes:

El mismo servidor evalúa todas las directivas de OPA Gatekeeper. Por el contrario, Admission Controller permite la definición de múltiples servidores de evaluación. Define estos servidores mediante un Recurso Personalizado llamado PolicyServer.

Al declarar una directiva Admission Controller, el administrador de Kubernetes decide qué PolicyServer la alberga.

Esto permite escenarios interesantes como los siguientes:

A medida que se añaden, eliminan y reconfiguran directivas, los recursos ya presentes en el clúster pueden volverse no conformes.

Tanto OPA Gatekeeper como Admission Controller tienen un escáner que opera en segundo plano. Este escáner evalúa los recursos ya definidos en el clúster y señala aquellos que no son conformes.

La única diferencia entre OPA Gatekeeper y Admission Controller es cómo se guardan los resultados del escáner.

OPA Gatekeeper añade los detalles de la violación al campo status de un recurso personalizado Constraint dado (ver aquí).

Admission Controller En cambio, almacena los resultados dentro de un conjunto de Recursos Personalizados de Informes definidos por openreports.io.