Revisión Kubernetes
Como el CKS necesita del CKA recomiendo que vamos apenas a hacer una breve revisión para refrescar la memoria.
Arquitectura
Es importante hacer una revisión de la arquitectura de Kubernetes sobre un aspecto de seguridad.
Revisa los ítems.
Colocamos contenedores para ejecutar en los nodos, esos contenedores necesitan un motor de contenedor para funcionar. Docker es solamente uno de los container runtime existentes, podemos usar podman, containerd, etc. Otros componentes son necesarios para mantener nuestros contenedores ejecutando (kubelet), agendar nuestros pods (kube-scheduler), verificando la salud de nuestros contenedores (kube-controller-manager), permitir la comunicación entre contenedores (kube-proxy) y muchas otras cosas que son extensiones de kubernetes para tácticas de implantación, replicación, volúmenes, etc.
La comunicación con kubernetes se da a través del api-server, de varias maneras siendo la más común utilizar kubectl que hace el trabajo de traducir lo que queremos para golang y enviar la petición para el api-server con la autenticación necesaria.
El api-server es bastante extensible y reutilizable lo que hace kubernetes tan popular.
El kubelet se ejecuta en cada nodo siendo responsable de ejecutar pods y comunicarse con el api-server para proporcionar informaciones sobre ellos. Pods son un agrupamiento lógico para nosotros, al final lo que tenemos son contenedores ejecutando con una serie de recursos que agrupados para quedar más fácil de entender. El kubelet traduce nuestra intención lógica de pods en contenedores.
En una cloud, cuando ejecutamos Kubernetes como solución, el controller manager también posee otros controllers además de los principales, trabajando para interactuar con los recursos de la cloud.
Tenemos también el CNI que permite la comunicación pod a pod en todo el clúster, creando una superficie de red interna para que cada pod pueda comunicarse con los otros incluso en diferentes nodos. Vale recordar que incluso en diferentes namespaces un pod consigue alcanzar otro pod por defecto.
Certificados
El PKI (Public Key Infrastructure) no es específico de Kubernetes, en realidad es algo muy común en el mundo de Internet siendo uno de los principales recursos de comunicación segura que fue implementado en Kubernetes.
Ítems para revisar:
Resumiendo...
-
CA (Certification Authority) es la raíz que confiará en los certificados. Todo certificado dentro del clúster utilizado por los componentes de kubernetes deben ser firmados por esta entidad. Esto servirá para que cada componente pueda validar unos a otros y tener certeza de que ellos están comunicándose con el identificador correcto.
-
Todos los componentes que son servidores poseen sus certificados de servidor, pero si fueran clientes poseen también certificados de clientes. Podemos observar abajo que el kubelet y el api-server son clientes y servidores al mismo tiempo.
-
Podemos encontrar los certificados dentro de /etc/kubernetes/pki en cada uno de los nodos
- Master
david@cks-master:~$ ls -lh /etc/kubernetes/pki/
total 68
# Podemos observar los certificados clientes del 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
# y el certificado como servidor
-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
# Tenemos una carpeta aquí solo con los certificados del 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.pubLos certificados que no están como archivos los tenemos hardcoded dentro de cada uno de los .conf de los 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
# El certificado del kubelet está en otro 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 a revisar aquí
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
# Aquí tenemos el certificado como cliente y como servidor que el kubelet necesita 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