înregistrare Logare
Puncte:0
avatar Server

Certificat rădăcină personalizat pentru fișierele kubeconfig

drapel jp
Chris G.

Alergare kubeadm init phase certs apiserver --config kubeadm.yaml

Este posibil să aveți certificate rădăcină multiple/personalizate pentru a fi utilizate pentru grupuri de utilizatori/kubectl/fișiere de configurare?

Întreb pentru că, aș dori să dau acces, pe bază de proiect - și apoi să elimin certificatul rădăcină personalizat - dar să păstrez certificatul rădăcină "original" pentru administratorii speciali kubectl.

Am văzut că puteți folosi tunelul ssh ca primă linie de apărare, pentru a proteja cheia publică a certificatului rădăcină.Dar încă trebuie să distribuiți certificatul public semnat, chiar dacă acesta se află în spatele cheii publice private ssh. Prin urmare, poate că există o modalitate de a folosi tunelul ssh - și de a introduce un certificat personalizat certificatesDir: /etc/kubernetes/pki?

kubeadm.yaml

apiServer:
  extraArgs:
    modul de autorizare: Nod,RBAC
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta1
certificatesDir: /etc/kubernetes/pki

Știu că poți folosi --insecure-skip-tls-verify în fișierul de configurare, dar pare o idee proastă.

53
0 + 0
Puncte:1
avatar Server
drapel in
mdaniel

Este posibil să aveți certificate rădăcină multiple/personalizate pentru a fi utilizate pentru grupuri de utilizatori/kubectl/fișiere de configurare?

Nu, există un singur certificat „rădăcină”, de aceea se numește rădăcină.

Cu toate acestea, x509 este un lanţ de încredere, ceea ce înseamnă că este foarte posibil să emiti CA-uri subordonate sub acea rădăcină, apoi să emiti certificatele de utilizator sub acele CA-uri, alegând să elimini CA-urile subordonate când proiectul se termină, ceea ce va orfani toate acele certificate de frunză. Rețineți că, după cunoștințele mele, schimbarea certificatelor sau a lanțului lor necesită repornirea planului de control, deoarece nu reîncarcă la cald acele fișiere de certificat. Cred că există o problemă cu GitHub, la fel ca toate celelalte 15.000 dintre ele

Cealaltă opțiune, în funcție de nevoile dvs., este să emiteți contracte de închiriere scurte pentru certificatele de utilizator, astfel încât procesul de „revocare” să nu modifice atât de mult lanțul de încredere x509, cât doar eșuează în reemiterea unei acreditări. Este mai aproape de școala de gândire Hashicorp Vault și Let's Encrypt

L-am implementat personal pe cel de-al doilea (folosind Vault), dar cred că primul este posibil deoarece apiserver folosește lanțuri x509 pentru unele dintre componentele sale de autentificare în cluster, așa că nu văd de ce nu ați putea profita în mod similar. a acelui mecanism

Știu că nu este ceea ce ai întrebat, dar utilizarea x509 pentru autentificarea tranzitorie este calea spre ruină, deoarece -- așa cum te confrunți -- ambele părți, emiterea și revocarea, sunt o durere uriașă. Dacă vă este deloc disponibil, Mecanismul de autentificare OIDC este mult mai ușor de raționat și kubectl are mai mult sau mai puțin suport încorporat pentru acesta

0 + 0
drapel jp
Chris G.
Vă mulțumesc pentru răspuns - cred că voi merge cu recomandarea dvs. folosind OpenID (OIDC). Voi încerca să combin acest https://github.com/micahhausler/k8s-oidc-helper cu github https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.