Infraestructura on Adur

Guía de bastionado de seguridad en Kubernetes

Sun, 03 Nov 2024 00:00:00 +0000

Superficie de Ataque de Kubernetes

Kubernetes por defecto no es seguro. El cluster expone múltiples vectores de ataque que necesitan atención sistemática:

API Server - Punto de control central; acceso no autorizado = compromiso total
etcd - Almacena todo el estado incluyendo secretos en base64 (sin cifrar por defecto)
Kubelet - Agente del nodo; API expuesto filtra info de pods y permite ejecutar comandos
Container runtime - Vulnerabilidades de escape dan acceso al host
Red - Los pods se comunican libremente con otros por defecto
Cadena de suministro - Imágenes maliciosas o vulnerables introducen backdoors

Esta guía cubre las medidas clave organizadas por vector de ataque.

Bastionado del API Server

El API server es el componente más crítico. Asegúralo primero:

Deshabilitar autenticación anónima: establece --anonymous-auth=false
Habilitar audit logging: rastrea quién hizo qué (cubierto en detalle más adelante)
Restringir acceso: usa reglas de firewall o security groups para limitar quien puede alcanzar el API server
Habilitar admission controllers: PodSecurity, NodeRestriction, ResourceQuota y LimitRanger deben estar activos
Usar OIDC para autenticación: integra con tu proveedor de identidad en lugar de depender de certificados de cliente

1
2


# Comprobar los flags actuales del API server (en clusters kubeadm)
kubectl -n kube-system get pod kube-apiserver-<node> -o jsonpath='{.spec.containers[0].command}' | tr ',' '\n'

Buenas Prácticas de RBAC

RBAC es tu mecanismo de autorización principal. Aplica el mínimo privilegio rigurosamente.

Reglas Clave

Nunca usar cluster-admin para workloads – otorga acceso ilimitado
Usar Roles (con namespace) sobre ClusterRoles siempre que sea posible
Evitar wildcards en especificaciones de recursos o verbos
Vincular a ServiceAccounts, no a usuarios para workloads automatizados
Revisar bindings regularmente – los permisos se acumulan con el tiempo

Ejemplo: Rol Restringido para Despliegues

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: production
 name: deployment-manager
rules:
 # Puede gestionar deployments
 - apiGroups: ["apps"]
 resources: ["deployments"]
 verbs: ["get", "list", "watch", "create", "update", "patch"]
 # Puede ver pods y logs
 - apiGroups: [""]
 resources: ["pods", "pods/log"]
 verbs: ["get", "list", "watch"]
 # Puede ver services
 - apiGroups: [""]
 resources: ["services"]
 verbs: ["get", "list", "watch"]
 # Explicitamente SIN acceso a secrets, escritura de configmaps, o exec
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 namespace: production
 name: deployment-manager-binding
subjects:
 - kind: ServiceAccount
 name: ci-deployer
 namespace: production
roleRef:
 kind: Role
 name: deployment-manager
 apiGroup: rbac.authorization.k8s.io

Audita el RBAC existente con:

1
2
3
4
5
6


# Listar todos los bindings de cluster-admin
kubectl get clusterrolebindings -o json | \
 jq '.items[] | select(.roleRef.name == "cluster-admin") | {name: .metadata.name, subjects: .subjects}'

# Comprobar que puede hacer una service account especifica
kubectl auth can-i --list --as=system:serviceaccount:production:ci-deployer -n production

Pod Security Standards

Los PSS (Pod Security Standards) de Kubernetes definen tres niveles de restricciones. Desde 1.25, Pod Security Admission (PSA) es el mecanismo integrado (reemplaza PodSecurityPolicy).

Los Tres Niveles

Nivel	Descripción	Caso de Uso
Privileged	Sin restricciones	Workloads de sistema (CNI, drivers de almacenamiento)
Baseline	Bloquea escalaciones de privilegios conocidas	Workloads generales
Restricted	Bastionado máximo	Workloads sensibles, clusters multi-tenant

