Kubelet Kimlik Doğrulama & Yetkilendirme

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Kubelet Authentication

Dokümanlardan:

Varsayılan olarak, diğer yapılandırılmış kimlik doğrulama yöntemleri tarafından reddedilmeyen kubelet’in HTTPS uç noktasına yapılan istekler anonim istekler olarak muamele görür ve kullanıcı adı system:anonymous ve grup system:unauthenticated verilir.

Kimlik doğrulama için 3 yöntem şunlardır:

  • Anonymous (varsayılan): Parametreyi --anonymous-auth=true olarak ayarlayın veya yapılandırmayı kullanın:
"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook: Bu, kubectl API bearer tokens’ı yetkilendirme için etkinleştirecek (geçerli herhangi bir token geçerli sayılacaktır). Bunu şu şekilde etkinleştirin:
  • API sunucusunda authentication.k8s.io/v1beta1 API grubunun etkin olduğundan emin olun
  • kubelet’i --authentication-token-webhook ve --kubeconfig bayraklarıyla başlatın veya aşağıdaki ayarı kullanın:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

kubelet, yapılandırılmış API server üzerinde TokenReview API çağrısı yapar ve bearer token’lerden kullanıcı bilgilerini belirler

  • X509 client certificates: X509 client certs ile kimlik doğrulamasına izin verir
  • Daha fazla ayrıntı için apiserver authentication documentation
  • kubelet’i --client-ca-file bayrağı ile başlatın; istemci sertifikalarını doğrulamak için bir CA paketi sağlayın. Veya yapılandırma ile:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet Yetkilendirmesi

Başarıyla kimlik doğrulanan (anonim bir istek dahil) her istek daha sonra yetkilendirilir. Varsayılan yetkilendirme modu AlwaysAllow’dır; bu da tüm isteklere izin verir.

Ancak diğer olası değer webhook (dışarıda çoğunlukla bununla karşılaşacaksınız). Bu mod, bir eyleme izin verip vermemeye karar vermek için kimliği doğrulanmış kullanıcının izinlerini denetler.

Warning

Şunu unutmayın: anonim kimlik doğrulama etkin olsa bile, anonim erişimin herhangi bir eylemi gerçekleştirmek için herhangi bir izni olmayabilir.

Webhook aracılığıyla yetkilendirme, parametre --authorization-mode=Webhook kullanılarak veya yapılandırma dosyasıyla şu şekilde yapılandırılabilir:

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

Kubelet, yapılandırılmış API sunucusunda SubjectAccessReview API’sini çağırarak her isteğin yetkilendirilmiş olup olmadığını belirler.

Kubelet, apiserver ile aynı request attributes yaklaşımını kullanarak API isteklerini yetkilendirir:

  • Eylem
HTTP verbrequest verb
POSTcreate
GET, HEADget (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUTupdate
PATCHpatch
DELETEdelete (for individual resources), deletecollection (for collections)
  • Kubelet API ile konuşan resource her zaman nodes’tır ve subresource, gelen isteğin yolundan belirlenir:
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

WebSocket-based /exec, /run, /attach, and /portforward fall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with only nodes/proxy GET can still exec containers if it connects directly to https://<node_ip>:10250 over WebSockets. See the nodes/proxy GET -> Kubelet /exec verb confusion abuse for details.

Örneğin, aşağıdaki istek kubelet’in pod bilgilerine izin olmadan erişmeye çalıştı:

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)
  • Bir Forbidden aldık; bu, isteğin kimlik doğrulama kontrolünü geçtiğini gösteriyor. Aksi takdirde yalnızca Unauthorised mesajı alırdık.
  • username’ı görebiliyoruz (bu durumda token’dan).
  • resource’un nodes ve subresource’un proxy olduğunu kontrol edin (bu, önceki bilgilerle mantıklı).

Referanslar

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin