CKA · Módulo 2 · RBAC y Seguridad

RBAC e sicurezza del cluster

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.

Who can do what, and how. The module whose vocabulary confuses most, yet which becomes simple with a single mental model: WHO + WHAT, connected by a BINDING.

Chi può fare cosa, e come. Il modulo che confonde di più per il suo vocabolario, ma che diventa semplice con un solo modello mentale: CHI + COSA, connessi da un BINDING.

Duración60 min

Duration60 min

Durata60 min

PrerequisitoMódulo 1 (API server)

PrerequisiteModule 1 (API server)

PrerequisitoModulo 1 (API server)

DificultadMedia-alta

DifficultyMedium-high

DifficoltàMedio-alta

Cae en examenSeguido

Exam frequencyOften

Frequenza d'esameSpesso

# Imperativo: role que puede ver pods en el ns actual# Imperative: a role that can view pods in the current ns# Imperativo: un role che può vedere i pod nel ns corrente k create role pod-reader \ --verb=get,list,watch \ --resource=pods # Con $do para ver el YAML# With $do to see the YAML# Con $do per vedere lo YAML k create role pod-reader \ --verb=get,list,watch --resource=pods $do

# Mismo formato, pero sin namespace (es cluster-wide)# Same shape, but no namespace (it is cluster-wide)# Stessa forma, ma senza namespace (è cluster-wide) k create clusterrole node-reader \ --verb=get,list,watch \ --resource=nodes $do

	Role	ClusterRole
Alcance	1 namespace	Todo el cluster
Scope	1 namespace	Whole cluster
Ambito	1 namespace	Tutto il cluster
Tiene namespace	Sí	No
Has a namespace	Yes	No
Ha un namespace	Sì	No
Para recursos	Namespaced (pods, etc.)	Namespaced O cluster-scoped (nodes, PVs)
For resources	Namespaced (pods, etc.)	Namespaced OR cluster-scoped (nodes, PVs)
Per risorse	Namespaced (pod, ecc.)	Namespaced O cluster-scoped (node, PV)

Role

ClusterRole

Role

ClusterRole

Role

ClusterRole

Alcance

1 namespace

Todo el cluster

Scope

1 namespace

Whole cluster

Ambito

1 namespace

Tutto il cluster

Tiene namespace

Sí

Has a namespace

Yes

Ha un namespace

Sì

Para recursos

Namespaced (pods, etc.)

Namespaced O cluster-scoped (nodes, PVs)

For resources

Namespaced (pods, etc.)

Namespaced OR cluster-scoped (nodes, PVs)

Per risorse

Namespaced (pod, ecc.)

Namespaced O cluster-scoped (node, PV)

# Darle el role 'pod-reader' al usuario 'juan'# Give the 'pod-reader' role to user 'juan'# Dare il role 'pod-reader' all'utente 'juan' k create rolebinding juan-pods \ --role=pod-reader \ --user=juan $do # A un ServiceAccount en vez de user:# To a ServiceAccount instead of a user:# A un ServiceAccount invece che a un utente: k create rolebinding sa-pods \ --role=pod-reader \ --serviceaccount=default:miapp $do

# Definís el permiso UNA vez como ClusterRole,# You define the permission ONCE as a ClusterRole,# Definisci il permesso UNA volta come ClusterRole, # y lo aplicás en namespaces específicos con RoleBinding# and apply it in specific namespaces with a RoleBinding# e lo applichi in namespace specifici con un RoleBinding k create rolebinding juan-en-dev \ --clusterrole=pod-reader \ --user=juan \ --namespace=dev $do

Binding	Referencia a	¿Válido?
RoleBinding	Role	SÍ
RoleBinding	Role	YES
RoleBinding	Role	SÌ
RoleBinding	ClusterRole	SÍ
RoleBinding	ClusterRole	YES
RoleBinding	ClusterRole	SÌ
ClusterRoleBinding	ClusterRole	SÍ
ClusterRoleBinding	ClusterRole	YES
ClusterRoleBinding	ClusterRole	SÌ
ClusterRoleBinding	Role	NO
ClusterRoleBinding	Role	NO
ClusterRoleBinding	Role	NO

Binding

Referencia a

¿Válido?

Binding

References

Valid?

Binding

Referenzia

Valido?

RoleBinding

Role

SÍ

RoleBinding

Role

YES

RoleBinding

Role

SÌ

RoleBinding

ClusterRole

SÍ

RoleBinding

ClusterRole

YES

RoleBinding

ClusterRole

SÌ

ClusterRoleBinding

ClusterRole

SÍ

ClusterRoleBinding

ClusterRole

YES

ClusterRoleBinding

ClusterRole

SÌ

ClusterRoleBinding

Role

ClusterRoleBinding

Role

ClusterRoleBinding

Role

k create clusterrole node-reader \ --verb=get,list,watch --resource=nodes # sin -n# no -n# senza -n k create clusterrolebinding juan-nodes \ --clusterrole=node-reader --user=juan # sin -n# no -n# senza -n

