Uso de controladores de admisión para mejorar la seguridad de Kubernetes

Si trabaja con Kubernetes, probablemente esté familiarizado con sus funciones de seguridad básicas, como RBAC y las políticas de red. Estas herramientas son útiles para establecer reglas básicas que determinen qué acciones pueden realizar los distintos usuarios o servicios de su clúster.

Pero puede que a veces necesite más granularidad o características que las que soportan el RBAC o las políticas de red. O bien es posible que desee realizar controles adicionales para validar un recurso antes de incorporarlo a su clúster.

Aquí es donde entran en juego los controladores de admisión de Kubernetes. Los controladores de admisión ofrecen una solución altamente extensible para realizar controles de seguridad que van más allá de las reglas de autenticación, autorización y seguridad de red que usted implemente a través de otros tipos de marcos de políticas de Kubernetes. También son fundamentales para conectar Kubernetes con herramientas de seguridad externas que ofrezcan funciones de análisis y cumplimiento aún más avanzadas.

Los controladores de admisión son un elemento opcional, y es posible que no los necesite para configuraciones sencillas que se pueden proteger sin problemas mediante RBAC básico o políticas de red. Sin embargo, para proteger clústeres complejos a gran escala, los controladores de admisión son un recurso que probablemente querrá aprovechar.

En este artículo se definen los controladores de admisión de Kubernetes, se explica su funcionamiento y se revisa el proceso típico para utilizarlos con fines de seguridad.

¿Qué son los controladores de admisión en Kubernetes?

Un controlador de admisión de Kubernetes es un código que evalúa las solicitudes al servidor de la API de Kubernetes y luego determina si permite o rechaza la solicitud.

La evaluación tiene lugar después de que el servidor de la API haya autenticado y autorizado la solicitud, pero antes de que esta se conceda y ejecute.

En otras palabras, aunque el servidor de la API haya resuelto que una solicitud es válida (algo que hace basándose en los RBAC Roles y ClusterRoles que usted ha configurado), los controladores de admisión evaluarán la solicitud y determinarán si la aceptan o no basándose en su propio conjunto de reglas.

Ventajas de los controladores de admisión

Los controladores de admisión ofrecen varias ventajas importantes como parte de una estrategia de seguridad de Kubernetes:

Doble comprobación de las solicitudes: Los controladores de admisión sirven en cierto modo como una segunda línea de defensa contra las solicitudes no válidas que puedan haber esquivado sus controles RBAC (debido a una mala configuración en una política RBAC, por ejemplo).
Flexibilidad de las reglas: Los controladores de admisión pueden evaluar las solicitudes y establecer reglas basadas en parámetros que no se pueden configurar (al menos no fácilmente) a través de RBAC. Esto es importante porque RBAC define reglas basadas solo en identidades y acciones. Los controladores de admisión ofrecen más matices, como la capacidad de limitar las solicitudes de recursos o impedir la ejecución de comandos en un container privilegiado.
Integraciones de terceros: Algunos controladores de admisión permiten el uso de webhooks. Puede utilizar webhooks para activar acciones en sistemas de seguridad de terceros. Esto significa que los controladores de admisión permiten integrar herramientas de seguridad externas en Kubernetes sin tener que ejecutar esas herramientas directamente en la API de Kubernetes. Posiblemente esta sea la característica más potente de los controladores de admisión.

Cómo trabajar con los controladores de admisión

Este es el proceso para utilizar los controladores de admisión en Kubernetes.

Habilitar los controladores de admisión en el clúster

Para utilizar los controladores de admisión en Kubernetes, primero debe asegurarse de que la función de los controladores de admisión esté habilitada en el archivo kube-apiserver.yaml de su clúster (ubicado generalmente en el directorio /etc/kubernetes/manifests/ del master o los nodos maestros de Kubernetes).

Si está presente la bandera –enable-admission-plugins, los controladores de admisión están habilitados para su clúster.

Elegir controladores de admisión específicos

La bandera –enable-admission-plugins puede ir seguida de una lista separada por comas, como la siguiente:

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition
,Priority,DefaultTolerationSeconds,DefaultStorageClass,StorageObjectInUseProtection
,PersistentVolumeClaimResize,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,RuntimeClass
,ResourceQuota

Esta lista identifica los controladores de admisión específicos que están activados para su clúster. La documentación de Kubernetes explica en detalle todos los controladores de admisión disponibles.

Si la bandera –enable-admission-plugins está presente pero no va seguida de una lista, Kubernetes habilita un conjunto de controladores de admisión predeterminados. En las versiones actuales de Kubernetes, estos son:

NamespaceLifecycle
LimitRanger
ServiceAccount
TaintNodesByCondition
Priority
DefaultTolerationSeconds
DefaultStorageClass
StorageObjectInUseProtection
PersistentVolumeClaimResize
RuntimeClass
CertificateApproval
CertificateSigning
CertificateSubjectRestriction
DefaultIngressClass
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
ResourceQuota

