Hardening Kubernetes: Permisos (RBAC)
Como ya hemos comentado la gestión de identidades y usuarios no está integrada en la plataforma y debe ser administrada por plataformas externas (Directorio Activo, Keycloak…). Sin embargo, lo que sí hace Kubernetes es manejar la autenticación y la autorización.
Cuando hablamos de dar permisos en un clúster de Kubernetes, tendremos que hablar del control de acceso basado en Roles. O lo que se denomina Role Based Access Control o RBAC, el cual maneja políticas de seguridad para usuarios, grupos o Pods, y que está implementado de una forma estable desde la versión 1.8 de Kubernetes.
Existen otras formas de autorizar usuarios como ABAC (Attribute-based access control), mediante Webhook o Node Authorization, pero explicaremos RBAC que es la más popular.
Ya hemos hablado de los usuarios en el punto anterior. En el caso de los Pods, para que un Pod pueda acceder a la API de Kubernetes necesitamos darle permisos específicos para ello. De hecho, los Roles se definen a nivel del espacio de nombres o Namespace.
Roles, Cluster Roles, Role/Cluster Bindings y Service Accounts
Vamos a definir brevemente en qué consisten los tipos de permisos que somos capaces de dar mediante RBAC.
- Roles: sirven para declarar servicios que afectan a Namespaces. Es decir, si necesitas darle permisos a un usuario, para acceder a un Namespace necesitas generar un role.
- Recursos: son Pods, NameSpace, Servicios, Deployments…
- Verbos: acciones que puedo lanzar a esos recursos (Get, List…)
- Cluster Role: si lo que buscamos es dar permisos a todo el Cluster y todos los Namespaces generaremos un Cluster Role.
- Role/Cluster Binding: define qué usuarios tienen qué roles. Sirve para asignar los usuarios a un Role o Cluster Role y poder asignar los permisos.
- Role: definición de los permisos para cada tipo de recurso de Kubernetes
- Subject: son los propios usuarios o grupos de usuarios
- Service Account: usuario que se crea para asignar los permisos
- Service Accounts: para dar permisos a Pods, necesitamos generar Service Accounts o cuentas de servicio
Como apunte, los permisos sólo permiten acceso a recursos, porque “por defecto se deniega todo” y es posible asignar varios roles al mismo usuario
El único pre-requisito para usar RBAC que esté habilitado en nuestro clúster mediante la opción “–authorization-mode=RBAC”. Eso lo podemos comprobar mediante el comando:
1 |
kubectl api-versions |
Si está habilitado tendremos un valor tipo:
1 |
.rbac.authorization.k8s.io/v1 |
Para implementar un Role en un Namespace concreto lo definiríamos:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: ebdn-namespace name: example-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] |
Y luego generaríamos el RoleBinding a partir de él en el mismo Namespace. Le asignamos al usuario “elblogdenegu” el role de ejemplo “example-role”, generando un Role binding “example-rolebinding”:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: example-rolebinding namespace: ebdn-namespace subjects: - kind: User name: elblogdenegu apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: example-role apiGroup: rbac.authorization.k8s.io |
Si lo que queremos es generar permisos sin depender de Namespace (para dárselos, por ejemplo, a un nodo) definiríamos ClusterRole:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: example-clusterrole rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] |
Y definiríamos un ClusterRoleBinding de la siguiente forma:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: example-clusterrolebinding subjects: - kind: User name: elblogdenegu apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: example-clusterrole apiGroup: rbac.authorization.k8s.io |
Por último, explicamos cómo dar todos los permisos a un grupo de usuarios o a cuentas de servicio. Al definir el RoleBinding en el apartado subjects le definiríamos el grupo de la siguiente forma:
1 2 3 4 5 6 7 |
subjects: - kind: Group (cambiaríamos esto por ServiceAccount si queremos hacerlo con una cuenta de servicio) name: "administradores" apiGroup: rbac.authorization.k8s.io |
Si le añadimos el Namespace, sólo le daremos totales sobre el Namespace, lo hago con una cuenta de servicio:
1 2 3 4 5 6 7 |
subjects: - kind: Group name: system:serviceaccounts:ebdn-namespace apiGroup: rbac.authorization.k8s.io |
Si os preguntáis como saber qué permisos existen, los podéis revisar en la API REFERENCE:
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/
¿Te ha gustado la entrada SÍGUENOS EN TWITTER?
Te ha gustado la entrada SGUENOS EN TWITTER O INVITANOS A UN CAFE?