Met AppArmor en SELinux beperk je wat een container op node-niveau mag doen, ook als een proces in de container toch extra rechten zou proberen te gebruiken. Dit is een extra verdedigingslaag naast RBAC, container image-hardening en NetworkPolicies.
Welke van de twee je gebruikt, hangt vooral af van het besturingssysteem van je nodes: AppArmor komt meestal voor op Ubuntu- en Debian-nodes (deze gebruiken we ook op het Kubernetes-platform van TransIP), terwijl SELinux gebruikelijk is op AlmaLinux, Rocky Linux, RHEL en CentOS Stream.
- Gebruik AppArmor of SELinux voor workloads met gevoelige data, extra privileges of strenge compliance-eisen.
- Begin met runtime-defaults en maak pas later strengere custom profiles.
- Custom AppArmor-profielen met `Localhost` of maatwerk-SELinux-policies vereisen nodebeheer. Op managed clusters is dat niet altijd mogelijk.
Voor je begint
Bepaal eerst welke Linux security module je nodes gebruiken. Controleer met kubectl het OS van je nodes:
kubectl get nodes -o wideGebruik in de praktijk meestal:
- AppArmor: op Ubuntu- of Debian-gebaseerde nodes.
- SELinux: op RHEL-, AlmaLinux-, Rocky Linux- of CentOS Stream-nodes.
Start op Ubuntu- en Debian-nodes met AppArmor RuntimeDefault
Stap 1
Maak een .yaml-bestand aan voor een pod met AppArmor `RuntimeDefault`, bijvoorbeeld:
nano apparmor-demo.yamlPlaats de volgende configuratie in het bestand:
apiVersion: v1
kind: Namespace
metadata:
name: kb-mac-test
---
apiVersion: v1
kind: Pod
metadata:
name: apparmor-runtime-default
namespace: kb-mac-test
spec:
restartPolicy: Never
containers:
- name: busybox
image: busybox:1.36
command: ["/bin/sh", "-c", "sleep 3600"]
securityContext:
appArmorProfile:
type: RuntimeDefault
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
runAsNonRoot: true
runAsUser: 65532
seccompProfile:
type: RuntimeDefaultSla de wijzigingen op en sluit het bestand (ctrl + x > y > enter).
Stap 2
Maak de resources aan en wacht tot de pod draait:
kubectl apply -f apparmor-demo.yaml
kubectl -n kb-mac-test wait --for=condition=Ready pod/apparmor-runtime-default --timeout=180s
Stap 3
Controleer of de container een AppArmor-profiel gebruikt:
kubectl -n kb-mac-test exec apparmor-runtime-default -- cat /proc/1/attr/currentJe hoort hier een profielnaam te zien in plaats van `unconfined`. Daarmee weet je dat AppArmor actief is voor de workload.
Gebruik SELinux op RHEL-gebaseerde nodes
Gebruik je nodes met SELinux, dan voeg je in plaats van appArmorProfile in de vorige paragraaf een `seLinuxOptions`-blok toe. Een eenvoudig voorbeeld ziet er zo uit:
securityContext:
seLinuxOptions:
level: "s0:c123,c456"
allowPrivilegeEscalation: false
runAsNonRoot: true
seccompProfile:
type: RuntimeDefaultGebruik `seLinuxOptions` alleen als je begrijpt welke labels en policies je nodes al gebruiken. Op veel platformen is de runtime-default al veilig genoeg, en een fout label kan ervoor zorgen dat een workload geen volumes of sockets meer mag openen.
Wanneer gebruik je RuntimeDefault en wanneer een custom profiel?
- RuntimeDefault: kies dit als veilige standaard voor vrijwel alle workloads.
- Custom AppArmor Localhost-profiel: gebruik dit alleen als je de nodes zelf beheert en hetzelfde profiel op elke node kunt laden.
- Custom SELinux-policy: gebruik dit alleen als je precies weet welke SELinux-contexten en type enforcement je nodig hebt.
Voor veel omgevingen levert `RuntimeDefault` al directe winst op zonder veel beheerlast.
AppArmor en SELinux zijn geen vervanging voor andere securitymaatregelen, maar wel een belangrijke extra laag. Begin met runtime-defaults, combineer die met beperkte privileges en breid pas uit naar custom profielen als daar een duidelijke reden voor is.