Accesso e ruoli
Dall’area Accesso della dashboard inviti persone al tuo team e decidi cosa può fare ciascuna di esse, sia nella dashboard sia, per i cluster hosted, all’interno di Kubernetes stesso. L’accesso viene concesso in due modi che si combinano: un tier che tutti hanno, più ruoli personalizzati opzionali.
Invitare membri
Invita un membro tramite email. Riceve un invito e accede con kubehz (email + password con due fattori, GitHub, o il tuo SSO; vedi Identità e accesso). Aggiungere o modificare un membro è un’azione sensibile e ti chiede di confermare con un accesso a due fattori fresco.
Solo un owner o un admin del team può gestire membri e ruoli.
I tre tier di accesso
Ogni membro ha esattamente un tier. Su un cluster hosted il tier si mappa direttamente all’accesso Kubernetes integrato:
| Tier | Nel cluster | Ruolo Kubernetes |
|---|---|---|
| Admin | Controllo completo, inclusi segreti e RBAC. | cluster-admin |
| Editor | Legge e scrive la maggior parte delle risorse; nessun ruolo o impostazione a livello di cluster. | edit |
| Viewer | Sola lettura, senza segreti. | view |
Il tier è la base di partenza. Per la maggior parte dei team i tre tier sono tutto ciò che serve.
Ruoli personalizzati
Quando un tier è troppo ampio, definisci un ruolo personalizzato: un accesso più ristretto e sicuro che componi in una matrice di permessi. Le righe sono risorse Kubernetes (pod, log, deployment, le tue CRD, …), le colonne sono azioni (get, list, watch, create, update, delete, …); spunta esattamente ciò che il ruolo può fare. Un ruolo personalizzato viene concesso in aggiunta al tier di un membro: aggiunge sempre e solo accesso, non lo riduce mai.
Modelli. Non devi partire da una griglia vuota. L’editor include punti di partenza revisionati (Log Viewer, Debugger, Deployment Manager e Cluster Observer) che precompilano la matrice; regola le spunte e salva. Il ruolo salvato è sempre la matrice stessa, quindi ciò che vedi è esattamente ciò che il cluster applica.
Le tue risorse. La matrice elenca le risorse Kubernetes standard più tutto ciò che i tuoi cluster hosted servono davvero (incluse le CRD), con un badge che mostra quali cluster conoscono ciascuna risorsa. I cluster possono differire: una regola che nomina una risorsa che qualche cluster non ha è perfettamente valida e lì semplicemente non ha effetto finché la CRD non compare.
Le azioni sensibili (leggere segreti, exec nei pod, impersonazione, escalation RBAC) sono evidenziate nell’editor, così un ruolo troppo ampio è visibile prima di salvarlo.
Ambito. Un ruolo si applica per impostazione predefinita all’intero cluster, oppure puoi limitarlo a namespace nominati (ad esempio, concedi a un collaboratore esterno Debugger solo in staging).
Assegnazione. Crea i ruoli nella sezione Ruoli dell’area Accesso, poi spuntali su un membro (o sul modulo di invito). Definire un ruolo non concede nulla di per sé; assegnarlo sì.
Scegliere i cluster per ogni membro
Sia il tier sia ogni assegnazione di ruolo personalizzato possono essere limitati a cluster hosted selezionati. Per impostazione predefinita l’accesso di un membro vale per tutti i cluster hosted del tuo team; scegli cluster specifici quando qualcuno deve toccarne solo alcuni: ad esempio uno sviluppatore esterno che è Editor solo sul cluster di staging, più Log Viewer in produzione.
La limitazione per cluster riguarda i cluster hosted (dove l’accesso è gestito da kubehz). I cluster self-hosted mantengono l’accesso che configuri tu stesso.
Porta il tuo SSO
Puoi federare il tuo provider di identità OIDC esterno (Okta, Entra, Google Workspace, o qualsiasi provider OIDC) così il tuo team accede con la vostra identità aziendale esistente. kubehz fa da broker per il login ed emette lo stesso accesso: il tuo tier e i tuoi ruoli decidono comunque cosa può fare ciascuna persona. Vedi Identità e accesso.
Come raggiunge il cluster
Il tuo tier e i tuoi ruoli personalizzati diventano group claim nel token che kubehz emette quando accedi. L’API server di un cluster hosted si fida di kubehz come proprio provider di identità e mappa quei gruppi all’RBAC di Kubernetes, limitato al tuo team, così l’accesso di un team non può mai applicarsi al cluster di un altro. Ti connetti con il kubeconfig OIDC; il cluster applica esattamente il tuo ruolo.
Prossimi passi
- Connessione con kubectl: scarica e usa il kubeconfig OIDC.
- Identità e accesso: opzioni di accesso e isolamento per team.
- Dashboard: il resto di ciò che la dashboard ti offre.
Stato del documento
| Aspetto | Dettaglio |
|---|---|
| Stato | attivo |
| Ultima revisione | 2026-07-16 |