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.

Hosted

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 da due impostazioni della tua appartenenza. Il tuo ruolo nel team (owner, admin, member) dice cosa puoi fare nella dashboard: owner e admin gestiscono membri e ruoli, i member usano ciò che è stato loro assegnato. Il tuo tier di accesso (admin, editor, viewer o none) si traduce in permessi sul cluster: gli admin ottengono cluster-admin, gli editor edit, i viewer view sull’API server del cluster. Vedi Accesso e ruoli per il modello.

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. 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. 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.

Un owner o un admin lo aggiunge dalla dashboard: Accesso → Membri → Provider di identità (federazione SSO). Serve una verifica MFA recente. Se la federazione SSO non è ancora abilitata per la tua organizzazione, il modulo te lo dice; è allora che vale il percorso assistito qui sotto.

Tieni pronti (provider OIDC):

• Nome visualizzato: come si chiama il provider nella schermata di accesso.
• URL dell’issuer: l’issuer https del provider (il documento di discovery sta su /.well-known/openid-configuration sotto quell’issuer).
• Client ID e client secret: da un’applicazione che registri presso il tuo provider per kubehz.
• Scope: opzionali; lasciarli vuoti usa i valori predefiniti.

SAML è supportato nella stessa sezione se il tuo provider non parla OIDC.

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 → Accesso). 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.

Prossimi passi

• Connessione con kubectl: usa l’identità appena configurata per ottenere un kubeconfig che non contiene alcun segreto durevole.
• Applicazioni (gate SSO): metti lo stesso sign-in davanti a un servizio nel tuo cluster, senza che il servizio supporti OIDC.
• Accesso e ruoli: i ruoli vivono in kubehz, quindi è lì che decidi cosa può fare ogni persona autenticata.

---

Stato del documento

Aspetto	Dettaglio
Stato	live: accesso social attivo; IdP proprio su richiesta
Ultima revisione	2026-07-15