Aplicar el principio de mínimo privilegio a Kubernetes con RBAC

Cuando se configura correctamente, los usuarios no autorizados no pueden acceder a funciones restringidas de la aplicación ni cambiar de rol. Tampoco pueden acceder a ciertos datos, como archivos y secretos de API, excepto cuando es necesario para completar una función asignada. Esto ayuda a proteger contra las consecuencias intencionales y no intencionales de las acciones no autorizadas.

En las instalaciones físicas, solo los empleados autorizados para trabajar en ellas pueden acceder a ciertas áreas, como las salas de servidores. Algunas ubicaciones críticas de estas instalaciones solo están disponibles para integrantes con experiencia o de mayor rango en los departamentos correspondientes.

El mismo criterio se aplica al PoLP. Por ejemplo, en un software de gestión de empleados, es probable que solo el personal de Recursos Humanos pueda acceder a los registros del personal. Del mismo modo, se pueden configurar ciertas acciones —como implementar versiones de aplicaciones en producción— para que solo las puedan ejecutar ingenieros sénior.

El PoLP también está presente en las aplicaciones de software como servicio (SaaS), donde los usuarios tienen distintos roles dentro de una aplicación según las tareas específicas que realizan.

Proteger los sistemas de software requiere encontrar un equilibrio entre evitar que el sistema sea demasiado restrictivo para las partes interesadas y evitar que sea demasiado vulnerable a los actores de amenazas. El PoLP nos ayuda a lograr este equilibrio: mantiene el sistema seguro y minimiza las dificultades relacionadas con el acceso.

Además, el PoLP ayuda a mantener un rendimiento operativo eficiente y confiable. Los sistemas son menos vulnerables al tiempo de inactividad causado por ataques de malware o por actividades riesgosas de los usuarios, como enviar código inseguro a producción o cambiar contraseñas de administrador.

En este artículo, exploraremos cómo Kubernetes (K8s) aplica el PoLP mediante el control de acceso basado en roles.

Aplicar el principio de mínimo privilegio al acceso a Kubernetes

Kubernetes gestiona cargas de trabajo de orquestación de contenedores. Ofrece una plataforma para que las organizaciones y los desarrolladores automaticen la implementación, la administración y el escalado de aplicaciones en contenedores. Esto significa que varios integrantes de los equipos de desarrollo, operaciones y TI necesitan acceder a un entorno de Kubernetes para crear o mantener las aplicaciones implementadas.

Para garantizar una seguridad óptima y proteger los recursos, las organizaciones deben aplicar el PoLP al usar Kubernetes, sin importar la etapa actual de producción. Por fortuna, Kubernetes incluye funciones de autenticación y autorización que permiten controlar el acceso. Los equipos deben definir explícitamente quién puede acceder a qué recursos operativos y con qué permisos al interactuar con la API de Kubernetes. Además, las organizaciones deben deshabilitar el acceso no autenticado, ya sea de cuentas humanas o de servicio.

Cómo Kubernetes administra el acceso con RBAC

El control de acceso basado en roles (RBAC) es un método que se usa en muchos sistemas para definir permisos sobre los recursos según los roles de las personas en el entorno. Kubernetes cuenta con un mecanismo RBAC nativo integral, que permite configurar permisos para especificar cómo puede interactuar un usuario o grupo de usuarios con cualquier objeto de Kubernetes en un clúster. Usar este marco de RBAC es el primer paso para proteger un clúster y sus aplicaciones en contenedores.

Los objetos de Kubernetes son entidades persistentes que especifican qué aplicaciones en contenedores están en ejecución, cuáles son sus recursos y qué políticas rigen su funcionamiento. En esencia, definen el estado deseado del clúster. Podemos crear, cambiar o eliminar objetos mediante la API de Kubernetes.

En Kubernetes, hay dos tipos de cuentas: las de usuario y las de servicio. Las cuentas de usuario corresponden a usuarios humanos activos, mientras que las cuentas de servicio corresponden a los procesos que acceden a la API de Kubernetes. El RBAC de Kubernetes rige el acceso de estas cuentas a los recursos, incluidos los pods, los secretos, los controladores y las definiciones de recursos personalizados (CRD).

