Autenticación y Autorización del Kubelet

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Autenticación del Kubelet

From the docss:

Por defecto, las solicitudes al endpoint HTTPS del kubelet que no son rechazadas por otros métodos de autenticación configurados se tratan como solicitudes anónimas, y se les asigna un nombre de usuario system:anonymous y un grupo system:unauthenticated.

Los 3 métodos de autenticación son:

  • Anonymous (por defecto): Usar estableciendo el parámetro --anonymous-auth=true o en la configuración:
"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook: Esto habilitará los kubectl API bearer tokens como autorización (cualquier token válido será válido). Permítalo con:
  • asegúrese de que el grupo de API authentication.k8s.io/v1beta1 esté habilitado en el API server
  • inicie el kubelet con las banderas --authentication-token-webhook y --kubeconfig o use la siguiente configuración:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

El kubelet llama a la TokenReview API en el API server configurado para determinar la información del usuario a partir de bearer tokens

  • X509 client certificates: Permiten autenticarse mediante X509 client certs
  • Consulta la apiserver authentication documentation para más detalles
  • Inicia el kubelet con la bandera --client-ca-file, proporcionando un CA bundle para verificar los certificados de cliente. O con la config:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Autorización del Kubelet

Cualquier solicitud que se autentique con éxito (incluida una solicitud anónima) es entonces autorizada. El modo de autorización por defecto es AlwaysAllow, que permite todas las solicitudes.

Sin embargo, el otro valor posible es webhook (que es lo que encontrarás más comúnmente). Este modo comprobará los permisos del usuario autenticado para permitir o denegar una acción.

Warning

Ten en cuenta que incluso si la autenticación anónima está habilitada el acceso anónimo podría no tener permisos para realizar ninguna acción.

La autorización vía webhook puede configurarse usando el parámetro --authorization-mode=Webhook o mediante el archivo de configuración con:

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

El kubelet llama a la API SubjectAccessReview en el servidor API configurado para determinar si cada solicitud está autorizada.

El kubelet autoriza las solicitudes a la API usando el mismo request attributes approach que el apiserver:

  • Acción
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)
  • The resource talking to the Kubelet api is always nodes and subresource is determined from the incoming request’s path:
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.

For example, the following request tried to access the pods info of kubelet without permission:

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)
  • Recibimos un Forbidden, por lo que la solicitud superó la verificación de autenticación. Si no, solo habríamos recibido un mensaje Unauthorised.
  • Podemos ver el username (en este caso desde el token)
  • Fíjate cómo el resource era nodes y el subresource proxy (lo cual concuerda con la información anterior)

References

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks