Kubelet Authentication & Authorization
Kubelet Authentication
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 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 APIinicie 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 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:
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:
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:
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
Last updated