Kubelet Authentication & Authorization

Aprende hacking en AWS desde cero hasta experto con htARTE (Experto en Equipo Rojo de AWS de HackTricks)!

Otras formas de apoyar a HackTricks:

• Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF Consulta los PLANES DE SUSCRIPCIÓN!

• Obtén la merchandising oficial de PEASS & HackTricks

• Descubre La Familia PEASS, nuestra colección exclusiva de NFTs

• Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.

• Comparte tus trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Autenticación de Kubelet

Desde la documentación:

Por defecto, las solicitudes al punto final HTTPS de 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 la configuración estableciendo el parámetro --anonymous-auth=true o la configuración:

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

• Webhook: Esto habilitará los tokens de portador de API de kubectl como autorización (cualquier token válido será válido). Permite esto con:

• asegúrate de que el grupo de API authentication.k8s.io/v1beta1 esté habilitado en el servidor de API

• inicia el kubelet con las banderas --authentication-token-webhook y --kubeconfig o usa la siguiente configuración:

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

El kubelet llama a la API TokenReview en el servidor API configurado para determinar la información del usuario a partir de los tokens de portador.

• Certificados de cliente X509: Permiten autenticarse a través de certificados de cliente X509

• consulte la documentación de autenticación del apiserver para obtener más detalles

• inicie el kubelet con la bandera --client-ca-file, proporcionando un paquete de 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 se autentique correctamente (incluida una solicitud anónima) será luego autorizada. El modo de autorización predeterminado es AlwaysAllow, que permite todas las solicitudes.

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

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 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 API SubjectAccessReview en el servidor API configurado para determinar si cada solicitud está autorizada.

El kubelet autoriza las solicitudes de API utilizando el mismo enfoque de atributos de solicitud que el servidor de API:

• Acción

Verbo HTTP	verbo de solicitud
POST	create
GET, HEAD	get (para recursos individuales), list (para colecciones, incluido el contenido completo del objeto), watch (para observar un recurso individual o una colección de recursos)
PUT	update
PATCH	patch
DELETE	delete (para recursos individuales), deletecollection (para colecciones)

• El recurso que habla con la API del Kubelet es siempre nodos y el subrecurso se determina a partir de la ruta de la solicitud entrante:

API del 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 del 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)

• Obtenemos un Forbidden, por lo que la solicitud pasó la verificación de Autenticación. De lo contrario, solo habríamos recibido un mensaje de No autorizado.

• Podemos ver el nombre de usuario (en este caso del token)

• Verificar que el recurso era nodos y el subrecurso proxy (lo cual tiene sentido con la información previa)

Referencias

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

Aprende a hackear AWS desde cero hasta convertirte en un experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

• Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF ¡Consulta los PLANES DE SUSCRIPCIÓN!

• Obtén productos oficiales de PEASS & HackTricks

• Descubre The PEASS Family, nuestra colección exclusiva de NFTs

• Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.

• Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud.