Explicación de RBAC de Kubernetes: conceptos clave y ejemplos

Kubernetes no es una plataforma de seguridad. No dispone de herramientas nativas para gestionar la mayoría de las tareas relacionadas con la seguridad, como la detección de vulnerabilidades dentro de las aplicaciones y la monitorización de brechas.

Sin embargo, hay una tarea de seguridad que Kubernetes sí gestiona muy bien de forma nativa: el control de acceso basado en roles (RBAC). Kubernetes lleva integrado un amplio marco RBAC. Hacer uso de él es un primer paso para proteger los clústeres y las aplicaciones que se ejecutan en Kubernetes.

En este artículo repasamos los conceptos básicos de RBAC de Kubernetes, demostramos cómo utilizar las políticas de RBAC de Kubernetes y destacamos las mejores prácticas a seguir y los errores a evitar cuando se trabaja con RBAC en Kubernetes.

Kubernetes RBAC: conceptos básicos

Si está leyendo esto, probablemente ya conozca RBAC como concepto general. En distintos contextos (como los sistemas operativos y las nubes públicas), los sistemas RBAC se pueden utilizar para definir quién puede acceder a qué en función de las identidades de los usuarios.

El RBAC de Kubernetes se basa en estos conceptos, si bien difiere en algunos aspectos clave de muchos de los otros tipos de marcos RBAC:

Cuentas de usuario vs. cuentas de servicios

En Kubernetes, las políticas RBAC pueden utilizarse para definir los derechos de acceso de los usuarios humanos (o grupos de usuarios humanos). Kubernetes identifica a los usuarios humanos como cuentas de usuario.

Sin embargo, las políticas RBAC también pueden regular el comportamiento de los recursos de software, que Kubernetes identifica como cuentas de servicios.

Aunque Kubernetes distingue entre cuentas de usuario y cuentas de servicios a nivel conceptual, esta distinción no importa realmente en lo que respecta a las políticas RBAC. Esto diferencia a RBAC de Kubernetes de muchos otros sistemas RBAC que suelen centrarse en la gestión de los permisos de los usuarios humanos (basados en factores como su rol de trabajo o el tipo de cuenta) en lugar de gestionar el acceso a los servicios de software.

Definiciones de recursos flexibles

El RBAC de Kubernetes también es bastante amplio en cuanto a la forma en que Kubernetes define las entidades que las políticas RBAC pueden regular.

Kubernetes se refiere a estas entidades como “recursos”, y pueden ser prácticamente cualquier cosa: pods, registros, controladores de entrada o cualquier otro tipo de recurso personalizado que usted decida definir.

La mayor parte de los otros sistemas RBAC tienden a ser más restrictivos en cuanto a los tipos de recursos que se pueden gestionar. Por ejemplo, los marcos de IAM en la nube están diseñados para gestionar solo tipos de recursos predefinidos, como instancias de máquinas virtuales o cubos de almacenamiento. (También puede utilizar etiquetas para controlar qué políticas se aplican a qué recursos, pero esto es menos escalable que el enfoque de Kubernetes, porque tendría que crear cada etiqueta manualmente).

Roles vs. ClusterRoles

Una peculiaridad relativamente simple pero importante del RBAC de Kubernetes es que establece una distinción entre los permisos que se aplican a los recursos dentro de un namespace, que se gestionan a través de Roles, y los que se aplican a todo el clúster, que se gestionan a través de ClusterRoles.

En la mayoría de los casos, usted trabajará con Roles, que pueden utilizarse para gestionar los permisos de forma más granular (es decir, dentro de namespaces individuales). Pero es posible que a veces quiera usar ClusterRoles para gestionar reglas para recursos que solo existen a nivel de clúster, como los nodos.

Gestión de permisos mediante “verbos” (“Verbs”)