Aplicacion de Pod Security Standards

Aplica los estandares a nivel de namespace usando labels:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


apiVersion: v1
kind: Namespace
metadata:
 name: production
 labels:
 # Enforce restricted: rechazar pods que violen
 pod-security.kubernetes.io/enforce: restricted
 pod-security.kubernetes.io/enforce-version: latest
 # Warn en violaciones baseline (muestra aviso pero permite)
 pod-security.kubernetes.io/warn: restricted
 pod-security.kubernetes.io/warn-version: latest
 # Audit: registrar violaciones
 pod-security.kubernetes.io/audit: restricted
 pod-security.kubernetes.io/audit-version: latest

Ejemplo de Pod Conforme

Un pod que pasa el nivel restricted:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


apiVersion: v1
kind: Pod
metadata:
 name: secure-app
 namespace: production
spec:
 securityContext:
 runAsNonRoot: true
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: myregistry.com/app:v1.2.3@sha256:abc123...
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 runAsUser: 1000
 runAsGroup: 1000
 capabilities:
 drop:
 - ALL
 resources:
 limits:
 memory: "256Mi"
 cpu: "500m"
 requests:
 memory: "128Mi"
 cpu: "250m"

Configuraciones de seguridad clave que siempre incluir:

runAsNonRoot: true – nunca ejecutar contenedores como root
readOnlyRootFilesystem: true – prevenir modificaciones del sistema de archivos
allowPrivilegeEscalation: false – bloquear setuid/setgid
capabilities.drop: ["ALL"] – eliminar todas las capabilities de Linux
seccompProfile.type: RuntimeDefault – aplicar perfil seccomp por defecto
Siempre especificar limites de recursos para prevenir DoS

NetworkPolicies

Por defecto, todos los pods pueden comunicarse con todos los demas pods en un cluster. Las NetworkPolicies restringen esto a solo el trafico necesario.

Denegacion Total por Defecto

Comienza cada namespace con una política de denegacion por defecto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-all
 namespace: production
spec:
 podSelector: {}
 policyTypes:
 - Ingress
 - Egress

Permitir Trafico Especifico

Luego permite explicitamente solo lo que se necesita:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-api-to-db
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: database
 policyTypes:
 - Ingress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: api-server
 ports:
 - protocol: TCP
 port: 5432
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-server-egress
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: api-server
 policyTypes:
 - Egress
 egress:
 # Permitir resolucion DNS
 - to: []
 ports:
 - protocol: UDP
 port: 53
 - protocol: TCP
 port: 53
 # Permitir conexion a la base de datos
 - to:
 - podSelector:
 matchLabels:
 app: database
 ports:
 - protocol: TCP
 port: 5432
 # Permitir HTTPS externo
 - to:
 - ipBlock:
 cidr: 0.0.0.0/0
 except:
 - 10.0.0.0/8
 - 172.16.0.0/12
 - 192.168.0.0/16
 ports:
 - protocol: TCP
 port: 443

Nota: las NetworkPolicies requieren un plugin CNI que las soporte (Calico, Cilium, Weave Net). El kubenet por defecto no aplica NetworkPolicies.

Gestion de Secretos

Los Secrets de Kubernetes estan codificados en base64, no cifrados. Cualquiera con acceso de lectura a Secrets en un namespace puede decodificarlos trivialmente. La gestion adecuada de secretos requiere herramientas adicionales.

Opcion 1: Sealed Secrets

Sealed Secrets (de Bitnami) cifra secretos del lado del cliente para que puedan almacenarse de forma segura en Git:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Instalar CLI kubeseal
# Cifrar un secreto
kubectl create secret generic db-creds \
 --from-literal=password=supersecret \
 --dry-run=client -o yaml | \
 kubeseal --format yaml > sealed-db-creds.yaml

# El sealed secret puede commitearse en Git
# Solo el controlador del cluster puede descifrarlo
kubectl apply -f sealed-db-creds.yaml

