Kubernetes Role-Based Access Control(RBAC)

¡Apoya a HackTricks y obtén beneficios!

• Si quieres ver a tu empresa anunciada en HackTricks o si quieres acceder a la última versión de PEASS o descargar HackTricks en PDF, ¡consulta los PLANES DE SUSCRIPCIÓN!

• Obtén el swag oficial de PEASS y HackTricks

• Descubre The PEASS Family, nuestra colección de exclusivos NFTs

• Únete al 💬 grupo de Discord o al grupo de Telegram o sígueme en Twitter 🐦 @carlospolopm.

• Comparte tus trucos de hacking enviando PR a los repositorios de GitHub de HackTricks y HackTricks Cloud.

Control de acceso basado en roles (RBAC)

Kubernetes tiene un módulo de autorización llamado Control de acceso basado en roles (RBAC) que ayuda a establecer permisos de utilización para el servidor API.

El modelo de permisos de RBAC se construye a partir de tres partes individuales:

1. Rol/ClusterRole ­– El permiso real. Contiene reglas que representan un conjunto de permisos. Cada regla contiene recursos y verbos. El verbo es la acción que se aplicará en el recurso.

2. Sujeto (Usuario, Grupo o ServiceAccount) – El objeto que recibirá los permisos.

3. RoleBinding/ClusterRoleBinding – La conexión entre Rol/ClusterRole y el sujeto.

La diferencia entre "Roles" y "ClusterRoles" es solo donde se aplicará el rol: un "Rol" otorgará acceso a solo un namespace específico, mientras que un "ClusterRole" se puede usar en todos los namespaces del clúster. Además, ClusterRoles también pueden otorgar acceso a:

• recursos de ámbito de clúster (como nodos).

• puntos finales de no recurso (como /healthz).

• recursos de ámbito de namespace (como Pods), en todos los namespaces.

A partir de Kubernetes 1.6, las políticas de RBAC están habilitadas de forma predeterminada. Pero para habilitar RBAC, puede usar algo como:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

Plantillas

En la plantilla de un Rol o un ClusterRole, deberá indicar el nombre del rol, el namespace (en roles) y luego los apiGroups, recursos y verbos del rol:

• Los apiGroups son una matriz que contiene los diferentes espacios de nombres de API a los que se aplica esta regla. Por ejemplo, una definición de Pod usa apiVersion: v1. Puede tener valores como rbac.authorization.k8s.io o [*].

• Los recursos son una matriz que define a qué recursos se aplica esta regla. Puede encontrar todos los recursos con: kubectl api-resources --namespaced=true

• Los verbos son una matriz que contiene los verbos permitidos. El verbo en Kubernetes define el tipo de acción que debe aplicar al recurso. Por ejemplo, el verbo de lista se utiliza contra colecciones mientras que "get" se utiliza contra un solo recurso.

Verbos de reglas

(Esta información fue tomada de aquí)

Verbo HTTP	Verbo de solicitud
POST	create
GET, HEAD	get (para recursos individuales), list (para colecciones, incluido el contenido completo del objeto), watch (para ver un recurso individual o una colección de recursos)
PUT	update
PATCH	patch
DELETE	delete (para recursos individuales), deletecollection (para colecciones)

Kubernetes a veces verifica la autorización para permisos adicionales utilizando verbos especializados. Por ejemplo:

• Política de seguridad de Pod

  • verbo use en recursos podsecuritypolicies en el grupo de API policy.

• RBAC

  • verbos bind y escalate en recursos roles y clusterroles en el grupo de API rbac.authorization.k8s.io.

• Autenticación

  • verbo impersonate en users, groups y serviceaccounts en el grupo API principal, y userextras en el grupo de API authentication.k8s.io.

Puede encontrar todos los verbos que admite cada recurso ejecutando kubectl api-resources --sort-by name -o wide

Ejemplos

Rol

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: defaultGreen
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

ClusterRole

```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: # "namespace" omitted since ClusterRoles are not namespaced name: secret-reader rules