Ansichten:
Profilanwendbarkeit: Stufe 1
Standardmäßig dürfen Container größtenteils uneingeschränkt innerhalb ihres eigenen Kontexts ausgeführt werden. Ein Cyber-Akteur, der in einem Container Ausführung erlangt hat, kann Dateien erstellen, Skripte herunterladen und die Anwendung innerhalb des Containers ändern. Kubernetes kann das Dateisystem eines Containers sperren und dadurch viele Aktivitäten nach einer Ausnutzung verhindern. Diese Einschränkungen betreffen jedoch auch legitime Container-Anwendungen und können potenziell zu Abstürzen oder anomalem Verhalten führen. Um Schäden an legitimen Anwendungen zu vermeiden, können Kubernetes-Administratoren sekundäre Lese-/Schreib-Dateisysteme für bestimmte Verzeichnisse einbinden, in denen Anwendungen Schreibzugriff benötigen.

Prüfung

Führen Sie den folgenden Befehl aus und überprüfen Sie den securityContext der Container jedes Pods:
kubectl get pods --all-namespaces
Stellen Sie sicher, dass jeder Container securityContext.readOnlyRootFilesystem auf true gesetzt hat.

Wiederherstellung

Ändern Sie containers[].securityContext.readOnlyRootFilesystem in true.
Das folgende Beispiel ist eine Kubernetes-Bereitstellungsvorlage, die ein schreibgeschütztes Stammdateisystem verwendet. 
securityContext: readOnlyRootFilesystem: true
Die Zeilen, die volumeMounts und volumes festlegen, zeigen, wie man ein beschreibbares Volume für Anwendungen erstellt, die diese Fähigkeit benötigen.
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec: 
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
      name: web
    spec:
      containers:
      - command: ["sleep"]
        args: ["999"]
        image: ubuntu:latest
        name: web
        securityContext:
          readOnlyRootFilesystem: true
        volumeMounts:
          - mountPath: /writeable/location/here
            name: volName
    volumes:
    - emptyDir: {}
    name: volName