Prijava & tvoj lastni ponudnik identitete

kubehz ima eno identiteto za vse: račun, ki ga uporabljaš za nadzorno ploščo, je ista identiteta, ki jo kubectl uporabi, ko se povežeš s privzetim OIDC kubeconfig. Ta stran pojasnjuje, od kod ta identiteta prihaja, kako se odločajo dovoljenja in kaj pri kubehz pomeni „pripelji svojega ponudnika identitete".

Zgodnji dostop

Gostovana kontrolna ravnina je v zgodnjem dostopu. Vse na tej strani velja za gostovane clustre; samostojno gostovani cluster obdrži avtentikacijo, ki si jo nastavil sam.

Ena identiteta, eno mesto za dovoljenja

Kaj smeš početi, odločata dve ločeni stvari — in ju je vredno držati narazen:

• Avtentikacija — kdo si. Zanjo skrbi kubehz ID (naša identitetna storitev). Prijaviš se lahko z e-pošto + geslom, s passkeyem ali prek federiranega ponudnika (glej spodaj).
• Avtorizacija — kaj smeš. O tem odločata tvoje članstvo v ekipi in vloga (owner, admin, editor, viewer). Vloga se preslika v dovoljenja na clustru: admini dobijo cluster-admin, editorji edit, viewerji view na API-strežniku clustra.

Pomembna posledica: način prijave nikoli ne spremeni tega, kaj smeš. Dovoljenja izhajajo iz članstva, ne iz načina prijave — in ko zapustiš ekipo, se tvoj dostop do clustra konča, ne glede na to, prek katerega ponudnika si se prijavljal.

Prijava prek zunanjega ponudnika

kubehz ID podpira federirano prijavo: namesto kubehz gesla se avtenticiraš pri zunanjem ponudniku identitete in kubehz rezultatu zaupa.

• Prijava z GitHubom je danes na voljo za vsak račun.
• Ob prvi federirani prijavi kubehz tvoj račun samodejno ustvari ali poveže (ujemanje po preverjeni e-pošti), zahteva sprejem pogojev — od takrat naprej pa seje nadzorne plošče in kubectl tečejo prek tega ponudnika.

Federirani uporabniki so polnopravni uporabniki: pojavijo se v tvoji ekipi, dobijo vloge kot vsi drugi in njihov OIDC kubeconfig deluje popolnoma enako.

Priklop IdP-ja tvojega podjetja

Če tvoja organizacija upravlja lasten ponudnik identitete (Entra ID, Okta, Keycloak, Google Workspace — kateri koli standardni OIDC IdP), ga je mogoče povezati s kubehz ID kot federiranega ponudnika — po istem mehanizmu kot prijavo z GitHubom:

1. Vaš IdP se registrira pri kubehz ID kot zunanji ponudnik.
2. Vaša ekipa se prijavlja prek podjetniške prijave (SSO). Računi se ustvarijo in povežejo ob prvi prijavi, tako kot pri GitHubu.
3. Članstvo in vloge upravljaš v kubehz — kdo je v ekipi in kaj sme —, medtem ko vaš IdP poseduje avtentikacijo: vaše politike gesel, vaš MFA, vaš offboarding. Onemogoči nekoga v vašem IdP in v kubehz se ne more več prijaviti.

Povezave podjetniških IdP-jev trenutno nastavljamo mi, za vsako organizacijo posebej — samopostrežnega obrazca še ni. Če želiš povezati svoj IdP, nam piši in ga uredimo skupaj.

Zakaj federacija, ne pa neposredna vezava clustra na vaš IdP?

API-strežnik tvojega clustra zaupa kubehz ID kot izdajatelju žetonov — z namensko avdienco za vsak cluster in skupinami, ki kodirajo tvoje vloge v kubehz ekipi. Prav to omogoča dostop, voden s članstvom: dodaj ali odstrani člana na nadzorni plošči in njegov kubectl dostop takoj sledi, brez RBAC objektov, ki bi jih moral vzdrževati. Cluster, neposredno vezan na zunanjega izdajatelja, bi izgubil prav to — zato načina „uporabi moj IdP kot izdajatelja API-strežnika" v standardnih paketih namenoma ne ponujamo. Če tvoja skladnost to zahteva, se pogovorimo o enterprise dogovoru.

Kaj to pomeni v praksi

Želiš	Kako
Prijavo z GitHubom	Na voljo zdaj — na prijavni strani izberi GitHub.
Podjetniški SSO za nadzorno ploščo in kubectl	Poveži vaš IdP s kubehz ID (piši nam).
Offboarding prek vašega IdP	Deluje: uporabnik, onemogočen v vašem IdP, ne more začeti nove kubehz seje. Odstrani ga še iz kubehz ekipe, da mu takoj odvzameš tekoči dostop.
Upravljanje dovoljenj clustra prek IdP skupin	Danes ne — vloge živijo v kubehz (nadzorna plošča → Ekipa). Preslikava IdP skupin v vloge je na načrtu za organizacijski SSO.
Vaš IdP kot neposredni OIDC izdajatelj clustra	Ne v standardnih paketih (glej opombo zgoraj) — enterprise pogovor.

Varnostne opombe

• Občutljiva dejanja (spremembe članov, izdaja žetonov, prenos admin kubeconfiga) zahtevajo svež drugi faktor, ne glede na način prijave.
• OIDC kubeconfig nikoli ne vsebuje trajne skrivnosti — glej Povezovanje s kubectl.
• Vsak način prijave se konča v isti kubehz identiteti, zato revizijski dogodki v dnevniku najemnika vedno imenujejo istega uporabnika.

---

Status dokumenta

Vidik	Podrobnost
Stanje	zgodnji dostop — funkcija v živo
Zadnji pregled	2026-07-15