Opcion 2: External Secrets Operator

External Secrets Operator sincroniza secretos desde proveedores externos (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) en Kubernetes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
 name: db-credentials
 namespace: production
spec:
 refreshInterval: 1h
 secretStoreRef:
 name: aws-secrets-manager
 kind: ClusterSecretStore
 target:
 name: db-credentials
 data:
 - secretKey: password
 remoteRef:
 key: production/database
 property: password

Habilitar Cifrado en Reposo

Asegurate de que etcd cifre los secretos en reposo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
 - resources:
 - secrets
 providers:
 - aescbc:
 keys:
 - name: key1
 secret: <base64-encoded-32-byte-key>
 - identity: {}

Audit Logging

Los audit logs de Kubernetes registran cada peticion al API server, proporcionando un rastro detallado de quien hizo que y cuando.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
 # Registrar todas las peticiones a secrets a nivel Metadata
 - level: Metadata
 resources:
 - group: ""
 resources: ["secrets"]
 # Registrar pod exec/attach a nivel RequestResponse
 - level: RequestResponse
 resources:
 - group: ""
 resources: ["pods/exec", "pods/attach"]
 # Registrar todas las operaciones de escritura a nivel Request
 - level: Request
 verbs: ["create", "update", "patch", "delete"]
 # Registrar todo lo demas a nivel Metadata
 - level: Metadata
 omitStages:
 - RequestReceived

Habilita en el API server con:

1
2
3
4
5


--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100

Envia los audit logs a tu SIEM o sistema de agregacion de logs (Loki, Elasticsearch) para analisis y alertas.

Politicas de Imagenes con Kyverno

Kyverno es un motor de políticas para Kubernetes que valida, muta y genera recursos basándose en políticas. Es mas sencillo de adoptar que OPA Gatekeeper porque las políticas se escriben como recursos de Kubernetes en lugar de Rego.

Requerir Digest de Imagen y Registro de Confianza

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: require-image-digest
spec:
 validationFailureAction: Enforce
 rules:
 - name: require-digest
 match:
 any:
 - resources:
 kinds:
 - Pod
 validate:
 message: "Las imágenes deben usar un digest (@sha256:...) en lugar de un tag"
 pattern:
 spec:
 containers:
 - image: "*@sha256:*"
 - name: require-trusted-registry
 match:
 any:
 - resources:
 kinds:
 - Pod
 validate:
 message: "Las imágenes deben provenir del registro de confianza"
 pattern:
 spec:
 containers:
 - image: "myregistry.com/*"

Esta política asegura que solo se desplieguen imágenes de tu registro de confianza con digests fijados, previniendo tanto ataques a la cadena de suministro como problemas de mutabilidad de tags.

CIS Kubernetes Benchmark

El CIS Kubernetes Benchmark proporciona un conjunto completo de recomendaciones de seguridad. Ejecuta comprobaciones automatizadas con kube-bench:

1
2
3
4
5


# Ejecutar comprobaciones del benchmark CIS
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Ver resultados
kubectl logs job/kube-bench

Aborda los hallazgos por prioridad: elementos criticos primero (autenticacion del API server, cifrado de etcd), luego altos (RBAC, network policies), despues medios y bajos.

Checklist de Bastionado

Usa esta checklist como punto de partida para asegurar tu cluster:

API server: autenticacion anonima deshabilitada, audit logging habilitado
etcd: cifrado en reposo, acceso restringido solo al API server
RBAC: sin bindings innecesarios de cluster-admin, minimo privilegio aplicado
Pod Security: PSS restricted aplicado en namespaces de produccion
NetworkPolicies: denegacion por defecto en todos los namespaces, reglas de permiso explicitas
Secretos: gestor de secretos externo o sealed secrets, cifrado en reposo
Imagenes: imágenes firmadas, aplicación de registro de confianza, fijación de digest
Nodos: actualizaciones de seguridad automaticas, SO bastionado segun CIS
Auditoria: audit logs del API server enviados al SIEM
Monitorizacion: alertas sobre cambios de RBAC, creacion de pods privilegiados, exec en pods
Cadena de suministro: escaneo de vulnerabilidades en CI/CD, escaneo de imágenes en tiempo de admisión
Red: TLS entre todos los componentes, service mesh para mTLS entre pods