A diferencia de los sistemas de control de acceso que solo pueden permitir o denegar el acceso, o de los sistemas que dividen los derechos de acceso en categorías amplias como “lectura”, “escritura” y “ejecución”, Kubernetes RBAC proporciona una serie de “verbos” que definen las acciones específicas que las cuentas pueden realizar en los recursos.

Por ejemplo, puede permitir a un usuario “crear” y “listar” un determinado recurso especificando los verbos adecuados con una política RBAC.

Puede obtener una lista de todos los verbos disponibles en su clúster ejecutando:

kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get 
--show-kind --ignore-not-found -l <label>=<value> -n <namespace>

Cómo trabajar con RBAC de Kubernetes: pasos y ejemplos

Ahora que sabemos cuáles son los conceptos básicos de RBAC en Kubernetes, veamos cómo utilizarlo.

Comprobar el soporte de RBAC

En primer lugar, asegúrese de que su clúster soporta RBAC. El RBAC se introdujo con Kubernetes 1.6, y la mayoría de los clústeres lo habilitan por defecto, pero nunca está de más comprobarlo.

Busque un archivo de configuración de RBAC en /etc/kubernetes/manifests en su(s) nodo(s) maestro(s) o en el pod del servidor de la API de Kubernetes y asegúrese de que contiene la bandera:

--authorization-mode=Node,RBAC

Definir cuentas de usuario y de servicios

A continuación, deberá definir las cuentas de usuario y/o de servicios a las que posteriormente se asignarán los permisos. A modo de sencillo ejemplo, estos son los pasos para crear una cuenta de usuario para un usuario al que llamaremos John.

Comience creando una nueva clave privada:

openssl genrsa -out john.key 2048

Hecho esto, debe crear una solicitud de firma de certificado (CSR) que contenga la clave pública y otros

datos del sujeto:

openssl req -new -key john.key -out john.csr -subj "/CN=john/
O=examplegroup"

Tenga en cuenta que Kubernetes utilizará el campo Organización (O=examplegroup) para determinar la

pertenencia a un grupo del usuario para el RBAC.

Deberá firmar esta CSR utilizando la CA raíz (entidad certificadora) de Kubernetes, que se encuentra en /etc/kubernetes/pki para este ejemplo (la ubicación del archivo en su implementación puede variar):

openssl x509 -req -in john.csr -CA /etc/kubernetes/pki/ca.crt
-CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out john.crt
Signature ok
subject=/CN=john/O=examplegroup
Getting CA Private Key

Puede inspeccionar el nuevo certificado:

openssl x509 -in john.crt -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 11309651818125161147 (0x9cf3f46850b372bb)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=kubernetes
Validity
Not Before: Apr 2 20:20:54 2018 GMT
Not After : May 2 20:20:54 2018 GMT
Subject: CN=john, O=examplegroup
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)

Por último, registre las nuevas credenciales y el contexto de configuración:

kubectl config set-credentials john --client-certificate=/home/newusers/john.crt --client-
key=/home/newusers/john.key


kubectl config set-context [email protected] --cluster=kubernetes --user=john

Crear un Role o ClusterRole

El siguiente paso consiste en crear un Role o ClusterRole. Aquí es donde definimos las acciones que se pueden realizar en un recurso.

En el siguiente ejemplo tenemos un rol que otorga permisos para obtener, ver y listar pods.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Crear un RoleBinding o ClusterRoleBinding

Por último, tenemos que “vincular” nuestro Role o ClusterRole al usuario o cuenta que hemos creado. La vinculación es lo que realmente permite que el usuario o la cuenta especificados desempeñen el rol en cuestión.

kubectl create rolebinding podreader-binding --user=john

Mejores prácticas de RBAC de Kubernetes

El RBAC de Kubernetes es una herramienta poderosa. Estas son las mejores prácticas para utilizarla de la manera más responsable posible.

Minimizar las banderas (flags) del servidor de la API

