Team e ruoli
Dall'area Team 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 Team, 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 |