Hardening Kubernetes – NSA

El hardening de la NSA viene con varias secciones, mas interesante que el OWASP que son los fallos mundiales. Sin configuraciones practicas y especificas para no ser parte de ese grupito.

La guia PDF de NSA del gobierno de estados unidos tiene mucho mas detalle y explicacion de porque cada punto.

Pero la lista en KubeArmor github es mas aplicable.

Hardening de Pods:

  • Los contenedores deben ser construidos, con usuarios de tipo non-root y de grupos non-root. Y deben ser colocados los non-root user en el manifiesto de K8.
apiVersion: v1
kind: Pod
metadata:
  name: non-root-pod
spec:
  securityContext:
    runAsUser: 1001 #El usaurio no debe ser 0
    runAsGroup: 1001 #El grupo no debe ser 0
    runAsNonRoot: true # Esta bandera deber ser true
  containers:
  - name: app
    image: nginx
  • Usar motores de contenedores rootless. Son estos motores que no tienen root en sus imagenes, me sucede con Openshift.
  • Hacer los filesystem inmutables. Hay una bandera para esto en los manifiestos.
containers:
- name: app
  image: nginx
  securityContext:
    readOnlyRootFilesystem: true # Debe ser true
  • Usar repositorios confiables e imagenes firmadas digitalmente.
  • Escanear los contenedores (scheck sysdig blogs)
  • Forzar la aplicacion de politicas segun el cluster y el caso de uso (PSA, PSP, kyverno, OPA).
  • Harden las capacidades del pod (Linux capabilites) solo usar las necesarias segun el caso de uso.
securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE
  • Prevenir el automount de cuentas de servicio en un pod. Lo ideal es que no se habiliten estas credenciales. Si un pod necesita acceso al cluster o servicios internos o externos debe ser mediante RBAC.
spec:
  automountServiceAccountToken: false
  • Usar una container runtime Hardened, con alguna estrategia (Hypervisor-backed or Kernel based or Application sandboxes container runtimes). Como gVisor o FireCracker
  • Restringir los PIDs de los pods. 
En el kubelet (si tiene acceso)
--pod-max-pids=100
--system-reserved=pid=1000
--kube-reserved=pid=500

Hardening de Namespaces:

  • Aislar los namespaces para multiples individuos, equipos o aplicaciones mediante reglas RBAC.
  • Limitar los recursos (Resource Quota, LimitRange Policy)

Hardening de Red y Plano de control:

  • Utilizar una network policy por defecto para denegar todo el trafico de ingress o egress a cualquier pod.
  • Utilizar certificados TLS para encriptar el trafico para todos los servicios que se exponen externamente, mediante NodePort, LoadBalancer u otros.
  • El API Server no debe exponerse a internet o a una red que no sea de confianza
  • Aplicar certifciados TLS para forzar la comunicacion HTTPS entre el etcd y el api-server.
  • Usar una CA (autoridad certificadora) para el etcd.
  • Usuarios no autenticados non-root deben ser bloqueados de acceder a kubeconfig files, etc.
  • Segmenta la red, de los worker nodes y los control nodes. Segun el tipo de trafico.
  • Encritar todo el trafico entre componentes de kubernetes.
  • Restringir todo el acceso a recursos de tipo secret mediante RBAC policies.
  • Usar una encriptacion fuerte para los datos de secretos.
  • Si se ejecuta en un cloud provider, prevenir el acceso a la instancia de metadatos cloud.

Autenticacion y autorizacion:

  • Implemetar un metodo de autenticacion o delegar la autenticacion a un servicio de terceros.
  • Deshabilitar los request anonimos mediante la opcion –anonymous-auth=false en el API Server
  • Crear politicas RBAC, con usuarios unicos para roles, administradores, developers, service accounts y equipos de infraestructura.
  • El acceso a pods debe ser restringido para aquellos que los necesitan mediante RBAC.

For a more detailed information, check out: https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF