Authentication
Quem são os possíveis tipos de usuários que temos no cluster?
- Admins: São aqueles que acessam o cluster para tarefas mais administrativas. Geralmente possuem acesso completo ao cluster.
- Developers: Acessam o cluster para testar ou implantar aplicações.
- End Users: Acessam as aplicações que estão rodando no cluster.
- Bots: São outras aplicações de terceiros que acessam as aplicações no cluster para fins de integração.
É necessário proteger a comunicação entre os componentes internos e o acesso desses possíveis usuários por meio de mecanismos de autenticação e autorização.
Os usuários das aplicações são gerenciados pelas próprias aplicações então vamos removê-los deste cenário.
Então ficamos com dois tipos de usuário, que são os
- Humanos:
- admins
- developers
- Aplicações (serviços, processos, aplicações, etc)
Para as aplicações usamos os ServiceAccounts do Kubernetes, mas não podemos criar um usuário com um comando kubectl create user david
. É necessário uma fonte externa que validará um usuário e permitirá a ele o uso de alguma role dentro do cluster. Poderíamos usar por exemplo um LDAP.
Todo acesso do usuário é gerenciado pelo kube-apiserver, acessando via kubectl ou via api não importa.
O kube-apiserver autentica o usuário antes de processar o pedido.
Mas como o kube-apiserver faz essa autenticação?
- Arquivo de password estático.
- Arquivo de token estático.
- Certificados
- Serviços de identidade como LDAP, Kerberos, etc
Password e Tokens Estáticos
Esse método foi DESCONTINUADO
no 1.19 e nem cairá na prova, mas vale para uma primeira introdução sobre o assunto.
É necessário criar um arquivo csv com as colunas password, username e userid. A última coluna de groups é opcional
Por exemplo user-details.csv com o conteúdo abaixo.
abcd123,david,u0001,group1
asdf4321,joao,u0002,group1
4321qwer,maria,u0003,grou2
Também é possível criar o arquivo de token, por exemplo criando um arquivo token-details.csv
Kuandfa1AD123ava234adavc12,david,u0010,group1
dDAar1435ASAdvcra32314dcca,joao,u0020,group1
Adafa13279DiiyrteuYUTR345c,maria,u0030,grou2
O kube-apiserver precisa subir sabendo onde estes arquivos se encontram passando a flag
--basic-auth-file=user-details.csv
e--token-auth-file=token-details.csv
. Não é necessário passar ambos, pois são apenas métodos diferentes de autenticação.
Se estiver rodando como um serviço deveríamos passar assim. É necessário reiniciar o serviço para fazer efeito.
Se estivermos rodando o kube-apiserver por meio de pods, por exemplo lançado pelo kubeadm, é necessário modificar o pod do kube-apiserver.yaml. O kubeadm tool automaticamente reiniciará o kube-apiserver com as novas modificações.
Para utilizar o kubectl com autenticação de usuário e senha precisamos passar o usuário e senha.
kubectl get pods --username=david --password=abcd123
#via api password e senha (david)
curl -v -k https://master-node-ip:6443/api/v1/pods -u "david:abcd123"
#via api token (joao)
curl -v -k https://master-node-ip:6443/api/v1/pods --header "Authorization: Bearer: dDAar1435ASAdvcra32314dcca"
Ou no nosso .kube/config o usuário para o cluster seria assim, então não precisaríamos passar o usuário e senha a cada comando.
clusters:
- name: meu-cluster
cluster:
server: https://endereco-do-cluster
...
contexts:
- name: joao-token
context:
cluster: meu-cluster
user: joao
- name: david-password
context:
cluster: meu-cluster
user: david
current-context: joao-token
users:
- name: david
user:
auth-provider:
name: "basic-auth"
config:
username: david
password: abcd123
- name: joao
user:
auth-provider:
name: "token"
config:
token: dDAar1435ASAdvcra32314dcca
Esses métodos não são recomendados e são considerados inseguros, principalmente com senhas e tokens muito fáceis de serem utilizados em ataques de força bruta. Armazenar senhas e tokens em arquivos nunca foi uma opção segura.
Deve ser considerado passar path onde os arquivos foram criados.