El bastionado de seguridad no es una actividad puntual. Programa revisiones trimestrales para reevaluar tu postura, ejecutar benchmarks CIS, revisar bindings RBAC y actualizar políticas a medida que tu cluster evoluciona.

Cómo bastioné mi homelab con K3s

Thu, 14 Sep 2023 00:00:00 +0000

Punto de partida

Llevo un tiempo corriendo K3s en un par de máquinas físicas en casa. Al principio lo instalé para aprender Kubernetes sin montar algo pesado, y lo fui usando para proyectos pequeños: algunas aplicaciones web, servicios de monitorización, cosas así. La instalación era perfectamente funcional pero nunca me había sentado a pensar en la seguridad con calma.

Hace unos meses decidí hacer ese ejercicio. Sin prisa, sin checklist genérica de internet. Solo mirar lo que tenía, entender qué estaba mal y arreglarlo.

Lo que encontré no era catastrófico, pero había bastantes cosas que no me gustaron. Lo escribo aquí porque K3s tiene particularidades respecto a un cluster Kubernetes estándar, y la mayoría de guías de bastionado hablan de kubeadm o clusters gestionados, no de instalaciones caseras con un binario único.

Lo que K3s tiene de diferente

Antes de entrar en lo que hice, vale la pena entender qué hace distinto a K3s desde el punto de vista de seguridad.

K3s empaqueta todo en un único binario: el API server, el scheduler, el controller manager, kubelet, kube-proxy y containerd. En lugar de etcd usa SQLite por defecto. El CNI por defecto es Flannel. El ingress controller por defecto es Traefik. Todo esto simplifica mucho la instalación, pero también significa que hay componentes activos que quizás no necesitas, y que algunas decisiones de diseño están pensadas para facilitar el uso, no para maximizar la seguridad.

El archivo de configuración está en /etc/rancher/k3s/config.yaml. Ahí es donde vive la mayoría de lo que voy a tocar.

El nodo antes que el cluster

Antes de tocar nada de Kubernetes, el sistema operativo. El cluster corre en Debian, así que empecé por ahí.

SSH

Tenía autenticación por contraseña activa. Es lo primero que hay que quitar:

1
2
3
4


# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AllowUsers miusuario

También cambié el puerto por defecto. No evita que alguien determinado te encuentre, pero sí elimina una cantidad enorme de ruido en los logs.

Firewall con nftables

La máquina tenía las interfaces de red completamente abiertas. Con un cluster K3s en casa, el API server (puerto 6443) no debería ser accesible desde fuera de tu red local. Mis reglas básicas con nftables:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# Listar reglas activas
nft list ruleset

# Política por defecto restrictiva
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Permitir loopback y conexiones establecidas
nft add rule inet filter input iifname lo accept
nft add rule inet filter input ct state established,related accept

# SSH solo desde red local
nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 22 accept

# API server K3s solo desde red local
nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 6443 accept

# Kubernetes node ports
nft add rule inet filter input tcp dport 30000-32767 accept

# Traefik (si lo usas como ingress)
nft add rule inet filter input tcp dport { 80, 443 } accept

# ICMP
nft add rule inet filter input icmp type echo-request accept

Lo que me sorprendió al revisar esto: el API server estaba escuchando en todas las interfaces y era alcanzable directamente desde la WAN porque el router tenía un port forward de otro servicio que arrastraba algo de tráfico. Pequeño susto, nada explotado, pero no era algo que quería dejar.

Parámetros del kernel

K3s con el flag --protect-kernel-defaults verifica que ciertos parámetros del kernel estén configurados correctamente. Si no los tienes bien, el arranque falla con un mensaje claro. Mejor configurarlos antes:

