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 — federa un provider OIDC esterno (Okta, Entra, Google Workspace, …) così il tuo team usa la vostra identità aziendale esistente. Vedi Team 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.

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

• Team 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