Review Kubernetes

Como o CKS precisa do CKA recomendo que vamos apenas fazer um breve review para refrescar a memória.

Arquitetura

É importante fazer um review da arquitetura do Kubernetes sobre um aspecto de segurança.

Reveja os itens.

Colocamos containers para executar nos nodes, esses containers precisam de um motor de container para funcionar. O Docker é somente um dos container runtime existentes, podemos usar o podman, containerd, etc. Outros componentes são necessários para manter nossos container executando (kubelet), agendar os nossos pods (kube-scheduller), verificando a saúde dos nossos containers (kube-controller-manager), permitir a comunicação entre containers (kube-proxy) e muitas outras coisas que são extensões do kubernetes para táticas de implantação, replicação, volumes, etc.

A comunicação com o kubernetes se dá através do api-server, de várias maneiras sendo a mais comum utilizar o kubectl que faz o trabalho de traduzir o que queremos para golang e enviar a requisição para o api-server com a autenticação necessária.

O api-server é bastante extensível e reutilizável o que torna o kubernetes tão popular.

O kubelet é executado em cada node sendo responsável por executar pods e se comunicar com o api-server para fornecer informações sobre eles. Pods são um agrupamento lógico para nós, no final o que temos são containers rodando com uma série de recursos que agrupados para ficar mais fácil de entender. O kubelet traduz nossa intenção lógica de pods em containers.

Em uma cloud, quando executamos o Kubernetes como solução, o controller manager também possui outros controllers além dos principais, trabalhando para interagir com os recursos da cloud.

alt text

Temos também o CNI que permite a comunicação pod a pod em todo o cluster, criando uma superfície de rede interna para que cada pod possa se comunicar com os outros mesmo em diferentes nodes. Vale lembrar que mesmo em diferentes namespaces um pod consegue alcançar outro pod por padrão.

Certificados

O PKI (Public Key Infrastructure) não é específico do Kubernetes, na verdade é algo muito comum no mundo da Internet sendo um dos principais recursos de comunicação segura que foi implementado no Kubernetes.

Itens para revisar:

Resumindo...

CA (Certification Authority) é a raiz que confiará nos certificados. Todo certificado dentro do cluster utilizado pelos componentes do kubernetes devem ser assinado por esta entidade. Isso servirá para que cada componentes possa validar uns aos outros e ter certeza de que eles estão se comunicando com o identificador correto.
Todos os componentes que são servidores possuem seus certificados de server, mas se forem clientes possui também certificados de clientes. Podemos observar abaixo que o kubelet e o api-server são clientes e servidores ao mesmo tempo.

Podemos encontrar os certificados dentro de /etc/kubernetes/pki em cada um dos nodes

Master

david@cks-master:~$ ls -lh /etc/kubernetes/pki/
total 68
# Podemos observer os certificados clientes do api-server
-rw-r--r-- 1 root root 1123 Aug 15 20:41 apiserver-etcd-client.crt
-rw------- 1 root root 1679 Aug 15 20:41 apiserver-etcd-client.key
-rw-r--r-- 1 root root 1176 Aug 15 20:41 apiserver-kubelet-client.crt
-rw------- 1 root root 1675 Aug 15 20:41 apiserver-kubelet-client.key
# e o certificado como server
-rw-r--r-- 1 root root 1285 Aug 15 20:41 apiserver.crt
-rw------- 1 root root 1679 Aug 15 20:41 apiserver.key
-rw-r--r-- 1 root root 1107 Aug 15 20:41 ca.crt
-rw------- 1 root root 1679 Aug 15 20:41 ca.key
# Temos uma pasta aqui só com os certificados do ETCD server
drwxr-xr-x 2 root root 4096 Aug 15 20:41 etcd
-rw-r--r-- 1 root root 1123 Aug 15 20:41 front-proxy-ca.crt
-rw------- 1 root root 1675 Aug 15 20:41 front-proxy-ca.key
-rw-r--r-- 1 root root 1119 Aug 15 20:41 front-proxy-client.crt
-rw------- 1 root root 1679 Aug 15 20:41 front-proxy-client.key
-rw------- 1 root root 1679 Aug 15 20:41 sa.key
-rw------- 1 root root  451 Aug 15 20:41 sa.pub

Os certificados que não estão como arquivos temos eles hardcoded dentro de cada um dos .conf dos componentes.

david@cks-master:~$ ls -la /etc/kubernetes/*.conf
-rw------- 1 root root 5650 Aug 15 20:41 /etc/kubernetes/admin.conf
-rw------- 1 root root 5674 Aug 15 20:41 /etc/kubernetes/controller-manager.conf
-rw------- 1 root root 1982 Aug 15 20:41 /etc/kubernetes/kubelet.conf
-rw------- 1 root root 5622 Aug 15 20:41 /etc/kubernetes/scheduler.conf
-rw------- 1 root root 5678 Aug 15 20:41 /etc/kubernetes/super-admin.conf

Worker

root@cks-worker:/etc/kubernetes# ls -lh /etc/kubernetes/pki/
total 4.0K
-rw-r--r-- 1 root root 1.1K Aug 15 20:43 ca.crt
# O certificado do kubelet fica em outro lugar
root@cks-worker:/etc/kubernetes# cat kubelet.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCVENDQWUyZ0F3SUJBZ0lJZnk5cXZHM0ozdUV3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TkRBNE1UVXlNRE0yTURKYUZ3MHpOREE0TVRNeU1EUXhNREphTUJVeApFekFSQmdOVkJBTVRDbXQxWW1WeWJtVjBaWE13Z2dFaU1BMEdDU3FHU0li...
    0K
    server: https://10.128.0.5:6443
  name: default-cluster
contexts:
- context:
    cluster: default-cluster
    namespace: default
    user: default-auth
  name: default-context
current-context: default-context
kind: Config
preferences: {}
users:
- name: default-auth
  user:
    # Vamos varrer aqui
    client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
    client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

# Aqui temos o certificado como cliente e como server que o kubelet precisar para funcionar.
root@cks-worker:/etc/kubernetes# ls -lh /var/lib/kubelet/pki/
total 12K
-rw------- 1 root root 1.1K Aug 15 20:43 kubelet-client-2024-08-15-20-43-23.pem
lrwxrwxrwx 1 root root   59 Aug 15 20:43 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2024-08-15-20-43-23.pem
-rw-r--r-- 1 root root 2.3K Aug 15 20:43 kubelet.crt
-rw------- 1 root root 1.7K Aug 15 20:43 kubelet.key

Arquitetura​

Certificados​

Arquitetura

Certificados