Quién puede hacer qué, y cómo. El módulo que más confunde por su vocabulario, pero que se vuelve simple con un solo modelo mental: QUIÉN + QUÉ, conectados por un BINDING.
# Imperativo: role que puede ver pods en el ns actual
k create role pod-reader \
--verb=get,list,watch \
--resource=pods
# Con $do para ver el YAML
k create role pod-reader \
--verb=get,list,watch --resource=pods $doEl YAML resultante:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]# Mismo formato, pero sin namespace (es cluster-wide)
k create clusterrole node-reader \
--verb=get,list,watch \
--resource=nodes $doapiGroups: [""] (string vacío) es el "core group" — pods, services, configmaps, etc. Para otros recursos cambia: apps (deployments), rbac.authorization.k8s.io (roles), etc. Si no sabés el group, k api-resources te lo dice.| Role | ClusterRole | |
|---|---|---|
| Alcance | 1 namespace | Todo el cluster |
| Tiene namespace | Sí | No |
| Para recursos | Namespaced (pods, etc.) | Namespaced O cluster-scoped (nodes, PVs) |
get, list, watch (lectura) · create, update, patch (escritura) · delete, deletecollection (borrado)
# Darle el role 'pod-reader' al usuario 'juan'
k create rolebinding juan-pods \
--role=pod-reader \
--user=juan $do
# A un ServiceAccount en vez de user:
k create rolebinding sa-pods \
--role=pod-reader \
--serviceaccount=default:miapp $dok create clusterrolebinding juan-nodes \
--clusterrole=node-reader \
--user=juan $do# Definís el permiso UNA vez como ClusterRole,
# y lo aplicás en namespaces específicos con RoleBinding
k create rolebinding juan-en-dev \
--clusterrole=pod-reader \
--user=juan \
--namespace=dev $do| Binding | Referencia a | ¿Válido? |
|---|---|---|
| RoleBinding | Role | SÍ |
| RoleBinding | ClusterRole | SÍ |
| ClusterRoleBinding | ClusterRole | SÍ |
| ClusterRoleBinding | Role | NO |
Un RoleBinding puede apuntar a un Role O a un ClusterRole (en ambos casos, los permisos aplican solo en SU namespace).
Un ClusterRoleBinding solo puede apuntar a un ClusterRole (nunca a un Role).
Un Role está atado a un namespace. Un ClusterRoleBinding es cluster-wide. No tiene sentido lógico otorgar cluster-wide algo que solo existe en un namespace. Por eso K8s no lo permite.
# Crear un SA
k create serviceaccount miapp
# Ver los SA del namespace
k get serviceaccounts
# Siempre existe uno llamado 'default'# En el YAML del pod:
spec:
serviceAccountName: miapp
containers:
- name: app
image: nginxk set serviceaccount deployment/web miapp# El SA es el SUBJECT del binding
k create rolebinding miapp-pods \
--role=pod-reader \
--serviceaccount=default:miapp $dodefault del namespace, que normalmente NO tiene permisos. Si tu app necesita hablar con el API server, creale un SA con los permisos justos.| User | ServiceAccount | |
|---|---|---|
| Para | Humanos | Pods / procesos |
| Lo gestiona K8s | No (externo) | Sí (objeto del cluster) |
| Tiene namespace | No | Sí |
| Se crea con kubectl | No | Sí |
Kubernetes no tiene objetos User. Los usuarios vienen de afuera (certificados, OIDC, etc.). Pero los ServiceAccounts SÍ son objetos que creás y gestionás con kubectl.
Formato: namespace:nombre. Por eso --serviceaccount=default:miapp significa "el SA llamado miapp en el namespace default".
/var/run/secrets/kubernetes.io/serviceaccount/). El pod lo usa para autenticarse contra el API server.# ¿Puedo crear deployments?
k auth can-i create deployments
# ¿Puedo borrar pods en el ns kube-system?
k auth can-i delete pods -n kube-system
# Respuesta: yes / no# ¿El usuario juan puede listar pods?
k auth can-i list pods --as juan
# ¿El SA miapp puede crear services?
k auth can-i create services \
--as=system:serviceaccount:default:miappk auth can-i --list --as juan--as (impersonation) es clave en el examen: te piden "verificá que el usuario X puede/no puede hacer Y". En vez de loguearte como X, impersonás con --as. Para un SA el formato es system:serviceaccount:NS:NOMBRE.Cuando algo "no tiene permisos" (como tu Forbidden del Módulo 1), el camino es:
auth can-i para confirmar qué faltaUn ServiceAccount como subject en impersonation o en bindings se escribe completo: system:serviceaccount:<ns>:<nombre>
auth can-i --list es oro para diagnosticar: te muestra el mapa completo de permisos de un subject, sin adivinar.# Ver el context actual
k config current-context
# Listar todos los contexts
k config get-contexts
# Cambiar de context
k config use-context <nombre>
# Ver el kubeconfig completo
k config viewk config set-context --current --namespace=dev
# Ahora todos los comandos van al ns 'dev' sin -nk config use-context es de los comandos que más vas a tipear. Y el --namespace en el context te ahorra poner -n en cada comando.| Sección | Qué define |
|---|---|
| clusters | A qué API server (URL + CA) |
| users | Quién sos (cert/token/credenciales) |
| contexts | Combina cluster + user + namespace |
Un context dice: "usá ESTE user para hablar con ESTE cluster en ESTE namespace". Cambiar de context = cambiar de identidad y/o destino de un saque.
Por defecto en ~/.kube/config (el que copiaste con admin.conf en el Módulo 1). La variable KUBECONFIG puede apuntar a otro.
admin.conf que copiaste a ~/.kube/config ES un kubeconfig. Tiene el cluster (tu API server), el user (admin con su cert), y un context que los une. Por eso al copiarlo, kubectl supo quién sos y a dónde conectarte.# Crear permisos (el QUÉ)
k create role NAME --verb=get,list --resource=pods $do
k create clusterrole NAME --verb=... --resource=nodes $do
# Conectar (el pegamento)
k create rolebinding NAME --role=R --user=U $do
k create clusterrolebinding NAME --clusterrole=CR --user=U $do
# ServiceAccount (identidad de pods)
k create serviceaccount NAME
k create rolebinding NAME --role=R \
--serviceaccount=NS:SA $do
# Verificar permisos
k auth can-i VERB RESOURCE --as USER
k auth can-i --list --as USER
# Contexts
k config use-context NAME
k config set-context --current --namespace=NS