# Crear un SA# Create an SA# Creare un SA k create serviceaccount miapp # Ver los SA del namespace# List the namespace's SAs# Elencare gli SA del namespace k get serviceaccounts # Siempre existe uno llamado 'default'# There is always one called 'default'# Ne esiste sempre uno chiamato 'default'

	User	ServiceAccount
Para	Humanos	Pods / procesos
For	Humans	Pods / processes
Per	Umani	Pod / processi
Lo gestiona K8s	No (externo)	Sí (objeto del cluster)
Managed by K8s	No (external)	Yes (a cluster object)
Gestito da K8s	No (esterno)	Sì (oggetto del cluster)
Tiene namespace	No	Sí
Has a namespace	No	Yes
Ha un namespace	No	Sì
Se crea con kubectl	No	Sí
Created with kubectl	No	Yes
Si crea con kubectl	No	Sì

User

ServiceAccount

User

ServiceAccount

User

ServiceAccount

Para

Humanos

Pods / procesos

For

Humans

Pods / processes

Per

Umani

Pod / processi

Lo gestiona K8s

No (externo)

Sí (objeto del cluster)

Managed by K8s

No (external)

Yes (a cluster object)

Gestito da K8s

No (esterno)

Sì (oggetto del cluster)

Tiene namespace

Sí

Has a namespace

Yes

Ha un namespace

Sì

Se crea con kubectl

Sí

Created with kubectl

Yes

Si crea con kubectl

Sì

# ¿Puedo crear deployments?# Can I create deployments?# Posso creare deployment? k auth can-i create deployments # ¿Puedo borrar pods en el ns kube-system?# Can I delete pods in the kube-system ns?# Posso cancellare pod nel ns kube-system? k auth can-i delete pods -n kube-system # Respuesta: yes / no# Answer: yes / no# Risposta: yes / no

# ¿El usuario juan puede listar pods?# Can user juan list pods?# L'utente juan può elencare i pod? k auth can-i list pods --as juan # ¿El SA miapp puede crear services?# Can the miapp SA create services?# Il SA miapp può creare service? k auth can-i create services \ --as=system:serviceaccount:default:miapp

# Ver el context actual# Show the current context# Mostrare il context corrente k config current-context # Listar todos los contexts# List all contexts# Elencare tutti i context k config get-contexts # Cambiar de context# Switch context# Cambiare context k config use-context <nombre> # Ver el kubeconfig completo# View the whole kubeconfig# Vedere l'intero kubeconfig k config view

Sección	Qué define
clusters	A qué API server (URL + CA)
clusters	Which API server (URL + CA)
clusters	Quale API server (URL + CA)
users	Quién sos (cert/token/credenciales)
users	Who you are (cert/token/credentials)
users	Chi sei (cert/token/credenziali)
contexts	Combina cluster + user + namespace
contexts	Combines cluster + user + namespace
contexts	Combina cluster + user + namespace

Sección

Qué define

Section

What it defines

Sezione

Cosa definisce

clusters

A qué API server (URL + CA)

clusters

Which API server (URL + CA)

clusters

Quale API server (URL + CA)

users

Quién sos (cert/token/credenciales)

users

Who you are (cert/token/credentials)

users

Chi sei (cert/token/credenziali)

contexts

Combina cluster + user + namespace

contexts

Combines cluster + user + namespace

contexts

Combina cluster + user + namespace

# Crear permisos (el QUÉ)# Create permissions (the WHAT)# Creare permessi (il COSA) k create role NAME --verb=get,list --resource=pods $do k create clusterrole NAME --verb=... --resource=nodes $do # Conectar (el pegamento)# Connect (the glue)# Collegare (la colla) k create rolebinding NAME --role=R --user=U $do k create clusterrolebinding NAME --clusterrole=CR --user=U $do # ServiceAccount (identidad de pods)# ServiceAccount (pod identity)# ServiceAccount (identità dei pod) k create serviceaccount NAME k create rolebinding NAME --role=R \ --serviceaccount=NS:SA $do # Verificar permisos# Verify permissions# Verificare i permessi 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

★

Fase 2 · resolver en vivo

Phase 2 · solve it live

Fase 2 · risolvere dal vivo

Práctica — 9 ejercicios

Practice — 9 exercises

Pratica — 9 esercizi

~5 min cada uno: el ritmo del examen. No abras la solución hasta intentarlo.

~5 min each: exam pace. Do not open the solution until you have tried.

~5 min ciascuno: il ritmo dell'esame. Non aprire la soluzione prima di provare.

0 / 9

🧠

Modelo mental. QUIÉN (subject) + QUÉ (Role/ClusterRole) = conectados por un BINDING. El Role sin binding no hace nada. Y RBAC es aditivo: solo tenés lo que algún binding te otorgó explícitamente — no existen reglas de negación.

