Identità e accesso

Tutto ciò che fai con kubehz (la dashboard, l’API e kubectl su un cluster hosted) sta dietro un unico accesso. Questa pagina spiega come funziona quel login e come raggiunge i tuoi cluster.

Un solo provider di identità

kubehz esegue il proprio provider di identità single sign-on (basato su ZITADEL). Accedi una volta a kubehz e quell’identità viene usata ovunque. Non c’è alcuna password di cluster separata da gestire.

Puoi accedere con:

• Email e password, protetta da autenticazione a due fattori;
• GitHub;
• Google;
• il tuo SSO (lo colleghiamo insieme a te, per organizzazione: non c’è owner o admin, dalla dashboard; ti aiutiamo se la federazione non è ancora abilitata per la tua organizzazione): federa un provider OIDC esterno (Okta, Entra, Google Workspace, …) così il tuo team usa la vostra identità aziendale esistente. Vedi Accesso e il tuo identity provider e Accesso e ruoli.

Il tuo team è isolato

Ogni team riceve la propria organizzazione di identità. I tuoi membri, i loro ruoli e qualsiasi SSO che federi risiedono all’interno della tua organizzazione e in nessun altro luogo: un team non può mai vedere o influenzare le persone o l’accesso di un altro team. Questo isolamento è il fondamento di come l’accesso ai cluster rimane separato tra i clienti.

Come l’accesso diventa accesso al cluster

Per un cluster hosted, non gestisci mai un insieme separato di utenti Kubernetes. Funziona così:

1. Accedi a kubehz. Il tuo tier e i tuoi ruoli personalizzati sono allegati al tuo token come group claim, contrassegnati con l’organizzazione del tuo team.
2. L’API server del tuo cluster hosted si fida di kubehz come proprio provider di identità OIDC.
3. Quando esegui kubectl con il kubeconfig OIDC, l’API server legge quei gruppi e li mappa all’RBAC di Kubernetes, ma corrispondono solo i binding per l’organizzazione del tuo team, quindi un token di un team non può mai ottenere accesso al cluster di un altro team.

Il risultato: aggiungi qualcuno al tuo team con un ruolo, e può usare kubectl immediatamente; rimuovilo, e il suo accesso termina: nessuna gestione degli utenti lato cluster, e nessun modo per far incrociare l’accesso tra team.

Cluster self-hosted

Tutto quanto sopra riguarda un cluster hosted. Per uno self-hosted la risposta è più breve, ed è quella che conta: l’API server del tuo cluster non si fida di kubehz.

• kubehz non è un provider di identità per il tuo cluster. Il tuo kubeconfig, il tuo RBAC e i tuoi utenti restano intatti; accedere a kubehz non concede a nessuno alcun accesso dentro il tuo cluster.
• L’accesso a kubehz governa la dashboard e l’API: chi nel tuo team vede i cluster registrati e chi può modificare le impostazioni del team.
• La piattaforma non si connette mai dentro un cluster self-hosted; l’agente nel cluster comunica solo verso l’esterno. Vedi Registrazione.

Non serve un account kubehz per far girare un cluster. lo funziona anche senza.

Step-up per azioni sensibili

Le azioni che concedono o ampliano l’accesso (invitare un membro, abilitare il kubeconfig admin a lunga durata) richiedono un accesso a due fattori fresco nel momento in cui le esegui, anche se hai già effettuato l’accesso. Questo impedisce che una sessione rubata o dimenticata sia sufficiente per concedere accesso.

Prossimi passi

• Accesso e ruoli: tier, ruoli personalizzati e SSO.
• Connessione con kubectl: il kubeconfig OIDC in pratica.
• Come funziona: il modello hosting × access e il confine di fiducia.

---

Stato del documento

Aspetto	Dettaglio
Stato	attivo
Ultima revisione	2026-07-14