Accesso & il tuo Identity Provider

kubehz ha un'unica identità per tutto: l'account che usi per la dashboard è la stessa identità che kubectl usa quando ti connetti con il kubeconfig OIDC predefinito. Questa pagina spiega da dove viene quella identità, come vengono decisi i permessi e cosa significa "porta il tuo Identity Provider" su kubehz.

Early access

Il control plane hosted è in early access. Tutto ciò che è descritto qui vale per i cluster hosted; un cluster self-hosted mantiene l'autenticazione che hai configurato tu.

Un'identità, un unico posto per i permessi

Due cose separate decidono cosa puoi fare — e conviene tenerle distinte:

• Autenticazione — chi sei. Gestita da kubehz ID (il nostro servizio di identità). Puoi accedere con email + password, una passkey o un provider federato (vedi sotto).
• Autorizzazione — cosa puoi fare. Decisa dalla tua appartenenza al team e dal ruolo (owner, admin, editor, viewer). Il ruolo si traduce in permessi sul cluster: gli admin ottengono cluster-admin, gli editor edit, i viewer view sull'API server del cluster.

La conseguenza importante: il modo in cui accedi non cambia mai ciò che puoi fare. I permessi derivano dall'appartenenza, non dal metodo di accesso — e quando lasci un team, il tuo accesso al cluster finisce con esso, indipendentemente dal provider con cui ti eri autenticato.

Accedere con un provider esterno

kubehz ID supporta l'accesso federato: invece di una password kubehz ti autentichi presso un identity provider esterno e kubehz si fida del risultato.

• L'accesso con GitHub è disponibile oggi per ogni account.
• Al primo accesso federato kubehz crea o collega il tuo account automaticamente (abbinamento sull'email verificata), chiede l'accettazione dei Termini — e da quel momento le sessioni della dashboard e di kubectl passano da quel provider.

Gli utenti federati sono utenti a tutti gli effetti: compaiono nel tuo team, ricevono ruoli come tutti gli altri e il loro kubeconfig OIDC funziona esattamente allo stesso modo.

Collegare l'IdP della tua azienda

Se la tua organizzazione gestisce un proprio identity provider (Entra ID, Okta, Keycloak, Google Workspace — qualsiasi IdP standard OIDC), può essere collegato a kubehz ID come provider federato — lo stesso meccanismo dell'accesso GitHub:

1. Il vostro IdP viene registrato presso kubehz ID come provider esterno.
2. Il team accede tramite il login aziendale (SSO). Gli account vengono creati e collegati al primo accesso, come con GitHub.
3. Appartenenza e ruoli li gestisci in kubehz — chi è nel team e cosa può fare — mentre il vostro IdP possiede l'autenticazione: le vostre policy sulle password, la vostra MFA, il vostro offboarding. Disattiva qualcuno nel vostro IdP e non potrà più accedere a kubehz.

Le connessioni degli IdP aziendali oggi le configuriamo noi, per organizzazione — non c'è ancora un modulo self-service. Se vuoi collegare il tuo IdP, contattaci e lo sistemiamo insieme.

Perché la federazione invece di puntare il cluster al vostro IdP?

L'API server del tuo cluster si fida di kubehz ID come emittente dei token — con un'audience dedicata per cluster e gruppi che codificano i ruoli del tuo team kubehz. È esattamente ciò che rende possibile l'accesso guidato dall'appartenenza: aggiungi o rimuovi un membro nella dashboard e il suo accesso kubectl segue immediatamente, senza oggetti RBAC da mantenere. Un cluster collegato direttamente a un emittente esterno perderebbe proprio questo — per questo una modalità diretta "usa il mio IdP come issuer dell'API server" non è offerta nei piani standard. Se la tua compliance la richiede, parliamone in ottica enterprise.

Cosa significa in pratica

Vuoi	Come
Accedere con GitHub	Disponibile ora — scegli GitHub nella pagina di accesso.
SSO aziendale per dashboard e kubectl	Collega il vostro IdP a kubehz ID (contattaci).
Offboarding tramite il vostro IdP	Funziona: un utente disattivato nel vostro IdP non può avviare una nuova sessione kubehz. Rimuovilo anche dal team kubehz per revocare subito l'accesso in corso.
Gestire i permessi del cluster con i gruppi dell'IdP	Non oggi — i ruoli vivono in kubehz (dashboard → Team). La mappatura gruppi-IdP → ruoli è nella roadmap dell'SSO per organizzazioni.
Il vostro IdP come issuer OIDC diretto del cluster	Non nei piani standard (vedi la nota sopra) — conversazione enterprise.

Note di sicurezza

• Le azioni sensibili (modifiche ai membri, emissione di token, download del kubeconfig admin) richiedono un secondo fattore recente, indipendentemente dal metodo di accesso.
• Il kubeconfig OIDC non contiene mai un segreto durevole — vedi Connessione con kubectl.
• Ogni metodo di accesso confluisce nella stessa identità kubehz, quindi gli eventi di audit nel log del tenant nominano sempre lo stesso utente.

---

Stato del documento

Aspetto	Dettaglio
Stato	early access — funzione attiva
Ultima revisione	2026-07-15