1
2
3
4
5
6
7


# /etc/sysctl.d/90-k3s-hardening.conf
kernel.panic = 10
kernel.panic_on_oops = 1
vm.overcommit_memory = 1
vm.panic_on_oom = 0
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 512

1

sysctl --system

Configuración de K3s

Con el nodo en orden, al cluster.

Archivo de configuración base

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# /etc/rancher/k3s/config.yaml
write-kubeconfig-mode: "0600"
protect-kernel-defaults: true
secrets-encryption: true
kube-apiserver-arg:
 - "anonymous-auth=false"
 - "audit-log-path=/var/log/k3s/audit.log"
 - "audit-log-maxage=30"
 - "audit-policy-file=/etc/rancher/k3s/audit-policy.yaml"
kube-controller-manager-arg:
 - "terminated-pod-gc-threshold=10"
kubelet-arg:
 - "streaming-connection-idle-timeout=5m"
 - "protect-kernel-defaults=true"
 - "make-iptables-util-chains=true"

Las tres líneas más importantes aquí:

secrets-encryption: true habilita el cifrado en reposo de los secrets de Kubernetes. Con K3s es un flag de primera clase, no hay que configurar un EncryptionConfiguration manual como en kubeadm.
anonymous-auth=false elimina el acceso anónimo al API server.
write-kubeconfig-mode: "0600" fuerza permisos restrictivos en el kubeconfig que K3s genera en /etc/rancher/k3s/k3s.yaml.

Política de auditoría

Sin audit logs, no sabes qué pasa en el cluster. Este es el mínimo razonable:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# /etc/rancher/k3s/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
 - level: Metadata
 resources:
 - group: ""
 resources: ["secrets"]
 - level: RequestResponse
 resources:
 - group: ""
 resources: ["pods/exec", "pods/attach"]
 - level: Request
 verbs: ["create", "update", "patch", "delete"]
 - level: None
 users: ["system:kube-proxy"]
 verbs: ["watch"]
 resources:
 - group: ""
 resources: ["endpoints", "services", "services/status"]
 - level: Metadata
 omitStages:
 - RequestReceived

Los logs van a /var/log/k3s/audit.log. En mi caso los recojo con Promtail y los mando a Loki, así puedo hacer queries desde Grafana cuando necesito revisar algo.

Kubeconfig

El kubeconfig que genera K3s en /etc/rancher/k3s/k3s.yaml tiene credenciales de administrador. Un error que vi en mi propia configuración: tenía ese archivo copiado en ~/.kube/config con permisos 644. Cualquier proceso corriendo bajo mi usuario podía leerlo.

1
2


# Permisos correctos
chmod 600 ~/.kube/config

Si tienes usuarios adicionales que necesitan acceso al cluster, crea ServiceAccounts o usa certificados de cliente con RBAC limitado. No distribuyas el kubeconfig de admin.

CNI: de Flannel a Cilium

Flannel viene por defecto en K3s. Funciona, pero no soporta NetworkPolicies por defecto. Eso significa que todos los pods se comunican entre sí sin restricciones.

Cambié a Cilium. El proceso con K3s requiere deshabilitar Flannel primero:

1
2
3


# /etc/rancher/k3s/config.yaml (añadir)
flannel-backend: none
disable-network-policy: true

Y luego instalar Cilium con Helm:

1
2
3
4
5
6
7
8
9


helm repo add cilium https://helm.cilium.io/

helm install cilium cilium/cilium \
 --namespace kube-system \
 --set operator.replicas=1 \
 --set ipam.mode=kubernetes \
 --set kubeProxyReplacement=strict \
 --set k8sServiceHost=192.168.1.10 \
 --set k8sServicePort=6443

Con kubeProxyReplacement=strict Cilium también reemplaza kube-proxy, lo que da mejor rendimiento con eBPF y mejor visibilidad del tráfico de red.