La API de Kubernetes tiene una serie de banderas opcionales que pueden habilitarse para simplificar algunos aspectos de la gestión de Kubernetes. Sin embargo, esto también aumenta los riesgos de seguridad. Evite estas banderas siempre que sea posible:

–insecure-port: Permite el acceso a solicitudes no autorizadas y no autenticadas. Si este

parámetro es igual a 0, significa que el puerto no es inseguro.

–insecure-bind-address: Lo ideal sería que evitara completamente las conexiones inseguras, pero en caso de que realmente las necesite, puede usar este parámetro para vincular solo con localhost. Asegúrese de que este parámetro no esté configurado, o al menos no con una dirección IP accesible a través de la red.
–anonymous-auth: Habilita las peticiones anónimas al puerto seguro del servidor API.

Aplicar el principio de mínimo privilegio

Al igual que con cualquier sistema RBAC, el RBAC de Kubernetes es más efectivo cuando los administradores siguen el principio de mínimo privilegio, es decir, cuando cada usuario o cuenta recibe únicamente los privilegios mínimos necesarios para realizar su trabajo.

En la práctica, esto significa por ejemplo usar Roles en lugar de ClusterRoles siempre que sea posible. Aunque configurar Roles para cada namespace es un poco más engorroso que definir un ClusterRole para todo el clúster, los Roles son más seguros porque se aplican a menos recursos.

Asimismo, evite usar comodines [“*”] cuando defina los verbos o el acceso a los recursos. Los comodines son el “chmod 777” de Kubernetes: son cómodos de aplicar, pero abren todo tipo de brechas de acceso no autorizados.

Evitar las cuentas de servicios predeterminadas

Kubernetes crea cuentas de servicios predeterminadas para identificar los procesos que se ejecutan en un pod.

Es posible que se sienta tentado a utilizar estas cuentas para asignar permisos en lugar de tomarse la molestia de configurar sus propias cuentas. Pero esa no es la mejor práctica. Es preferible que cree cuentas de servicios específicas para cada servicio, ya que proporcionan la base para controles de acceso más granulares.

Por cierto, si se está preguntando qué pasa con los usuarios predeterminados, Kubernetes no tiene cuentas de usuario predeterminadas, así que no tiene que preocuparte por eso. Deberá crear usuarios explícitamente si quiere asignarles Roles o ClusterRoles.

Actualizar las políticas RBAC continuamente

El RBAC de Kubernetes será igual de efectivo que las políticas RBAC que usted cree. Si sus políticas quedan anticuadas, es posible que en poco tiempo se encuentre con usuarios o cuentas de servicios con demasiados permisos.

Por eso, una práctica recomendada es asegurarse de que cada vez que cree, elimine o actualice los permisos de cualquier cuenta de usuario o de servicios, o cuando cree namespaces o pods, también modifique o elimine todas las políticas RBAC asociadas a esa entidad. Esto puede resultar algo tedioso, ya que Kubernetes tiene múltiples tipos de archivos asociados a RBAC (Roles, RoleBindings, ClusterRoles y ClusterRoleBindings). Aun así, es importante que las actualizaciones de las políticas RBAC sean una parte sistemática y continua de la gestión de Kubernetes.

Cómo aprovechar al máximo RBAC de Kubernetes

Es imposible ejecutar un clúster Kubernetes seguro de cualquier tamaño sin utilizar RBAC. Aunque puede prescindir de las políticas de RBAC si ejecuta un clúster de un solo nodo en el ordenador portátil a modo de prueba, para un clúster con múltiples usuarios, pods, namespaces y similares necesitará políticas RBAC que definan quién y qué puede hacer dentro del clúster.

Por lo tanto, aunque el enfoque de Kubernetes con respecto a RBAC puede parecer algo extraño en ciertos aspectos, y no siempre es el sistema más sencillo de RBAC para trabajar, invertir tiempo en aprender cómo funciona RBAC en Kubernetes y cómo usarlo eficazmente es una práctica básica recomendada para proteger cualquier entorno de producción de Kubernetes.