Português - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubelet Authentication & Authorization

Support HackTricks

Kubelet Authentication

Da documentação:

Por padrão, as solicitações para o endpoint HTTPS do kubelet que não são rejeitadas por outros métodos de autenticação configurados são tratadas como solicitações anônimas, e recebem um nome de usuário de system:anonymous e um grupo de system:unauthenticated.

Os 3 métodos de autenticação são:

  • Anônimo (padrão): Use a configuração definindo o parâmetro --anonymous-auth=true ou a configuração:

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

  • Webhook: Isso habilitará os tokens de portador da API do kubectl como autorização (qualquer token válido será válido). Permita com:

  • assegure-se de que o grupo de API authentication.k8s.io/v1beta1 esteja habilitado no servidor da API

  • inicie o kubelet com as flags --authentication-token-webhook e --kubeconfig ou use a seguinte configuração:

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

O kubelet chama a TokenReview API no servidor API configurado para determinar informações do usuário a partir de tokens de portador

  • Certificados de cliente X509: Permitem autenticar via certificados de cliente X509

  • veja a documentação de autenticação do apiserver para mais detalhes

  • inicie o kubelet com a flag --client-ca-file, fornecendo um pacote CA para verificar os certificados de cliente. Ou com a configuração:

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

Kubelet Authorization

Qualquer solicitação que seja autenticada com sucesso (incluindo uma solicitação anônima) é então autorizada. O modo de autorização padrão é AlwaysAllow, que permite todas as solicitações.

No entanto, o outro valor possível é webhook (que é o que você encontrará principalmente por aí). Este modo verificará as permissões do usuário autenticado para permitir ou negar uma ação.

Observe que mesmo se a autenticação anônima estiver habilitada, o acesso anônimo pode não ter nenhuma permissão para realizar qualquer ação.

A autorização via webhook pode ser configurada usando o parâmetro --authorization-mode=Webhook ou via o arquivo de configuração com:

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

O kubelet chama a SubjectAccessReview API no servidor API configurado para determinar se cada solicitação está autorizada.

O kubelet autoriza solicitações de API usando a mesma abordagem de atributos de solicitação que o apiserver:

  • Ação

  • O recurso que se comunica com a API do Kubelet é sempre nós e o subrecurso é determinado pelo caminho da solicitação recebida:

Por exemplo, a seguinte solicitação tentou acessar as informações dos pods do kubelet sem permissão:

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)

  • Recebemos um Proibido, então a solicitação passou na verificação de Autenticação. Se não, teríamos recebido apenas uma mensagem de Não Autorizado.

  • Podemos ver o nome de usuário (neste caso, do token)

  • Verifique como o recurso era nós e o sub-recurso proxy (o que faz sentido com as informações anteriores)

Referências

Support HackTricks
PreviousPentesting Kubernetes ServicesNextExposing Services in Kubernetes

Last updated