33 Security Context in Kubernetes

Security Context

Security Context definiert Privilegien und Zugriffskontrollparameter für Pods oder Container innerhalb eines Pods in Kubernetes. Sie werden verwendet, um die Zugriffsrechte und Fähigkeiten von Prozessen zu steuern, die in einem Container laufen. Security Context kann auf zwei Ebenen definiert werden:

• Pod Security Context: Beeinflusst den gesamten Pod und alle Container innerhalb dieses Pods.
• Container Security Context: Spezifisch für einen einzelnen Container innerhalb eines Pods und überschreibt den Pod Security Context, sofern vorhanden.

33.1 Konfiguration des Security Context

Die Konfiguration erfolgt über die Pod-Spezifikation oder die Container-Spezifikation im Manifest (YAML-Format) von Kubernetes. Einige der Attribute, die konfiguriert werden können, umfassen:

• runAsUser: Bestimmt, welche User-ID (UID) Prozesse innerhalb des Containers verwenden werden.
• runAsGroup: Bestimmt, welche Gruppen-ID (GID) Prozesse innerhalb des Containers verwenden werden.
• fsGroup: Legt die Eigentumsrechte und Gruppenrechte für Volumes fest.
• privileged: Gibt an, ob der Container mit erweiterten Privilegien ausgeführt werden soll.
• readOnlyRootFilesystem: Ermöglicht es, das Root-Dateisystem des Containers als schreibgeschützt zu setzen.
• allowPrivilegeEscalation: Steuert, ob Prozesse in einem Container ihre Privilegien erhöhen können.
• capabilities: Gibt dem Container bestimmte Berechtigungen, die über die Standardberechtigungen hinausgehen.
• seLinuxOptions: Erlaubt die Konfiguration von SELinux Labels für den Container.

33.2 Anwendung von Security Context

Um einen Security Context anzuwenden, fügt man die entsprechenden Felder in das Pod oder Container Manifest ein. Hier ein Beispiel für einen Pod Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: example-container
    image: example/image

Im Container Security Context kann es so aussehen:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example/image
    securityContext:
      runAsNonRoot: true
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

33.3 Best Practices

• Verwenden von runAsNonRoot: Stellt sicher, dass der Container nicht als root-Benutzer läuft.
• Einschränken von capabilities: Entfernt unnötige Berechtigungen und folgt dem Prinzip des geringsten Privilegs.
• Aktivieren von readOnlyRootFilesystem: Begrenzt die Möglichkeiten einer Kompromittierung des Containers.
• Anpassung der SELinux Policies: Sorgt für eine strikte Trennung und Kontrolle über Prozesse und Dateizugriffe.

33.4 Sicherheitsaspekte

Durch die feingranulare Kontrolle über Betriebssystemebenen-Privilegien bietet der Security Context in Kubernetes eine starke Sicherheitsebene. Es ist jedoch wichtig, die Konfiguration sorgfältig zu planen und Standardvorlagen zu verwenden, um die Konsistenz und Sicherheit der Deployments zu gewährleisten. Sicherheitsaudits und regelmäßige Überprüfungen der Security Contexts sind ebenso entscheidend, um sicherzustellen, dass keine unerwünschten Berechtigungen gewährt werden.

33.5 Demonstration des Security Context über kubectl exec

Um zu demonstrieren, wie der Security Context eines Containers die Identität und Berechtigungen eines Prozesses beeinflusst, kann man den kubectl exec Befehl nutzen, um in den Container einzutreten und den id Befehl auszuführen. Der id Befehl zeigt die User-ID (UID), Gruppen-ID (GID) und die Gruppenzugehörigkeit des aktuellen Benutzers.

Zuerst erstellt man einen Pod mit einem spezifischen Security Context:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 3000
  containers:
  - name: alpine
    image: alpine
    command: ["sh", "-c", "sleep 1h"]

Nachdem der Pod läuft, kann man mit dem folgenden Befehl in den Container eintreten:

kubectl exec -it security-context-demo -- sh

Im Container kann man dann den Befehl id ausführen, um die UID und GID des aktuellen Benutzers zu überprüfen:

id

Die Antwort sollte die UID und GID anzeigen, die im Security Context definiert wurden:

uid=1000 gid=3000

Dies zeigt, dass der Prozess im Container mit den im Security Context definierten Berechtigungen ausgeführt wird.