El Control de Acceso Basado en Roles (RBAC) es un mecanismo de seguridad en Kubernetes que permite gestionar el acceso a los recursos del clúster de manera granular. Con RBAC, puedes definir quién puede hacer qué dentro del clúster, asignando permisos específicos a usuarios, grupos o cuentas de servicio.

Antes de profundizar en RBAC, es importante entender algunos conceptos clave:

• Roles: Definen un conjunto de permisos. Los roles pueden ser específicos de un namespace (Role) o globales en el clúster (ClusterRole).
• RoleBindings: Asocian un Role con un usuario, grupo o cuenta de servicio dentro de un namespace.
• ClusterRoleBindings: Asocian un ClusterRole con un usuario, grupo o cuenta de servicio a nivel de clúster.

Un Role en Kubernetes se define mediante un archivo YAML. Aquí hay un ejemplo de un Role que permite listar y obtener pods en un namespace específico:

• apiVersion: La versión de la API de RBAC.
• kind: El tipo de recurso, en este caso, Role.
• metadata: Información sobre el Role, incluyendo el namespace y el nombre.
• rules: Una lista de reglas que definen los permisos. Cada regla incluye:
  • apiGroups: Los grupos de API a los que se aplican los permisos.
  • resources: Los recursos a los que se aplican los permisos.
  • verbs: Las acciones permitidas (por ejemplo, get, list, create, delete).

Un RoleBinding asocia un Role con un usuario, grupo o cuenta de servicio. Aquí hay un ejemplo de un RoleBinding que asocia el Role pod-reader con un usuario llamado jane:

• apiVersion: La versión de la API de RBAC.
• kind: El tipo de recurso, en este caso, RoleBinding.
• metadata: Información sobre el RoleBinding, incluyendo el nombre y el namespace.
• subjects: Una lista de sujetos (usuarios, grupos o cuentas de servicio) a los que se aplica el RoleBinding.
  • kind: El tipo de sujeto (por ejemplo, User, Group, ServiceAccount).
  • name: El nombre del sujeto.
  • apiGroup: El grupo de API del sujeto.
• roleRef: Referencia al Role que se está asociando.
  • kind: El tipo de Role (por ejemplo, Role o ClusterRole).
  • name: El nombre del Role.
  • apiGroup: El grupo de API del Role.

Un ClusterRole es similar a un Role, pero se aplica a nivel de clúster. Aquí hay un ejemplo de un ClusterRole que permite listar y obtener pods en todo el clúster:

Un ClusterRoleBinding asocia un ClusterRole con un usuario, grupo o cuenta de servicio a nivel de clúster. Aquí hay un ejemplo de un ClusterRoleBinding que asocia el ClusterRole cluster-pod-reader con un usuario llamado jane:

1. Crear un Role: Define un Role que permita listar y obtener servicios (services) en el namespace default.

2. Crear un RoleBinding: Asocia el Role service-reader con un usuario llamado john.

1. Role:

2. RoleBinding:

• Error: No especificar correctamente el apiGroup en roleRef.

  • Solución: Asegúrate de que apiGroup en roleRef coincida con el grupo de API del Role o ClusterRole.

• Error: Intentar usar un RoleBinding para un ClusterRole.

  • Solución: Usa ClusterRoleBinding para asociar un ClusterRole.

• Consejo: Utiliza nombres descriptivos para tus Roles y RoleBindings para facilitar la gestión y el mantenimiento.

El Control de Acceso Basado en Roles (RBAC) es una herramienta poderosa para gestionar la seguridad en Kubernetes. Permite definir permisos específicos para usuarios, grupos y cuentas de servicio, asegurando que solo tengan acceso a los recursos necesarios. En esta sección, hemos cubierto los conceptos básicos de RBAC, incluyendo Roles, RoleBindings, ClusterRoles y ClusterRoleBindings, y hemos proporcionado ejemplos prácticos para ayudarte a implementar RBAC en tu clúster de Kubernetes.

En el próximo tema, exploraremos las Políticas de Seguridad de Pods (Pod Security Policies) y cómo pueden ayudarte a asegurar aún más tu clúster de Kubernetes.