Kubernetes Security: Hardening di Sistema e Controlli Operativi

L'hardening security riduce la superficie di attacco e rende piu controllabile l'esecuzione di servizi, container e workload applicativi. L'obiettivo e' verificare privilegi, servizi esposti, configurazioni sensibili e policy di rete, mantenendo ogni controllo ripetibile e documentabile.

Panoramica

Le verifiche principali riguardano identita utente, privilegi sudo, possibili vettori di privilege escalation, permessi sui file critici, stato dei servizi, autenticazione SSH e hardening dei workload Kubernetes. In ambienti esposti tramite Traefik, anche header HTTP, rate limit e instradamento devono essere trattati come parte della superficie pubblica.

Verifica identita e privilegi

Controllare l'utente corrente, i gruppi associati e i privilegi disponibili:

whoami
id
groups
sudo -l

Verificare gli utenti privilegiati:

getent group sudo
getent group wheel

Questi controlli permettono di validare che gli utenti abbiano solo i privilegi necessari e che le regole sudo siano esplicite, limitate e tracciabili.

Controllo privilege escalation

Ricercare binari con bit SUID e SGID:

find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

Verificare file e directory scrivibili nel filesystem corrente:

find / -xdev -type f -writable 2>/dev/null
find / -xdev -type d -writable 2>/dev/null

Controllare eventuali Linux capabilities assegnate ai binari:

getcap -r / 2>/dev/null

SUID, SGID, path scrivibili e capabilities anomale sono elementi da validare periodicamente, perche possono trasformarsi in vettori di escalation se combinati con binari vulnerabili o configurazioni permissive.

Servizi, porte e SSH

Verificare porte in ascolto e servizi attivi:

ss -tulpn
systemctl --type=service --state=running

Controllare la configurazione effettiva di SSH:

sshd -T

Parametri da verificare:

PermitRootLogin
PasswordAuthentication
PubkeyAuthentication
AllowUsers
AllowGroups
MaxAuthTries

La configurazione attesa privilegia autenticazione tramite chiave, accessi limitati agli utenti necessari e divieto di login diretto come root quando non richiesto.

Permessi sensibili e aggiornamenti

Validare permessi e sintassi dei file legati ad autenticazione e privilegi:

ls -l /etc/passwd
ls -l /etc/shadow
ls -l /etc/group
ls -l /etc/sudoers
ls -ld /etc/sudoers.d
visudo -c

Verificare aggiornamenti disponibili:

apt update
apt list --upgradable

Su distribuzioni RHEL-like:

dnf check-update
dnf updateinfo list security

Hardening Kubernetes

Per i workload Kubernetes, il baseline minimo deve limitare privilegi, token automatici e accesso alla rete.

spec:
  enableServiceLinks: false # (1)!
  automountServiceAccountToken: false # (2)!
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false # (3)!
        capabilities:
          drop:
            - ALL # (4)!
        readOnlyRootFilesystem: true # (5)!
        runAsNonRoot: true # (6)!

1. Evita l'iniezione automatica delle variabili ambiente dei Service Kubernetes nel Pod.
2. Non monta automaticamente il token del ServiceAccount quando il workload non deve chiamare l'API Kubernetes.
3. Impedisce al processo di acquisire privilegi aggiuntivi rispetto a quelli iniziali.
4. Rimuove tutte le Linux capabilities non necessarie dal container.
5. Monta il filesystem root del container in sola lettura.
6. Forza l'esecuzione del processo con utente non root.

NetworkPolicy e Traefik

Le NetworkPolicy permettono di ridurre la comunicazione laterale tra Pod, consentendo solo i flussi necessari. Per un endpoint pubblico esposto tramite Traefik, il traffico in ingresso dovrebbe arrivare esclusivamente dal controller ingress/gateway e solo sulla porta applicativa prevista.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-public-endpoint
spec:
  podSelector:
    matchLabels:
      app: mkdocs
      component: mcp
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system # (1)!
          podSelector:
            matchLabels:
              app.kubernetes.io/name: rke2-traefik # (2)!
      ports:
        - protocol: TCP
          port: 8000 # (3)!
  egress: [] # (4)!

1. Limita la sorgente al namespace in cui opera Traefik.
2. Consente traffico solo dai Pod del controller Traefik.
3. Espone esclusivamente la porta applicativa necessaria.
4. Blocca traffico in uscita dal workload quando non richiesto.

Sul layer HTTP, Traefik puo applicare controlli aggiuntivi come rimozione dell'header Server, Cache-Control: no-store, X-Content-Type-Options: nosniff e rate limit sull'endpoint pubblico. CORS deve rimanere chiuso quando non esiste una reale esigenza di accesso browser cross-origin.

Risultato atteso

Una configurazione hardened deve garantire che:

• gli utenti dispongano solo dei privilegi necessari;
• le regole sudo siano limitate e verificabili;
• SUID, SGID e capabilities anomale vengano identificate;
• non siano presenti file critici scrivibili impropriamente;
• siano esposti solo i servizi necessari;
• SSH utilizzi una configurazione restrittiva;
• i container girino non-root, con privilegi minimi e filesystem read-only;
• le policy di rete limitino ingress ed egress;
• gli endpoint pubblici siano protetti da header hardening e rate limit;
• le verifiche possano essere ripetute periodicamente.