Fórum Root.cz
Hlavní témata => Server => Téma založeno: czechsys 27. 01. 2026, 10:36:57
-
Cau,
vyvojari si chteji zkusit nejaky kubernetes, tak jsem zatim rozbehl zakladni k3s. Nejdrive jsem zkusil pouzit rootless k3s, ale testovaci kontejnery nespolupracovaly s gpu. Tak jsem se vratil k rootful. No a narazil jsem na to, ze tam vlastne neni zadna sprava uzivatelu. V tuhle chvili by mi na testovani stacilo aspon, kdyby se to dalo omezit na neprivilegovane kontejnery a omezit uzivatele do jejich namespace.
Postup pro funkcni pridani uzivatelu jsem musel nakonec musel hledat po githubech (wtf), defacto via uzivatelske certifikaty. Rancher UI jsem do toho jeste nezkousel nainstalovat. Nez budu zatracet cas ruznymi hokus pokusy, ma nekdo tip na nejakou administracni free variantu, ktera by se dala zkusit, resp. pripadne klidne i pripadne cele reseni (kube + administrace)?
Diky.
-
Osobně mě spíš přijde že k8s cílí na automatizované deploymenty a správu než aby se s tím někdo "klikal" ručně ... Nicméně se třeba mýlím a někdo s něčím přijde ...
-
Co co myslíte těmi uživateli? K čemu chcete vlastně ten kubernet používat? Kubernet je systém pro běh služeb v kontejnerech, o jaké uživatele vám jde? Uživatele pro správu toho kubernetu nebo aplikační uživatele těch služeb??
-
Co co myslíte těmi uživateli? K čemu chcete vlastně ten kubernet používat? Kubernet je systém pro běh služeb v kontejnerech, o jaké uživatele vám jde? Uživatele pro správu toho kubernetu nebo aplikační uživatele těch služeb??
Uzivatele, kteri budou mit moznost pristupu ke kubernetu, s omezenymi pravy - napr. aby skupina uzivatelu mela pristup jen do sveho namespace a nemohla tak pracovat s namespacem jine skupiny.
-
Na redditu jsem zahledl info o Project Capsule - vytvari abstrakci tenant, ktery sdruzuji namespaces, network/security politiky, rbac atd.
-
Co co myslíte těmi uživateli? K čemu chcete vlastně ten kubernet používat? Kubernet je systém pro běh služeb v kontejnerech, o jaké uživatele vám jde? Uživatele pro správu toho kubernetu nebo aplikační uživatele těch služeb??
Uzivatele, kteri budou mit moznost pristupu ke kubernetu, s omezenymi pravy - napr. aby skupina uzivatelu mela pristup jen do sveho namespace a nemohla tak pracovat s namespacem jine skupiny.
My v práci používáme RBAC model https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Detailům nerozumím - není to náplň mojí práce, každopádně máme jako DEVOPS přístup jen na některé namespace a očividně tam je možnost detailně řídit, co kdo může a to i v rámci jednoho namespace (které může role vidět, restartovat atd.).
-
Co co myslíte těmi uživateli? K čemu chcete vlastně ten kubernet používat? Kubernet je systém pro běh služeb v kontejnerech, o jaké uživatele vám jde? Uživatele pro správu toho kubernetu nebo aplikační uživatele těch služeb??
Uzivatele, kteri budou mit moznost pristupu ke kubernetu, s omezenymi pravy - napr. aby skupina uzivatelu mela pristup jen do sveho namespace a nemohla tak pracovat s namespacem jine skupiny.
My v práci používáme RBAC model https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Detailům nerozumím - není to náplň mojí práce, každopádně máme jako DEVOPS přístup jen na některé namespace a očividně tam je možnost detailně řídit, co kdo může a to i v rámci jednoho namespace (které může role vidět, restartovat atd.).
To se používá (téměř) všude, nicméně co jsem pochopil tazatele tak by na to rád klikátko a ne sadu yamlů který musí psát a aplikovat....
-
v rancher UI se daji "naklikat" rbac role aspol, jedna vec jsou prava pro aplikace a druha pro uzivatele (pripojeni pres SSO providera, kubeconfig), vyvojar obvykle pushne kod a ocekava ze mu nejake cicd vytvori kontejner v k3s/k8s s novym kodem
pres k3s a rancher cli to jde cele nainstalovat a nakonfigurovat skriptem misto klikacky
-
Cus, mam naky laby plus minus fcni kde jsou externi uzivatele v ipe(AD), replikuji se do keycloaku, kterej dela identity provdera a proti nemu je oprenej kubernetes api aserver. Uzivatel na zaklade skupiny nebo usernamu v ipe ma konkretni prava v k8s. Jak to muze vypadat je treba zde (hromada playbooku - zajima te hlavne slozka deploy/08_k8s:
https://github.com/veldrane/citadel-core
Funguje to tak ze skupiny a useri ktere, jsou externi maji v ramci kubernetes sveta nejaky prefix, na ktery pak delas clusterrolebiding. Uzivatel se prihlasi pres keycloak, dostane token, ten ma groups claim a aud ktery overuje kube-api server. Na zaklade nej pak user prihlaseny pres kubectl nebo treba pres dashboard vidi objekty na ktere ma prava. Pokud chces vic informaci klidne pis do pm.
-
Chceme to na prvotni odzkouseni. Takze psani nejakych RBAC yaml apod, kdy clovek netusi co a jak, je nesmysl. Proto klikatko do zacatku.
Rancher ted zkousim, ale nejak se mi proti externimu k3s nechce chytnout. A clovek nevi proc...Chyba tady, chyba tamhle, jestli to mezi sebou komunikuje pres LUA, GUA, cert aby z logu pochopil.
Nemam zatim rad kubernetes :D
-
Tak jsem to cele (k3s + rancher + k3s) smazal a zkusil znova, tentokrat bez definovani dualstacku (service/cluster cidr). "Bezi" to ted na default ipv4 subnetech a chytlo se to cele napoprve. Tak zkusim ipv6 only...
-
Tak ako bolo spomenute uz vyssie,K8s samozrejme spravu pouzivatelov ma. Nechapem skor tie otazky ludi,bolo by fajm,keby odpovedal niekto,kto s k8s skutocne robi a pozna ho.
Ako uz bolo sppmenute,zakladom je RBAC,teda presnejsie definovanie roli s opravneniami a ich mapovanie. A k8s dokonca pozna aj pojem User (lepsie je ale Group,vysvetlim neskor preco), len User je "identifikovany" certifikatom a nie credentials ako sme zvyknuti.
Ja na to ale idem inak. Definujem RBAC,ale napojim kubeapi server na oidc keycloak,ty si riesim v realme spravu a login flow pouzivatela (napr. obycajna login obrazovka). K8s poviem,aby z tokenu mapovala v role mapping groupu z tokenu pouzivatela.
A voala,zrazu mam normalne prihlasovanie do k8s clusteru. A tu to nekonci.
Keycloak OIDC a tych istych userov (a dalsie skupiny do ktorych userov mozem zaradit) dalej vyuzivam pre prihlasenie do Grafany,Traefiku,PgAdmina a inych veci,co podporuju oidc a su v ramci operativy nasadene v k8s clusterim.
Je to velmi sikovne a handy riesenie autorizacie v celom k8s clusteri...a hlavne je to velmi jednoduche spravit.
A vsetkymi desiatimi odporucam K3s (len traefik si instalovat sam cez helm chart - aj kvlli dashboardu)
A hlavne nepouzivajte nejake klikatka...definovanie RBAC nie je zlozite a hlavne vie co robi...skutocne su to par riadkove YAML subory.
Mozem na ukazku pastnut,ak bude zaujem.
-
Tak ako bolo spomenute uz vyssie,K8s samozrejme spravu pouzivatelov ma. Nechapem skor tie otazky ludi,bolo by fajm,keby odpovedal niekto,kto s k8s skutocne robi a pozna ho.
Ako uz bolo sppmenute,zakladom je RBAC,teda presnejsie definovanie roli s opravneniami a ich mapovanie. A k8s dokonca pozna aj pojem User (lepsie je ale Group,vysvetlim neskor preco), len User je "identifikovany" certifikatom a nie credentials ako sme zvyknuti.
Ja na to ale idem inak. Definujem RBAC,ale napojim kubeapi server na oidc keycloak,ty si riesim v realme spravu a login flow pouzivatela (napr. obycajna login obrazovka). K8s poviem,aby z tokenu mapovala v role mapping groupu z tokenu pouzivatela.
A voala,zrazu mam normalne prihlasovanie do k8s clusteru. A tu to nekonci.
Keycloak OIDC a tych istych userov (a dalsie skupiny do ktorych userov mozem zaradit) dalej vyuzivam pre prihlasenie do Grafany,Traefiku,PgAdmina a inych veci,co podporuju oidc a su v ramci operativy nasadene v k8s clusterim.
Je to velmi sikovne a handy riesenie autorizacie v celom k8s clusteri...a hlavne je to velmi jednoduche spravit.
A vsetkymi desiatimi odporucam K3s (len traefik si instalovat sam cez helm chart - aj kvlli dashboardu)
A hlavne nepouzivajte nejake klikatka...definovanie RBAC nie je zlozite a hlavne vie co robi...skutocne su to par riadkove YAML subory.
Mozem na ukazku pastnut,ak bude zaujem.
Ukazku urcite pastnete, oidc je tema velmi siroke nicmene nastavit ho dobre (treba client id/aud separation) neni obcas uplne trivka. Tech flow nebo scenaru je taky mrte ;)
Btw neresil jste nekdy na keycloak/k8s neco jako workload federation identity ? Ve zkratce:
Pod ma mountlej sa token vydanej k8s a vy ho pres token exchange na keycloak vymenite za access token k nejakemu resourcu.
Jinak v tech ansible rolich co jsem pastoval je autentizaci kubernetes api a kyecloak sam o sobe je syncnutej s AD/Ipou (tedy keycloak je ro a ad je zdroj pravdy)