Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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:
Webhook: Isso habilitará os tokens portadores da API do kubectl como autorização (qualquer token válido será aceito). 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:
O kubelet chama a TokenReview API no servidor API configurado para determinar informações do usuário a partir de tokens bearer
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:
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 permissões 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:
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
| Verbo HTTP | verbo de solicitação |
|---|---|
POST | criar |
GET, HEAD | obter (para recursos individuais), listar (para coleções, incluindo conteúdo completo do objeto), assistir (para assistir a um recurso individual ou coleção de recursos) |
PUT | atualizar |
PATCH | patch |
DELETE | deletar (para recursos individuais), deletecollection (para coleções) |
O recurso que se comunica com a API do Kubelet é sempre nós e o subrecurso é determinado pelo caminho da solicitação recebida:
| API do Kubelet | recurso | subrecurso |
|---|---|---|
/stats/* | nós | stats |
/metrics/* | nós | metrics |
/logs/* | nós | log |
/spec/* | nós | spec |
todos os outros | nós | proxy |
Por exemplo, a seguinte solicitação tentou acessar as informações dos pods do kubelet sem permissão:
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)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
