Kubelet Authentication & Authorization

Reading time: 5 minutes

Kubelet Authentication

Do docs:

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 definindo o parâmetro --anonymous-auth=true ou a configuração:

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

• Webhook: Isso irá habilitar os tokens bearer da API kubectl como autorização (qualquer token válido será aceito). Permita com:
• certifique-se de que o grupo de API authentication.k8s.io/v1beta1 está 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
},

• 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 bundle 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.

A autorização via webhook pode ser configurada usando o param --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 a partir do 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 Forbidden, então a solicitação passou na verificação de Autenticação. Se não, teríamos recebido apenas uma mensagem Unauthorised.
• Podemos ver o nome de usuário (neste caso, do token)
• Verifique como o recurso era nodes e o subrecurso proxy (o que faz sentido com as informações anteriores)

Referências

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