Después del cambio, empecé a aplicar NetworkPolicies. La primera y más importante: denegación por defecto en todos los namespaces de aplicaciones:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-all
 namespace: apps
spec:
 podSelector: {}
 policyTypes:
 - Ingress
 - Egress

A partir de ahí, permitir solo lo necesario explícitamente.

Secrets: qué hacer cuando solo tienes K3s

En un entorno corporativo usarías Vault o External Secrets Operator con AWS Secrets Manager o similar. En un homelab eso es overkill. Mi solución fue más simple:

El cifrado en reposo de K3s ya protege los secrets en la base de datos. Para los manifiestos en Git, uso age para cifrar los valores sensibles antes de commitearlos:

1
2


# Cifrar un valor
echo "mi-contraseña-real" | age -r $(cat ~/.config/age/recipient.txt) | base64

Y el valor cifrado va al repositorio. Para desplegarlo hay un paso manual de descifrado. No es tan cómodo como un operador automático, pero para un homelab es suficiente y no añade complejidad operativa.

Falco para detección en tiempo de ejecución

Todo lo anterior es prevención. Falco es detección: monitoriza las llamadas al sistema y genera alertas cuando algo sospechoso ocurre en un contenedor.

Lo instalé con Helm:

1
2
3
4
5


helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
 --namespace falco \
 --create-namespace \
 --set driver.kind=ebpf

Las reglas por defecto ya cubren bastante: ejecución de shells en contenedores, escrituras en directorios del sistema, cambios de privilegios, conexiones de red inesperadas. Añadí algunas reglas propias para mi caso de uso específico.

Las alertas van a Loki también. Así tengo en el mismo lugar los audit logs del API server y las alertas de Falco.

Pod Security Standards

Con K3s en versión >= 1.25 puedes usar Pod Security Admission directamente. Apliqué el nivel baseline en los namespaces de aplicaciones y restricted donde era posible:

1
2
3
4
5
6
7


apiVersion: v1
kind: Namespace
metadata:
 name: apps
 labels:
 pod-security.kubernetes.io/enforce: baseline
 pod-security.kubernetes.io/warn: restricted

El nivel restricted es estricto: requiere que los contenedores no corran como root, que el sistema de archivos raíz sea de solo lectura, y que se eliminen todas las capabilities de Linux. Algunas aplicaciones que tenía desplegadas no cumplían. Fui arreglándolo de una en una antes de subir el nivel de enforce.

Lo que dejé para después

No todo está perfecto. Hay cosas que sé que debería hacer y todavía no he hecho:

Rootless K3s: se puede correr K3s completamente sin root, lo que reduce el impacto de una posible escalada de privilegios. Lo he mirado, tiene algunas limitaciones con ciertas características de red, pero para mi caso de uso debería funcionar.

Verificación de imágenes con cosign: firmar y verificar imágenes antes de desplegarlas. Tengo un registro privado para mis imágenes y las de terceros que uso, pero no estoy verificando firmas todavía.

CIS Benchmark: K3s tiene documentación oficial para el benchmark CIS K3s. Lo he revisado parcialmente pero no he pasado kube-bench de forma sistemática para ver qué queda pendiente.

Lo que aprendí

La instalación por defecto de K3s es sorprendentemente razonable para lo que es: una distribución pensada para ser fácil de desplegar. Pero “razonable” no es lo mismo que “bastionada”.

Lo que más me sorprendió fue lo fácil que resultó hacer la mayoría de cambios. K3s tiene flags de primera clase para muchas cosas que en kubeadm requieren configuración manual. El secrets-encryption, el protect-kernel-defaults, la política de auditoría directamente en el archivo de configuración. No es tan difícil si te sientas a leer la documentación.

El mayor riesgo en un homelab no es que alguien en internet te ataque directamente. Es que tienes un montón de servicios corriendo en la misma red que tu vida personal, y si alguno se compromete, el radio de explosión puede ser mayor de lo que parece. Vale la pena tomárselo en serio aunque sea un entorno de juguete.