Mental model. WHO (subject) + WHAT (Role/ClusterRole) = connected by a BINDING. A Role with no binding does nothing. And RBAC is additive: you only have what some binding explicitly granted — there are no deny rules.

Modello mentale. CHI (subject) + COSA (Role/ClusterRole) = connessi da un BINDING. Un Role senza binding non fa nulla. E RBAC è additivo: hai solo ciò che un binding ti ha concesso esplicitamente — non esistono regole di negazione.

◆

Preparación. Estos ejercicios no rompen el cluster, así que no hace falta snapshot. Sí hacen falta namespaces: k create ns dev staging prod pipeline. Para limpiar entre reps, etiquetá lo que creás con ej=rbac y borralo: k delete role,clusterrole,rolebinding,clusterrolebinding,sa -l ej=rbac -A --ignore-not-found.

Setup. These exercises do not break the cluster, so no snapshot is needed. Namespaces are: k create ns dev staging prod pipeline. To clean between reps, label what you create with ej=rbac and delete it: k delete role,clusterrole,rolebinding,clusterrolebinding,sa -l ej=rbac -A --ignore-not-found.

Preparazione. Questi esercizi non rompono il cluster, quindi non serve snapshot. Servono i namespace: k create ns dev staging prod pipeline. Per pulire fra le rep, etichetta ciò che crei con ej=rbac e cancellalo: k delete role,clusterrole,rolebinding,clusterrolebinding,sa -l ej=rbac -A --ignore-not-found.

El binding básico (SA + Role + RoleBinding)

The basic binding (SA + Role + RoleBinding)

Il binding di base (SA + Role + RoleBinding)

~5 min hecho

En el namespace default, creá un ServiceAccount llamado tester. Creá un Role svc-reader que permita get, list y watch sobre services. Otorgale ese role al SA tester con un RoleBinding llamado tester-svc. Verificá que tester puede listar services pero no puede listar pods.

Es el patrón canónico de RBAC — que te salga sin pensar.

In the default namespace, create a ServiceAccount called tester. Create a Role svc-reader allowing get, list and watch on services. Grant that role to the tester SA with a RoleBinding called tester-svc. Verify tester can list services but cannot list pods.

This is the canonical RBAC pattern — it should come out without thinking.

Nel namespace default, crea un ServiceAccount chiamato tester. Crea un Role svc-reader che permetta get, list e watch sui services. Concedi quel role al SA tester con un RoleBinding chiamato tester-svc. Verifica che tester possa elencare i service ma non i pod.

È il pattern canonico di RBAC — deve uscirti senza pensare.

Ver soluciónShow solutionMostra soluzione

# QUIÉN# WHO# CHI
k create serviceaccount tester

# QUÉ# WHAT# COSA
k create role svc-reader --verb=get,list,watch --resource=services

# BINDING (pegamento): conecta el QUIÉN con el QUÉ# BINDING (the glue): connects the WHO to the WHAT# BINDING (la colla): collega il CHI al COSA
k create rolebinding tester-svc --role=svc-reader --serviceaccount=default:tester

# VERIFICAR (impersonando al SA)# VERIFY (impersonating the SA)# VERIFICARE (impersonando il SA)
k auth can-i list services --as=system:serviceaccount:default:tester   #  yes
k auth can-i list pods     --as=system:serviceaccount:default:tester   #  no

Claves

Key points

Punti chiave

El SA como subject se escribe completo: system:serviceaccount:<ns>:<nombre>.
El role solo cubre services, así que pods da no: el permiso que no otorgás, no existe.
Tres objetos, tres comandos. Si te sale en menos de 2 minutos sin mirar, este patrón ya es tuyo.

An SA as a subject is written in full: system:serviceaccount:<ns>:<name>.
The role only covers services, so pods returns no: a permission you do not grant does not exist.
Three objects, three commands. If it takes under 2 minutes from memory, this pattern is yours.

Un SA come subject si scrive per intero: system:serviceaccount:<ns>:<nome>.
Il role copre solo i services, quindi pods dà no: un permesso che non concedi non esiste.
Tre oggetti, tre comandi. Se ti riesce in meno di 2 minuti a memoria, questo pattern è tuo.

La trampa: ClusterRoleBinding → Role

The trap: ClusterRoleBinding → Role

La trappola: ClusterRoleBinding → Role

~5 min hecho

Tenés el Role svc-reader (namespaced, del E1). Querés dárselo al usuario juan a nivel de todo el cluster con un ClusterRoleBinding. Intentalo. ¿Qué pasa y por qué? Después, lográ el objetivo real ("juan puede leer services en el namespace dev") de la forma correcta.

You have the svc-reader Role (namespaced, from E1). You want to give it to user juan across the whole cluster with a ClusterRoleBinding. Try it. What happens and why? Then achieve the real goal ("juan can read services in the dev namespace") the correct way.

