|
Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado. |
|
Esta es documentación inédita para Admission Controller 1.34-dev. |
Rego
|
El soporte para Rego está disponible en estas versiones:
El soporte para políticas de Rego admite datos contextuales de la versión SUSE Security Admission Controller 1.9. |
El lenguaje Rego es un lenguaje específico de dominio para habilitar políticas como código. Rego es un lenguaje inspirado en Datalog.
Hay dos formas de escribir políticas Rego para implementar políticas como código en Kubernetes, Open Policy Agent y Gatekeeper.
Las siguientes secciones muestran cómo los dos marcos son diferentes, aunque utilizan el mismo lenguaje. Si estás más interesado en la implementación de Admission Controller, puedes visitar directamente la documentación específica del marco enlazada a continuación.
Un lenguaje, dos marcos
Open Policy Agent (OPA)
Open Policy Agent es un proyecto que te permite implementar políticas como código en cualquier proyecto. Puedes usar OPA para cualquier verificación basada en políticas que necesite tu aplicación.
En este contexto, escribir políticas para Kubernetes es simplemente utilizar OPA. Al usar webhooks de admisión de Kubernetes, es posible evaluar solicitudes usando OPA, que ejecuta las políticas escritas en Rego.
OPA tiene integración opcional con Kubernetes a través de su kube-mgmt sidecar.
Cuando se despliega en Kubernetes, y con el servidor OPA evaluando las políticas Rego,
es capaz de replicar los recursos de Kubernetes configurados en Rego.
Así que esos recursos de Kubernetes son visibles para todas las políticas.
Con OPA puedes definir políticas dentro de los objetos ConfigMap de Kubernetes.
Puedes leer más sobre ello en
su página del proyecto.
Observando las diferencias
Tanto las políticas de OPA como las de Gatekeeper utilizan Rego para describir políticas como código. Cada solución tiene diferencias a la hora de escribir políticas en Rego, como se muestra en las siguientes secciones.
Punto de entrada
El punto de entrada es el nombre de una regla dentro de un paquete, y es la regla invocada por el tiempo de ejecución cuando se ejecuta la política.
Limitaciones actuales
Políticas conscientes del contexto
Las políticas conscientes del contexto son políticas que no evalúan la solicitud de entrada de forma aislada.
Toman otros factores en cuenta para tomar una decisión.
Por ejemplo, una política que evalúa recursos con espacio de nombres,
y utiliza una anotación,
en el espacio de nombres padre para configurar algo en la política.
Otro ejemplo sería una política que evalúa recursos Ingress,
pero para tomar una decisión también tiene la lista de los recursos Ingress existentes.
La idea de las políticas conscientes del contexto también puede extenderse a recursos personalizados, así que tu política podría querer evaluar una solicitud basada en los recursos personalizados actualmente utilizados también.
Tanto OPA como Gatekeeper soportan políticas conscientes del contexto, a partir de la versión Admission Controller 1.9.
Más detalles sobre políticas conscientes del contexto están aquí.
Políticas de mutación
Gatekeeper tiene soporte para políticas de mutación, pero Admission Controller aún no ha implementado políticas de mutación con compatibilidad con Gatekeeper. Puedes utilizar políticas que usen el SDK Admission Controller para escribir políticas de mutación, pero actualmente, no puedes ejecutar políticas de mutación de Gatekeeper en Admission Controller.