Kubelet Authentication & Authorization

Reading time: 4 minutes

Kubelet Authentication

Iz dokumenata:

Po defaultu, zahtevi ka kubelet-ovom HTTPS kraju koji nisu odbijeni od strane drugih konfigurisanih metoda autentifikacije tretiraju se kao anonimni zahtevi, i dodeljuju im se korisničko ime system:anonymous i grupa system:unauthenticated.

3 metode autentifikacije su:

• Anonimna (default): Koristite postavku postavljanjem parametra --anonymous-auth=true ili konfiguracije:

"authentication": {
"anonymous": {
"enabled": true
},

• Webhook: Ovo će omogućiti kubectl API bearer tokene kao autorizaciju (bilo koji validan token će biti validan). Dozvolite to sa:
• osigurajte da je authentication.k8s.io/v1beta1 API grupa omogućena na API serveru
• pokrenite kubelet sa --authentication-token-webhook i --kubeconfig zastavicama ili koristite sledeće podešavanje:

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

• X509 klijentski sertifikati: Omogućavaju autentifikaciju putem X509 klijentskih sertifikata
• pogledajte dokumentaciju o autentifikaciji apiservera za više detalja
• pokrenite kubelet sa --client-ca-file flagom, pružajući CA paket za verifikaciju klijentskih sertifikata. Ili sa konfiguracijom:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet Authorization

Svaki zahtev koji je uspešno autentifikovan (uključujući anonimni zahtev) zatim se autorizuje. Podrazumevani način autorizacije je AlwaysAllow, koji dozvoljava sve zahteve.

Međutim, druga moguća vrednost je webhook (što je ono što ćete najčešće pronaći napolju). Ovaj način će proveriti dozvole autentifikovanog korisnika da dozvoli ili zabrani neku akciju.

Autorizacija putem webhook-a može se konfigurisati koristeći parametar --authorization-mode=Webhook ili putem konfiguracione datoteke sa:

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

Kubelet poziva SubjectAccessReview API na konfigurisanom API serveru da utvrdi da li je svaki zahtev ovlašćen.

Kubelet ovlašćuje API zahteve koristeći isti pristup atributima zahteva kao apiserver:

• Akcija

• Resurs koji komunicira sa Kubelet API je uvek čvorovi, a podresurs se utvrđuje iz putanje dolaznog zahteva:

Na primer, sledeći zahtev je pokušao da pristupi informacijama o podovima kubeleta bez dozvole:

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)

• Dobijamo Zabranjeno, tako da je zahtev prošao proveru autentifikacije. Da nije, dobili bismo samo Neovlašćen poruku.
• Možemo videti korisničko ime (u ovom slučaju iz tokena)
• Proverite kako je resurs bio čvorovi i podresurs proxy (što ima smisla sa prethodnim informacijama)

References

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/