Los permisos en Kubernetes se definen con objetos Role o ClusterRole. Luego, los permisos definidos se asignan como reglas mediante los objetos RoleBinding y ClusterRoleBinding. La API de RBAC define los siguientes cuatro tipos de objetos de Kubernetes:

• Role: administra los permisos aplicables a los recursos de un espacio de nombres individual

• ClusterRole: administra los permisos aplicables a todo un clúster

• RoleBinding: asigna un Role a una cuenta o grupo dentro de un espacio de nombres específico

• ClusterRoleBinding: asigna un ClusterRole a una cuenta o grupo en todos los espacios de nombres del clúster

En las próximas dos secciones, exploraremos cómo las políticas de RBAC se ajustan al PoLP para limitar el acceso a los recursos de los clústeres.

Definir permisos

Para establecer correctamente los permisos, debes configurar Kubernetes de modo que refleje el rol de cada integrante del equipo, teniendo en cuenta las prácticas del PoLP. Usar Roles y ClusterRoles es una forma muy eficiente de hacerlo. Los Roles se aplican a los recursos de un solo espacio de nombres, mientras que los ClusterRoles se aplican a los recursos de todo el clúster.

En esta sección, exploraremos cómo restringir el acceso a ciertas partes de un sistema con Role y ClusterRole.

Supongamos que una empresa tiene un nuevo ingeniero sénior de DevOps que debe poder ver todas las variables de entorno y otros secretos, mientras que los demás integrantes de su equipo no. Además, como integrante del equipo de operaciones, este ingeniero también podría necesitar ver los pods creados para las cargas de trabajo de las aplicaciones de la empresa, a fin de monitorear el estado de los contenedores que alojan las aplicaciones del lado del cliente.

Para lograrlo, comienza por definir los objetos Role y ClusterRole en tu archivo YAML. A continuación, se muestra un ejemplo de cómo definir un Role para permitir el acceso de lectura a los secretos en el espacio de nombres de desarrollo:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  namespace: development
5  name: secret-reader
6rules:
7- apiGroups: [""]
8  resources: ["secrets"]
9  verbs: ["get", "watch", "list"]

El código anterior especifica la versión de la API. RBAC usa el grupo de API rbac.authorization.k8s.io para configurar políticas de autorización mediante la API de Kubernetes. Luego especifica el tipo de definición como Role y menciona el espacio de nombres al que se aplicará: development. Se supone que development es el grupo de espacio de nombres de los recursos que usa el equipo de desarrollo. A continuación, se asigna al Role el nombre secretpod-reader.

La sección rules contiene los recursos a los que se aplica la regla y las acciones que el Role puede realizar en ellos. Esta sección también incluye algunos verbos de reglas. Kubernetes usa verbos como write, watch, read y delete para administrar permisos en categorías generales.

