0Pricing
Kubernetes Basics · Lezione

Account di servizio e identità dei workload

Impari come i Service Accounts assegnano ai Pod una propria identità, come funzionano i relativi token e come concedere loro l’accesso con il principio del privilegio minimo.

Account di servizio e identità dei workload è una lezione Kubernetes Basics gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Kubernetes Basics, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Kubernetes Basics include 4 lezioni in totale.

Identità per i workload

Gli utenti si autenticano presso Kubernetes, ma anche i Pod hanno bisogno di un'identità per poter comunicare in sicurezza con il server API. Questa identità è un Service Account.

Che cos'è un Service Account?

Un ServiceAccount è un oggetto associato a un namespace che rappresenta l'identità di un workload. Ogni Pod viene eseguito con un Service Account; se non ne specifica uno, viene usato default.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: report-generator
  namespace: analytics

Assegnare un Service Account a un Pod

Imposti serviceAccountName nella specifica del Pod per eseguirlo con un'identità specifica.

apiVersion: v1
kind: Pod
metadata:
  name: reporter
spec:
  serviceAccountName: report-generator
  containers:
  - name: app
    image: reporter:1.0

Il token montato

Kubernetes monta nel Pod un token JWT a breve durata per il Service Account, utilizzato per autenticare le chiamate all'API.

# inside the Pod
cat /var/run/secrets/kubernetes.io/serviceaccount/token

Perché l'account predefinito è rischioso

Il ServiceAccount default è condiviso da tutti i Pod di un namespace. Assegnargli delle autorizzazioni esporrebbe eccessivamente ogni workload. Preferisca un account dedicato per ogni workload.

Disabilitare il montaggio automatico del token

Se un Pod non chiama mai l'API, disabiliti il montaggio del token per ridurre la superficie di attacco.

apiVersion: v1
kind: Pod
metadata:
  name: no-api-pod
spec:
  automountServiceAccountToken: false
  containers:
  - name: app
    image: myapp:1.0

Concedere autorizzazioni con RBAC

Un Service Account non ha alcun potere finché non lo associa a un Role. Il subject del RoleBinding è il Service Account.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: reporter-read
  namespace: analytics
subjects:
- kind: ServiceAccount
  name: report-generator
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Il principio del privilegio minimo in pratica

  • Utilizzare un Service Account per ogni workload
  • Concedere solo i verbi e le risorse di cui ha realmente bisogno
  • Limitare l'ambito a un namespace con Role quando possibile, invece di usare ClusterRole

Token associati e proiettati

I token moderni sono proiettati e associati alla durata del Pod, con una scadenza breve. Si rinnovano automaticamente, quindi un token sottratto è molto meno pericoloso rispetto ai vecchi secret di lunga durata.

Identità dei workload nel cloud

Le piattaforme cloud associano un ServiceAccount Kubernetes a un'identità IAM cloud, ad esempio IRSA su AWS o Workload Identity su GKE, così i Pod possono accedere alle risorse cloud senza memorizzare credenziali statiche.

metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123:role/report-role

Verificare le autorizzazioni

Utilizzi kubectl auth can-i impersonando il Service Account per confermare che disponga esattamente dell'accesso previsto.

kubectl auth can-i list pods \
  --as=system:serviceaccount:analytics:report-generator \
  -n analytics

Verifica rapida

Verifichi la sua comprensione dei Service Account.

Riepilogo

Ha imparato che un ServiceAccount fornisce a un Pod una propria identità, supportata da token proiettati a breve durata. Applichi il principio del privilegio minimo con un account dedicato per ogni workload, conceda l'accesso tramite binding RBAC, disabiliti il montaggio dei token quando non servono e associ gli account a IAM cloud per accedere senza credenziali.

Domande Frequenti

La lezione «Account di servizio e identità dei workload» è gratuita?

Sì — il testo completo di «Account di servizio e identità dei workload» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Kubernetes Basics, passa a CoddyKit PRO. Il corso Kubernetes Basics include 4 lezioni in totale.

Cosa imparerò in «Account di servizio e identità dei workload»?

Impari come i Service Accounts assegnano ai Pod una propria identità, come funzionano i relativi token e come concedere loro l’accesso con il principio del privilegio minimo. Eserciti Kubernetes Basics con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Kubernetes Basics?

Non è richiesta alcuna esperienza precedente. Kubernetes Basics su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Account di servizio e identità dei workload»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Kubernetes Basics?

Sì. Ogni lezione Kubernetes Basics include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Role-Based Access Control (RBAC)
  2. Network Policy per l'isolamento
  3. Standard di sicurezza dei Pod
  4. Account di servizio e identità dei workload
← Torna a Kubernetes Basics