Por lo tanto, puede utilizar los controladores de admisión predeterminados o puede definir explícitamente qué controladores de admisión habilitar.

Deshabilitar los controladores de admisión

Si lo desea, puede deshabilitar explícitamente los controladores de admisión utilizando la bandera –disable-admission-plugins=… en el archivo kube-apiserver.yaml.

Esta bandera es útil si está utilizando el conjunto de controladores predeterminados, pero quiere deshabilitar ciertos controladores dentro de ese conjunto.

Comprobar los controladores de admisión activos

Si no está seguro de qué controladores de admisión están habilitados en su clúster, ejecute este comando para ver una lista:

kube-apiserver -h | grep enable-admission-plugins

Configurar los controladores de admisión

Kubernetes aplicará automáticamente los controladores de admisión que usted habilite en su clúster. No es necesario crear archivos de políticas adicionales (como en el caso de RBAC, por ejemplo).

Sin embargo, para ciertos controladores de admisión es posible que tenga que especificar detalles de configuración. Por ejemplo, para utilizar el controlador EventRateLimit, que limita el número de solicitudes que puede aceptar el servidor de la API, tendrá que crear un archivo de configuración en formato YAML y remitir a él el servidor de la API utilizando la bandera–admission-control-config-file.

El archivo de configuración será más o menos así:

apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
- type: Namespace
  qps: 50
  burst: 100
  cacheSize: 2000
- type: User
  qps: 10
  burst: 50

En este archivo, qps significa consultas por segundo, y burst define cuántas consultas aceptará el servidor de la API antes de aplicar el límite establecido por qps. De este modo, un qps de 50 con un burst de 100 significa que el servidor aceptará hasta 100 consultas antes de empezar a aplicar el límite de qps de 50. Los límites se definen para tipos específicos de recursos (en el ejemplo anterior, namespaces y usuarios).

Para conocer todos los detalles sobre la configuración de controladores de admisión específicos, consulte la documentación de Kubernetes.

Cómo crear controladores de admisión personalizados con webhooks

Si se configuran correctamente, los diversos controladores de admisión integrados pueden mejorar significativamente muchos aspectos de la seguridad de su clúster.

Sin embargo, como se ha señalado anteriormente, el aspecto más potente de los controladores de admisión es su capacidad para integrarse con herramientas de seguridad externas a través de webhooks.

Por ejemplo, puede utilizar el controlador ImagePolicyWebhook para conectarse a un servidor remoto. Para ello, primero debe asegurarse de que el ImagePolicyWebhook está habilitado en kube-apiserver.yaml.

Después, cree un archivo (lo llamaremos admission-config.yaml) que incluya los detalles de configuración de ImagePolicyWebhook que va a usar para conectarse al servidor remoto. Remita el servidor de la API a este archivo con:

kube-apiserver --admission-control-config-file=admission-config.yaml

El propio archivo admission-config.yaml debe contener una stanza como la siguiente:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
  configuration:
    imagePolicy:
      kubeConfigFile: <path-to-kubeconfig-file>
      allowTTL: 50
      denyTTL: 50
      retryBackoff: 500
      defaultAllow: true

También necesitará un archivo kubeconfig separado para configurar el servidor remoto, por ejemplo:

# clusters refers to the remote service.
clusters:
- name: name-of-remote-imagepolicy-service
  cluster:
    certificate-authority: /path/to/ca.pem    # CA for verifying the remote service.
    server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.
# users refers to the API server's webhook configuration.
users:
- name: name-of-api-server
  user:
    client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
    client-key: /path/to/key.pem          # key matching the cert

Si está configurado correctamente, esto permitirá que el servidor de la API de Kubernetes se conecte a un servicio remoto (es decir, el servidor remoto que definimos anteriormente) al efectuar decisiones de admisión. Una vez más, la ventaja de este enfoque es que puede definir las reglas de admisión externamente, sin tener que incrustar el motor de políticas que quiera utilizar en el propio servidor de la API de Kubernetes (porque, a decir verdad, la configuración del servidor de la API es lo suficientemente complicada en sí misma).

En resumen, los controladores de admisión de Kubernetes son un recurso potente y, al menos para los estándares de Kubernetes, relativamente fácil de usar para añadir otra capa de seguridad a sus clústeres. Los controladores de admisión específicos que decida habilitar pueden variar dependiendo de sus workloads y, tenga o no un motivo para ello, también puede definir controladores personalizados utilizando webhooks.

En todo caso, lo más probable es que quiera habilitar al menos los controladores de admisión predeterminados para todos los clústeres de Kubernetes que vaya a utilizar para cualquier tipo de workload de producción.