Skip to main content

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.

Alt text

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

Alt text

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.

Alt text

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.

Alt text

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.