A continuación, se muestra cómo definir un ClusterRole para permitir el acceso de lectura a los pods del front-end en el clúster:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: pod-reader
5rules:
6- apiGroups: [""]
7  resources: ["pods"]
8  verbs: ["get", "watch", "list"

Observa que el código anterior no especifica el espacio de nombres en los metadatos. Esto se debe a que los ClusterRoles no están asociados a un espacio de nombres. Por lo tanto, en la sección de metadatos solo especificaste el nombre del ClusterRole: pod-reader.

A continuación, puedes vincular el Role al grupo de recursos asociado al espacio de nombres de desarrollo y vincular el ClusterRole al clúster. Ahora, tu equipo —y nadie más— puede ver los secretos necesarios en los recursos de desarrollo. Aplicar el PoLP de esta manera permite que tu equipo acceda a lo que necesita para realizar tareas de desarrollo, pero impide que otras personas de la organización accedan a estos pods y recursos.

Ya creaste un Role para permitir que el ingeniero de DevOps acceda a los secretos y un ClusterRole para que todo el equipo de DevOps pueda leer los pods. En la próxima sección, asignarás los permisos al Role y al ClusterRole.

Asignar permisos

La vinculación de roles es útil, por ejemplo, cuando un empleado específico necesita acceder a las claves secretas que se usan en la configuración de una aplicación. Estas pueden ser pares de claves de API o variables de entorno.

Además, debemos usar la vinculación de clúster para otorgar permisos en todo un clúster. La vinculación de clúster puede permitir que cualquier usuario del rol de clúster especificado lea los pods en cualquier espacio de nombres del clúster.

Si el ingeniero de DevOps es un usuario llamado Sola, puedes asignar el Role creado anteriormente a un usuario llamado sola en el espacio de nombres de desarrollo. Así, sola podrá leer los secretos de ese espacio de nombres.

Ten en cuenta que el nombre sola distingue entre mayúsculas y minúsculas. La definición de RoleBinding es la siguiente:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: RoleBinding
3metadata:
4  name: secret-reader
5  namespace: development
6subjects:
7- kind: User
8  name: sola
9  apiGroup: rbac.authorization.k8s.io
10roleRef:
11  kind: Role
12  name: secret-reader 
13  apiGroup: rbac.authorization.k8s.io

En el código anterior:

• Especificaste el tipo RoleBinding.

• Especificaste un Role llamado secret-reader y el espacio de nombres development al que se aplica el RoleBinding.

• Especificaste sola como User en la sección subjects. También puedes especificar varios sujetos.

• Vinculaste el Role correspondiente en la sección roleRef. Ten en cuenta que, una vez creada una vinculación, no se puede cambiar el Role o ClusterRole asociado en la sección roleRef.

El ejemplo anterior de RoleBinding sirve para casos en los que un integrante específico del equipo de desarrollo necesita acceder a las claves secretas usadas en la configuración de una aplicación, como pares de claves de API y variables de entorno.

A partir de aquí, debes usar ClusterBinding para otorgar permisos en todo un clúster. En el siguiente ejemplo, verás cómo ClusterBinding permite que cualquier usuario del grupo ops lea los pods en cualquier espacio de nombres del clúster. Ten en cuenta que el nombre ops distingue entre mayúsculas y minúsculas:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: read-pods-global
5subjects:
6- kind: Group
7  name: ops
8  apiGroup: rbac.authorization.k8s.io
9roleRef:
10  kind: ClusterRole
11  name: pod-reader
12  apiGroup: rbac.authorization.k8s.io

La vinculación de clúster es útil en situaciones como la del ejemplo anterior, en las que necesitamos otorgar a todos los integrantes del equipo permiso para acceder a todos los pods del clúster. Si cada permiso específico está configurado correctamente, los usuarios del grupo pueden ver los pods y evaluar su estado, lo que les permite completar los informes requeridos y sus responsabilidades de monitoreo. Al mismo tiempo, las definiciones de ClusterRole garantizan que los usuarios no puedan modificar los pods ni las aplicaciones que contienen.

Proteger tus configuraciones de K8

El acceso basado en roles puede contribuir considerablemente a aplicar el principio de mínimo privilegio. Por fortuna, el marco nativo de RBAC de Kubernetes ofrece muchas funciones en este ámbito. La posibilidad de crear y vincular roles es muy eficaz para garantizar que solo la cantidad mínima de usuarios tenga el acceso necesario a los recursos requeridos. Esto limita la exposición a posibles actores maliciosos sin obstaculizar las funciones de ningún integrante del equipo. Para ver un ejemplo del uso de RBAC en Kubernetes, descubre cómo lo usamos en Snyk.

Para obtener más información sobre cómo aplicar el PoLP correctamente y de forma segura en tu entorno de Kubernetes, visita Snyk y consulta otras publicaciones del blog de Snyk.

Recursos de Kubernetes:

• Seguridad de Kubernetes

• Imágenes de Docker en Kubernetes

• Guía de monitoreo de Kubernetes

• Configuración securityContext de Kubernetes

• Operadores de Kubernetes