Autenticación y Autorización de Kubelet
Tip
Aprende y practica Hacking en AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP:HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Hacking en Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Apoya a HackTricks
- Revisa los planes de suscripción!
- Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
- Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.
Autenticación de Kubelet
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 de system:anonymous y un grupo de system:unauthenticated.
Los 3 métodos de autenticación son:
- Anónimo (por defecto): Usar configurando el parámetro
--anonymous-auth=trueo la configuración:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: Esto habilitará los tokens portadores de API de kubectl como autorización (cualquier token válido será válido). Permítalo con:
- asegúrese de que el grupo de API
authentication.k8s.io/v1beta1esté habilitado en el servidor API - inicie el kubelet con las banderas
--authentication-token-webhooky--kubeconfigo use la siguiente configuración:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
Note
El kubelet llama a la
TokenReviewAPI en el servidor API configurado para determinar la información del usuario a partir de tokens portadores.
- Certificados de cliente X509: Permiten autenticar a través de certificados de cliente X509.
- consulta la documentación de autenticación del apiserver para más detalles.
- inicia el kubelet con la bandera
--client-ca-file, proporcionando un paquete CA para verificar los certificados de cliente. O con la configuración:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
Autorización de Kubelet
Cualquier solicitud que sea autenticada con éxito (incluida una solicitud anónima) es luego autorizada. El modo de autorización predeterminado es AlwaysAllow, que permite todas las solicitudes.
Sin embargo, el otro valor posible es webhook (que es lo que principalmente encontrarás allí). Este modo verificará 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 ningún permiso para realizar ninguna acción.
La autorización a través de webhook se puede configurar utilizando el parámetro --authorization-mode=Webhook o a través del archivo de configuración con:
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
El kubelet llama a la SubjectAccessReview API en el servidor API configurado para determinar si cada solicitud está autorizada.
El kubelet autoriza las solicitudes API utilizando el mismo enfoque de atributos de solicitud que el apiserver:
- Acción
| Verbo HTTP | verbo de solicitud |
|---|---|
| POST | crear |
| GET, HEAD | obtener (para recursos individuales), listar (para colecciones, incluyendo contenido completo del objeto), observar (para observar un recurso individual o colección de recursos) |
| PUT | actualizar |
| PATCH | parchear |
| DELETE | eliminar (para recursos individuales), eliminarcolección (para colecciones) |
- El recurso que se comunica con la API de Kubelet es siempre nodos y el subrecurso se determina a partir de la ruta de la solicitud entrante:
| API de Kubelet | recurso | subrecurso |
|---|---|---|
| /stats/* | nodos | stats |
| /metrics/* | nodos | metrics |
| /logs/* | nodos | log |
| /spec/* | nodos | spec |
| todos los demás | nodos | proxy |
Por ejemplo, la siguiente solicitud intentó acceder a la información de los pods de kubelet sin permiso:
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 pasó la verificación de autenticación. Si no, solo habríamos recibido un mensaje de
Unauthorised. - Podemos ver el nombre de usuario (en este caso del token)
- Verifique cómo el recurso era nodes y el subrecurso proxy (lo cual tiene sentido con la información anterior)
References
Tip
Aprende y practica Hacking en AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP:HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Hacking en Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Apoya a HackTricks
- Revisa los planes de suscripción!
- Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
- Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.
HackTricks Cloud