Hai il Role svc-reader (namespaced, dall'E1). Vuoi darlo all'utente juan su tutto il cluster con un ClusterRoleBinding. Provaci. Cosa succede e perché? Poi raggiungi l'obiettivo vero ("juan può leggere i service nel namespace dev") nel modo giusto.

Ver soluciónShow solutionMostra soluzione

No se puede, y el propio kubectl te lo impide: create clusterrolebinding solo tiene el flag --clusterrole, no existe --role. Un ClusterRoleBinding nunca referencia un Role.

It cannot be done, and kubectl itself stops you: create clusterrolebinding only has the --clusterrole flag; --role does not exist. A ClusterRoleBinding never references a Role.

Non si può, e kubectl stesso te lo impedisce: create clusterrolebinding ha solo il flag --clusterrole; --role non esiste. Un ClusterRoleBinding non referenzia mai un Role.

# la forma correcta: ClusterRole (reutilizable) + RoleBinding (acotado)# the correct way: ClusterRole (reusable) + RoleBinding (scoped)# il modo giusto: ClusterRole (riutilizzabile) + RoleBinding (limitato)
k create clusterrole svc-reader-cr --verb=get,list,watch --resource=services
k create rolebinding juan-svc-dev --clusterrole=svc-reader-cr --user=juan -n dev

# el alcance lo pone el BINDING, no el ClusterRole:# scope comes from the BINDING, not the ClusterRole:# l'ambito lo dà il BINDING, non il ClusterRole:
k auth can-i list services --as=juan -n dev      #  yes
k auth can-i list services --as=juan -n default  #  no

Claves

Key points

Punti chiave

Por qué: un Role vive atado a un namespace; un ClusterRoleBinding es cluster-wide. Otorgar cluster-wide algo que solo existe en un namespace no tiene sentido, así que la API lo prohíbe.
Idea que no se negocia: el "Cluster" en ClusterRole es solo la definición; el alcance real lo decide el binding.
Además el CRB acá habría sido un over-grant: pedían dev, no todo el cluster.

Why: a Role is tied to a namespace; a ClusterRoleBinding is cluster-wide. Granting cluster-wide something that exists in one namespace makes no sense, so the API forbids it.
Non-negotiable idea: the "Cluster" in ClusterRole is only the definition; the real scope is the binding's call.
Besides, a CRB here would have been an over-grant: dev was asked for, not the whole cluster.

Perché: un Role è legato a un namespace; un ClusterRoleBinding è cluster-wide. Concedere cluster-wide qualcosa che esiste in un namespace non ha senso, perciò l'API lo vieta.
Idea non negoziabile: il "Cluster" in ClusterRole è solo la definizione; l'ambito reale lo decide il binding.
Inoltre qui un CRB sarebbe stato un over-grant: chiedevano dev, non tutto il cluster.

Misma trampa, pero el subject es un ServiceAccount

Same trap, but the subject is a ServiceAccount

Stessa trappola, ma il subject è un ServiceAccount

~5 min hecho

En el namespace pipeline existe el ServiceAccount runner. Reutilizando el ClusterRole secret-reader (ya existe: get,list,watch sobre secrets), hacé que runner pueda leer los secrets solo en pipeline. No crees ningún Role nuevo.

Criterio: get secrets --as=system:serviceaccount:pipeline:runner → yes en pipeline, no en default.

In the pipeline namespace the ServiceAccount runner exists. Reusing the secret-reader ClusterRole (already there: get,list,watch on secrets), make runner able to read secrets only in pipeline. Create no new Role.

Criterion: get secrets --as=system:serviceaccount:pipeline:runner → yes in pipeline, no in default.

Nel namespace pipeline esiste il ServiceAccount runner. Riutilizzando il ClusterRole secret-reader (già presente: get,list,watch sui secrets), fai in modo che runner possa leggere i secret solo in pipeline. Non creare nessun Role nuovo.

Criterio: get secrets --as=system:serviceaccount:pipeline:runner → yes in pipeline, no in default.

Ver soluciónShow solutionMostra soluzione

k create rolebinding runner-secrets \
  --clusterrole=secret-reader --serviceaccount=pipeline:runner -n pipeline

k auth can-i get secrets --as=system:serviceaccount:pipeline:runner -n pipeline   #  yes
k auth can-i get secrets --as=system:serviceaccount:pipeline:runner -n default    #  no

Claves

Key points

Punti chiave

Mismo patrón que E2 (ClusterRole + RoleBinding acotado); cambia solo el subject.
Un SA se pasa con --serviceaccount=<ns>:<nombre> en el binding y se impersona con --as=system:serviceaccount:<ns>:<nombre>. Dos sintaxis para lo mismo — memorizá las dos.
El alcance lo sigue poniendo el RoleBinding, que vive en pipeline.

Same pattern as E2 (ClusterRole + scoped RoleBinding); only the subject changes.
An SA is passed as --serviceaccount=<ns>:<name> in the binding and impersonated as --as=system:serviceaccount:<ns>:<name>. Two syntaxes for the same thing — memorise both.
Scope still comes from the RoleBinding, which lives in pipeline.

Stesso pattern dell'E2 (ClusterRole + RoleBinding limitato); cambia solo il subject.
Un SA si passa come --serviceaccount=<ns>:<nome> nel binding e si impersona come --as=system:serviceaccount:<ns>:<nome>. Due sintassi per la stessa cosa — memorizzale entrambe.
L'ambito continua a darlo il RoleBinding, che vive in pipeline.

Cuándo el ClusterRoleBinding SÍ corresponde

When a ClusterRoleBinding IS the right call

Quando il ClusterRoleBinding È la scelta giusta

~5 min hecho

El usuario ops tiene que poder listar nodes en todo el cluster. Logralo. Después respondé: ¿podrías haber acotado esto a un solo namespace con un RoleBinding? ¿Por qué no?

User ops must be able to list nodes across the whole cluster. Make it happen. Then answer: could you have confined this to a single namespace with a RoleBinding? Why not?

L'utente ops deve poter elencare i nodes su tutto il cluster. Fallo. Poi rispondi: avresti potuto limitarlo a un solo namespace con un RoleBinding? Perché no?

Ver soluciónShow solutionMostra soluzione

k create clusterrole node-viewer --verb=get,list,watch --resource=nodes
k create clusterrolebinding ops-nodes --clusterrole=node-viewer --user=ops

k auth can-i list nodes --as=ops    #  yes (nodes no vive en ningún namespace)#  yes (nodes lives in no namespace)#  yes (nodes non vive in alcun namespace)

Claves

Key points

Punti chiave

nodes es un recurso cluster-scoped — no pertenece a ningún namespace. Un RoleBinding solo gobierna recursos de su namespace, así que no hay forma de acotarlo.
Para recursos cluster-scoped el único binding válido es el ClusterRoleBinding.
Contraste con E2: acá el CRB no es over-grant (es la única opción); allá sí lo era, porque services es namespaced y existía la alternativa acotada.

nodes is a cluster-scoped resource — it belongs to no namespace. A RoleBinding governs only resources in its namespace, so there is no way to confine it.
For cluster-scoped resources the only valid binding is the ClusterRoleBinding.
Contrast with E2: here the CRB is not an over-grant (it is the only option); there it was, because services is namespaced and the scoped alternative existed.

nodes è una risorsa cluster-scoped — non appartiene a nessun namespace. Un RoleBinding governa solo risorse del suo namespace, quindi non c'è modo di limitarlo.
Per le risorse cluster-scoped l'unico binding valido è il ClusterRoleBinding.
Contrasto con E2: qui il CRB non è un over-grant (è l'unica opzione); là lo era, perché services è namespaced ed esisteva l'alternativa limitata.

Un ClusterRole, dos namespaces (y un tercero que no)

One ClusterRole, two namespaces (and a third that stays out)

Un ClusterRole, due namespace (e un terzo che resta fuori)

~5 min hecho

El usuario dev-lead tiene que poder listar services en dev y en staging, pero no en prod. Reutilizá un solo ClusterRole (svc-reader-cr, del E2).

User dev-lead must be able to list services in dev and staging, but not in prod. Reuse a single ClusterRole (svc-reader-cr, from E2).

L'utente dev-lead deve poter elencare i services in dev e in staging, ma non in prod. Riutilizza un solo ClusterRole (svc-reader-cr, dall'E2).

Ver soluciónShow solutionMostra soluzione

k create rolebinding devlead-svc --clusterrole=svc-reader-cr --user=dev-lead -n dev
k create rolebinding devlead-svc --clusterrole=svc-reader-cr --user=dev-lead -n staging

k auth can-i list services --as=dev-lead -n dev      #  yes
k auth can-i list services --as=dev-lead -n staging  #  yes
k auth can-i list services --as=dev-lead -n prod     #  no

Claves

Key points

Punti chiave

Un RoleBinding gobierna un namespace: dos namespaces = dos RoleBindings.
Los dos bindings pueden tener el mismo nombre: los objetos namespaced son únicos por namespace, no globalmente.
prod no tiene binding, así que queda afuera: el ClusterRole por sí solo no otorga nada hasta que un binding lo activa en un namespace concreto.

A RoleBinding governs one namespace: two namespaces = two RoleBindings.
Both bindings can share the same name: namespaced objects are unique per namespace, not globally.
prod has no binding, so it stays out: a ClusterRole alone grants nothing until a binding activates it in a concrete namespace.

Un RoleBinding governa un namespace: due namespace = due RoleBinding.
I due binding possono avere lo stesso nome: gli oggetti namespaced sono unici per namespace, non globalmente.
prod non ha binding, quindi resta fuori: un ClusterRole da solo non concede nulla finché un binding non lo attiva in un namespace concreto.

El SA que usa un pod

The SA a pod actually uses

Il SA che un pod usa davvero

~5 min hecho

Creá un ServiceAccount reader-sa. Creá un pod probe (imagen nginx) que use ese SA. Verificá desde el objeto pod que quedó asignado (no el default).

Create a ServiceAccount reader-sa. Create a pod probe (image nginx) that uses that SA. Verify from the pod object that it stuck (not the default).

Crea un ServiceAccount reader-sa. Crea un pod probe (immagine nginx) che usi quel SA. Verifica dall'oggetto pod che sia stato assegnato (non il default).

Ver soluciónShow solutionMostra soluzione

k create serviceaccount reader-sa

# generá el pod y agregá serviceAccountName (el imperativo no tiene flag)# generate the pod and add serviceAccountName (no imperative flag exists)# genera il pod e aggiungi serviceAccountName (non esiste un flag imperativo)
k run probe --image=nginx $do > probe.yaml
vim probe.yaml       # bajo spec:  serviceAccountName: reader-sa# under spec:  serviceAccountName: reader-sa# sotto spec:  serviceAccountName: reader-sa
k apply -f probe.yaml

k get pod probe -o jsonpath='{.spec.serviceAccountName}'   #  reader-sa

Claves

Key points

Punti chiave

serviceAccountName va en spec: del pod, al mismo nivel que containers:.
No hay flag imperativo para un pod — es de los casos de "generá y editá" del M0.
Para un deployment ya existente sí lo hay: k set serviceaccount deployment/web reader-sa.

serviceAccountName goes under the pod's spec:, at the same level as containers:.
There is no imperative flag for a pod — one of M0's "generate and edit" cases.
For an existing deployment there is one: k set serviceaccount deployment/web reader-sa.

serviceAccountName va sotto spec: del pod, allo stesso livello di containers:.
Non esiste un flag imperativo per un pod — è uno dei casi "genera e modifica" del M0.
Per un deployment esistente sì: k set serviceaccount deployment/web reader-sa.

Del pod al permiso (encadenar todo)

From pod to permission (chaining it all)

Dal pod al permesso (concatenare tutto)

~5 min hecho

El SA reader-sa del E6 debe poder leer configmaps (get, list) solo en el namespace default. Otorgale el permiso y verificá como el SA. Extra: confirmá que NO puede crearlos.

The reader-sa SA from E6 must be able to read configmaps (get, list) only in the default namespace. Grant the permission and verify as the SA. Extra: confirm it CANNOT create them.

Il SA reader-sa dell'E6 deve poter leggere le configmap (get, list) solo nel namespace default. Concedi il permesso e verifica come il SA. Extra: conferma che NON può crearle.

Ver soluciónShow solutionMostra soluzione

k create role cm-reader --verb=get,list --resource=configmaps
k create rolebinding reader-sa-cm --role=cm-reader --serviceaccount=default:reader-sa

k auth can-i list   configmaps --as=system:serviceaccount:default:reader-sa   #  yes
k auth can-i create configmaps --as=system:serviceaccount:default:reader-sa   #  no

Claves

Key points

Punti chiave

configmaps es del core group (apiGroups: [""]), como pods y services.
El verbo create no está en el role → no. RBAC es aditivo: solo tenés lo que algún binding te otorga explícitamente.
Encadenaste las tres piezas del módulo: un SA que usa un pod, un Role, y el binding que los une.

configmaps is in the core group (apiGroups: [""]), like pods and services.
The create verb is not in the role → no. RBAC is additive: you only have what a binding explicitly grants.
You chained the module's three pieces: an SA a pod uses, a Role, and the binding joining them.

configmaps è nel core group (apiGroups: [""]), come pod e service.
Il verbo create non è nel role → no. RBAC è additivo: hai solo ciò che un binding concede esplicitamente.
Hai concatenato i tre pezzi del modulo: un SA usato da un pod, un Role, e il binding che li unisce.

Diagnóstico rápido con auth can-i · y kubeconfig

Fast diagnosis with auth can-i · and kubeconfig

Diagnosi rapida con auth can-i · e kubeconfig

~5 min hecho

Sin crear nada nuevo, un comando por respuesta: (1) ¿vos podés borrar pods en kube-system? (2) ¿juan puede listar services en dev? (3) mostrá el mapa completo de lo que puede hacer el SA tester. (4) Mostrá el context actual y listá todos. (5) Cambiá el namespace por defecto de tu context a dev. (6) Explicá con tus palabras las 3 secciones de un kubeconfig.

Without creating anything new, one command per answer: (1) can you delete pods in kube-system? (2) can juan list services in dev? (3) show the full map of what the tester SA can do. (4) Show the current context and list them all. (5) Change your context's default namespace to dev. (6) Explain in your own words the 3 sections of a kubeconfig.

Senza creare nulla di nuovo, un comando per risposta: (1) puoi cancellare pod in kube-system? (2) juan può elencare i service in dev? (3) mostra la mappa completa di ciò che può fare il SA tester. (4) Mostra il context corrente ed elencali tutti. (5) Cambia il namespace predefinito del tuo context a dev. (6) Spiega a parole tue le 3 sezioni di un kubeconfig.

Ver soluciónShow solutionMostra soluzione

k auth can-i delete pods -n kube-system                         # 1  yes (sos admin)# 1  yes (you are admin)# 1  yes (sei admin)
k auth can-i list services --as=juan -n dev                     # 2  yes
k auth can-i --list --as=system:serviceaccount:default:tester   # 3  tabla de permisos# 3  permission table# 3  tabella dei permessi

k config current-context
k config get-contexts
k config set-context --current --namespace=dev
# para volver: k config set-context --current --namespace=default# to go back: k config set-context --current --namespace=default# per tornare: k config set-context --current --namespace=default

Claves

Key points

Punti chiave

--as impersona sin tener que loguearte como ese subject; auth can-i --list es la radiografía completa. Es el paso 1 de todo diagnóstico de RBAC.
clusters = a qué API server apuntás (URL + CA). users = quién sos (cert/token). contexts = el perfil activo: cluster + user + namespace.
En el examen cada tarea puede pedir un cluster distinto: k config use-context es de los comandos que más vas a tipear.

--as impersonates without logging in as that subject; auth can-i --list is the full X-ray. It is step 1 of every RBAC diagnosis.
clusters = which API server you point at (URL + CA). users = who you are (cert/token). contexts = the active profile: cluster + user + namespace.
In the exam each task may want a different cluster: k config use-context is among the commands you type most.

--as impersona senza autenticarti come quel subject; auth can-i --list è la radiografia completa. È il passo 1 di ogni diagnosi RBAC.
clusters = a quale API server punti (URL + CA). users = chi sei (cert/token). contexts = il profilo attivo: cluster + user + namespace.
All'esame ogni task può volere un cluster diverso: k config use-context è fra i comandi che digiterai di più.

Troubleshooting — el pod con Forbidden

Troubleshooting — the pod with Forbidden

Troubleshooting — il pod con Forbidden

~6 min hecho

Una app corre con el SA app-sa en default y en sus logs aparece:

Error: pods is forbidden: User "system:serviceaccount:default:app-sa" cannot list resource "pods"

Diagnosticá por qué y arreglalo para que el SA pueda listar pods. Prepararlo: k create sa app-sa.

An app runs with the app-sa SA in default and its logs show:

Error: pods is forbidden: User "system:serviceaccount:default:app-sa" cannot list resource "pods"

Diagnose why and fix it so the SA can list pods. To set it up: k create sa app-sa.

Un'app gira con il SA app-sa in default e nei log compare:

Error: pods is forbidden: User "system:serviceaccount:default:app-sa" cannot list resource "pods"

Diagnostica perché e sistemalo così che il SA possa elencare i pod. Per prepararlo: k create sa app-sa.

Ver soluciónShow solutionMostra soluzione

# 1 · confirmar qué falta# 1 · confirm what is missing# 1 · confermare cosa manca
k auth can-i list pods --as=system:serviceaccount:default:app-sa   #  no

# 2 · ver el mapa: ¿tiene algún permiso?# 2 · see the map: does it have any permission at all?# 2 · vedere la mappa: ha qualche permesso?
k auth can-i --list --as=system:serviceaccount:default:app-sa      #  casi nada#  almost nothing#  quasi nulla

# 3 · diagnóstico: no hay Role con list pods, ni Binding que conecte al SA# 3 · diagnosis: no Role with list pods, and no Binding connecting the SA# 3 · diagnosi: nessun Role con list pods, né Binding che colleghi il SA

# 4 · arreglar# 4 · fix# 4 · sistemare
k create role pod-reader --verb=get,list,watch --resource=pods
k create rolebinding app-sa-pods --role=pod-reader --serviceaccount=default:app-sa

# 5 · reverificar# 5 · re-verify# 5 · riverificare
k auth can-i list pods --as=system:serviceaccount:default:app-sa   #  yes

Claves

Key points

Punti chiave

El error es un dato, no un obstáculo: el mensaje te da el subject completo y el recurso. Ya sabés qué preguntarle a can-i.
El 90% de los "Forbidden" de RBAC es falta el binding o el role no tiene el verbo/recurso correcto.
Volvé siempre al modelo: ¿quién? ¿qué permiso? ¿están conectados? Y reverificá siempre al final.

The error is data, not an obstacle: the message hands you the full subject and the resource. You already know what to ask can-i.
90% of RBAC "Forbidden" is a missing binding or a role without the right verb/resource.
Always return to the model: who? which permission? are they connected? And always re-verify at the end.

L'errore è un dato, non un ostacolo: il messaggio ti dà il subject completo e la risorsa. Sai già cosa chiedere a can-i.
Il 90% dei "Forbidden" di RBAC è un binding mancante o un role senza il verbo/risorsa giusti.
Torna sempre al modello: chi? quale permesso? sono collegati? E riverifica sempre alla fine.

Autoevaluación — antes de marcar M2 como ★ dominado

Self-check — before marking M2 as ★ mastered

Autovalutazione — prima di segnare M2 come ★ padroneggiato

Escribir el trío SA + Role + RoleBinding de memoria en menos de 2 min.
Explicar por qué ClusterRoleBinding → Role no existe.
Elegir entre RoleBinding y ClusterRoleBinding sabiendo si el recurso es namespaced o cluster-scoped.
Reutilizar un ClusterRole en varios namespaces con RoleBindings.
Asignar un SA a un pod y saber dónde va el campo.
Verificar permisos de cualquier subject con --as y --as … --list.
Diagnosticar un Forbidden desde el mensaje hasta el fix.
Cambiar context y namespace por defecto.

Write the SA + Role + RoleBinding trio from memory in under 2 min.
Explain why ClusterRoleBinding → Role does not exist.
Choose between RoleBinding and ClusterRoleBinding knowing whether the resource is namespaced or cluster-scoped.
Reuse a ClusterRole across several namespaces with RoleBindings.
Assign an SA to a pod and know where the field goes.
Verify any subject's permissions with --as and --as … --list.
Diagnose a Forbidden from the message all the way to the fix.
Switch context and default namespace.

Scrivere il trio SA + Role + RoleBinding a memoria in meno di 2 min.
Spiegare perché ClusterRoleBinding → Role non esiste.
Scegliere fra RoleBinding e ClusterRoleBinding sapendo se la risorsa è namespaced o cluster-scoped.
Riutilizzare un ClusterRole in più namespace con RoleBinding.
Assegnare un SA a un pod e sapere dove va il campo.
Verificare i permessi di qualsiasi subject con --as e --as … --list.
Diagnosticare un Forbidden dal messaggio fino al fix.
Cambiare context e namespace predefinito.

El modelo mental que resuelve todo RBAC

The mental model that solves all of RBAC

Il modello mentale che risolve tutto RBAC

Roles & ClusterRoles

Role — permisos en UN namespace

Role — permissions in ONE namespace

Role — permessi in UN namespace

ClusterRole — permisos en TODO el cluster

ClusterRole — permissions across the WHOLE cluster

ClusterRole — permessi su TUTTO il cluster

Role vs ClusterRole

Role vs ClusterRole

Role contro ClusterRole

Las 3 partes de un rule

The 3 parts of a rule

Le 3 parti di una rule

Los verbos comunes

The common verbs

I verbi comuni

RoleBindings & ClusterRoleBindings

RoleBinding — da permisos en UN namespace

RoleBinding — grants in ONE namespace

RoleBinding — concede in UN namespace

ClusterRoleBinding — da permisos en TODO el cluster

ClusterRoleBinding — grants across the WHOLE cluster

ClusterRoleBinding — concede su TUTTO il cluster

El patrón útil: ClusterRole + RoleBinding

The useful pattern: ClusterRole + RoleBinding

Il pattern utile: ClusterRole + RoleBinding

La tabla que tenés que saber de memoria

The table you must know by heart

La tabella da sapere a memoria

La regla en palabras

The rule in words

La regola a parole

Por qué ClusterRoleBinding → Role no existe

Why ClusterRoleBinding → Role does not exist

Perché ClusterRoleBinding → Role non esiste

El role es el QUÉ · el binding es el DÓNDE

The role is the WHAT · the binding is the WHERE

Il role è il COSA · il binding è il DOVE

Eje 1 — el ROLE (el QUÉ)

Axis 1 — the ROLE (the WHAT)

Asse 1 — il ROLE (il COSA)

Eje 2 — el BINDING (el DÓNDE aplica)

Axis 2 — the BINDING (WHERE it applies)

Asse 2 — il BINDING (DOVE si applica)

Permiso en UN namespace

Permission in ONE namespace

Permesso in UN namespace

Definición reutilizable, ACOTADA a un namespace

Reusable definition, CONFINED to one namespace

Definizione riutilizzabile, LIMITATA a un namespace

Permiso en TODO el cluster

Permission across the WHOLE cluster

Permesso su TUTTO il cluster

❌ No existe

❌ Does not exist

❌ Non esiste

ServiceAccounts

Crear y usar un ServiceAccount

Creating and using a ServiceAccount

Creare e usare un ServiceAccount

Asignar el SA a un pod

Assigning the SA to a pod

Assegnare il SA a un pod

Imperativo: setear el SA de un deployment

Imperative: set a deployment's SA

Imperativo: impostare il SA di un deployment

Darle permisos al SA (combina todo)

Granting the SA permissions (it all comes together)

Dare permessi al SA (mette insieme tutto)

User vs ServiceAccount

User vs ServiceAccount

User contro ServiceAccount

El dato clave

The key fact

Il dato chiave

Cómo se nombra un SA en un binding

How an SA is named in a binding