Sicherheit des Pods - Amazon EKS
Linux-FunktionenSicherheitslösungen für PodsEmpfehlungenTools und Ressourcen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Sicherheit des Pods

Die Pod-Spezifikation umfasst eine Vielzahl verschiedener Attribute, die Ihre allgemeine Sicherheitslage stärken oder schwächen können. Als Kubernetes-Experte sollte es Ihr Hauptanliegen sein, zu verhindern, dass ein Prozess, der in einem Container ausgeführt wird, die Isolationsgrenzen der Container-Laufzeit durchbricht und Zugriff auf den zugrunde liegenden Host erhält.

Linux-Funktionen

Die Prozesse, die innerhalb eines Containers ausgeführt werden, werden standardmäßig im Kontext des [Linux] -Root-Benutzers ausgeführt. Obwohl die Aktionen von root innerhalb eines Containers teilweise durch die Linux-Funktionen eingeschränkt werden, die die Container-Runtime den Containern zuweist, könnten diese Standardberechtigungen es einem Angreifer ermöglichen, seine Rechte zu erweitern und/oder Zugriff auf vertrauliche Informationen zu erhalten, die an den Host gebunden sind, einschließlich Secrets und. ConfigMaps Im Folgenden finden Sie eine Liste der Standardfunktionen, die Containern zugewiesen sind. Weitere Informationen zu den einzelnen Funktionen finden Sie unter http://man7. org/linux/man-pages/man7/capabilities7.html.

CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETUID, CAP_SETFCAP, CAP_SETPCAP, CAP_SYS_CHROOT

EC2 und Fargate-Pods werden standardmäßig die oben genannten Funktionen zugewiesen. Darüber hinaus können Linux-Funktionen nur aus Fargate-Pods entfernt werden.

Pods, die als privilegiert ausgeführt werden, erben alle Linux-Funktionen, die mit Root auf dem Host verknüpft sind. Dies sollte nach Möglichkeit vermieden werden.

Knotenautorisierung

Alle Kubernetes-Worker-Knoten verwenden einen Autorisierungsmodus namens Node Authorization. Die Knotenautorisierung autorisiert alle API-Anfragen, die vom Kubelet stammen, und ermöglicht es den Knoten, die folgenden Aktionen auszuführen:

Operationen lesen:

  • service

  • Endpunkte

  • Knoten

  • Hülsen

  • Secrets, Configmaps, persistente Volume Claims und persistente Volumes, die sich auf Pods beziehen, die an den Knoten des Kubelets gebunden sind

Schreiboperationen:

  • Knoten und Knotenstatus (aktivieren Sie das NodeRestriction Zulassungs-Plugin, um ein Kubelet darauf zu beschränken, seinen eigenen Knoten zu modifizieren)

  • Pods und Pod-Status (aktivieren Sie das NodeRestriction Zugangs-Plugin, um ein Kubelet darauf zu beschränken, an sich selbst gebundene Pods zu ändern)

  • Veranstaltungen

Operationen im Zusammenhang mit der Authentifizierung:

  • Lese-/Schreibzugriff auf die CertificateSigningRequest (CSR-) API für TLS-Bootstrapping

  • die Fähigkeit, Prüfungen zu erstellen und für delegierte Prüfungen durchzuführen TokenReview SubjectAccessReview authentication/authorization

EKS verwendet den Node Restriction Admission Controller, der es dem Knoten nur ermöglicht, einen begrenzten Satz von Knotenattributen und Pod-Objekten zu ändern, die an den Knoten gebunden sind. Dennoch kann ein Angreifer, dem es gelingt, Zugriff auf den Host zu erhalten, weiterhin vertrauliche Informationen über die Umgebung aus der Kubernetes-API abrufen, die es ihm ermöglichen könnten, sich innerhalb des Clusters seitlich zu bewegen.

Sicherheitslösungen für Pods

Pod-Sicherheitsrichtlinie (PSP)

In der Vergangenheit wurden Ressourcen der Pod Security Policy (PSP) verwendet, um eine Reihe von Anforderungen zu spezifizieren, die Pods erfüllen mussten, bevor sie erstellt werden konnten. Seit Version 1.21 von Kubernetes sind PSP veraltet. Sie sollen in Kubernetes Version 1.25 entfernt werden.

Wichtig

PSPs sind in Kubernetes Version 1.21 veraltet. Sie haben bis Version 1.25 oder etwa 2 Jahre Zeit, um auf eine Alternative umzusteigen. In diesem Dokument wird die Begründung für diese Abwertung erläutert.

Migration zu einer neuen Pod-Sicherheitslösung

Da PSPs diese Sicherheitskontrollen ab Kubernetes v1.25 entfernt wurden, müssen Clusteradministratoren und -betreiber diese Sicherheitskontrollen ersetzen. Zwei Lösungen können diesen Bedarf decken:

Sowohl die PAC- als auch die PSS-Lösung können mit PSP koexistieren. Sie können in Clustern verwendet werden, bevor PSP entfernt wird. Dies erleichtert die Einführung bei der Migration von PSP. Bitte lies dir dieses Dokument durch, wenn du eine Migration von PSP zu PSS in Betracht ziehst.

Kyverno, eine der unten aufgeführten PAC-Lösungen, bietet in einem Blogbeitrag spezifische Leitlinien für die Migration von PSPs zu seiner Lösung, darunter analoge Richtlinien, Funktionsvergleiche und ein Migrationsverfahren. Zusätzliche Informationen und Anleitungen zur Migration nach Kyverno in Bezug auf Pod Security Admission (PSA) wurden hier im AWS-Blog veröffentlicht.

Policy-as-code (PAC)

Policy-as-code (PAC) -Lösungen bieten Leitplanken, um Cluster-Benutzer anzuleiten und unerwünschtes Verhalten durch vorgeschriebene und automatisierte Kontrollen zu verhindern. PAC verwendet Kubernetes Dynamic Admission Controllers, um den Anforderungsfluss des Kubernetes-API-Servers über einen Webhook-Aufruf abzufangen und Anforderungs-Payloads auf der Grundlage von Richtlinien, die als Code geschrieben und gespeichert wurden, zu mutieren und zu validieren. Die Mutation und Validierung erfolgt, bevor die API-Serveranfrage zu einer Änderung des Clusters führt. PAC-Lösungen verwenden Richtlinien, um Payloads von API-Serveranfragen auf der Grundlage von Taxonomie und Werten abzugleichen und darauf zu reagieren.

Für Kubernetes sind mehrere Open-Source-PAC-Lösungen verfügbar. Diese Lösungen sind nicht Teil des Kubernetes-Projekts. Sie stammen aus dem Kubernetes-Ökosystem. Einige PAC-Lösungen sind unten aufgeführt.

Weitere Informationen zu PAC-Lösungen und dazu, wie wir Ihnen bei der Auswahl der für Ihre Bedürfnisse geeigneten Lösung helfen können, finden Sie unter den folgenden Links.

Pod-Sicherheitsstandards (PSS) und Pod Security Admission (PSA)

Als Reaktion auf die PSP-Abwertung und die anhaltende Notwendigkeit, die Pod-Sicherheit mit einer integrierten Kubernetes-Lösung zu kontrollieren out-of-the-box, hat die Kubernetes Auth Special Interest Group die Pod Security Standards (PSS) und Pod Security Admission (PSA) entwickelt. Zu den Bemühungen der PSA gehört ein Webhook-Projekt für die Zugangssteuerung, das die im PSS definierten Kontrollen implementiert. Dieser Ansatz für den Zugangscontroller ähnelt dem, der in den PAC-Lösungen verwendet wird.

Laut der Kubernetes-Dokumentation definiert das PSS „drei verschiedene Richtlinien, um das gesamte Sicherheitsspektrum abzudecken. Diese Richtlinien sind kumulativ und reichen von sehr freizügig bis sehr restriktiv. `“

Diese Richtlinien sind wie folgt definiert:

  • Privilegiert: Uneingeschränkte (unsichere) Richtlinie, die ein möglichst breites Maß an Berechtigungen bietet. Diese Richtlinie ermöglicht bekannte Eskalationen von Rechten. Es ist das Fehlen einer Richtlinie. Dies ist ideal für Anwendungen wie Logging-Agenten CNIs, Speichertreiber und andere systemweite Anwendungen, die privilegierten Zugriff benötigen.

  • Grundeinstellung: Minimal restriktive Richtlinie, die bekannte Rechteerweiterungen verhindert. Ermöglicht die standardmäßige (minimal angegebene) Pod-Konfiguration. Die Basisrichtlinie verbietet die Verwendung von HostNetwork, HostPid, HostIPC, HostPath, HostPort, die Unfähigkeit, Linux-Funktionen hinzuzufügen, sowie mehrere andere Einschränkungen.

  • Eingeschränkt: Stark eingeschränkte Richtlinie, die den aktuellen bewährten Methoden zur Pod-Hardening-Methode entspricht. Diese Richtlinie erbt von der Baseline und fügt weitere Einschränkungen hinzu, z. B. die Unfähigkeit, als Root-Benutzer oder als Root-Gruppe ausgeführt zu werden. Eingeschränkte Richtlinien können die Funktionsfähigkeit einer Anwendung beeinträchtigen. Sie sind in erster Linie auf die Ausführung sicherheitskritischer Anwendungen ausgerichtet.

Diese Richtlinien definieren Profile für die Pod-Ausführung, die in drei Stufen mit privilegiertem und eingeschränktem Zugriff unterteilt sind.

Um die im PSS definierten Kontrollen zu implementieren, arbeitet PSA in drei Modi:

  • durchsetzen: Verstöße gegen die Richtlinien führen dazu, dass der Pod abgelehnt wird.

  • Prüfung: Bei Verstößen gegen Richtlinien wird dem im Audit-Protokoll aufgezeichneten Ereignis eine Audit-Anmerkung hinzugefügt, andernfalls sind sie jedoch zulässig.

  • Warnung: Bei Verstößen gegen Richtlinien wird eine Warnung angezeigt, die vom Benutzer angezeigt wird, sind aber ansonsten zulässig.

Diese Modi und die Profilstufen (Einschränkungsebenen) werden auf der Kubernetes-Namespace-Ebene mithilfe von Labels konfiguriert, wie im folgenden Beispiel zu sehen ist.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: restricted

Wenn diese Betriebsmodi unabhängig voneinander verwendet werden, reagieren sie unterschiedlich, was zu unterschiedlichen Benutzererfahrungen führt. Der Erzwingungsmodus verhindert, dass Pods erstellt werden, wenn die jeweiligen PodSpecs gegen die konfigurierte Einschränkungsstufe verstoßen. In diesem Modus wird jedoch nicht verhindert, dass Kubernetes-Objekte, die Pods erstellen, wie z. B. Deployments, auf den Cluster angewendet werden, auch wenn die darin enthaltene PodSpec gegen die angewendete PSS verstößt. In diesem Fall wird das Deployment angewendet, wohingegen die Anwendung der Pods verhindert wird.

Dies ist eine schwierige Benutzererfahrung, da es keinen unmittelbaren Hinweis darauf gibt, dass das erfolgreich angewendete Deployment-Objekt einer fehlgeschlagenen Pod-Erstellung widerspricht. Mit den fraglichen PodSpecs werden keine Pods erstellt. Wenn Sie die Bereitstellungsressource mit überprüfen, kubectl get deploy <DEPLOYMENT_NAME> -oyaml wird die Meldung des ausgefallenen .status.conditions Pod-Elements angezeigt, wie unten dargestellt.

...
status:
  conditions:
    - lastTransitionTime: "2022-01-20T01:02:08Z"
      lastUpdateTime: "2022-01-20T01:02:08Z"
      message: 'pods "test-688f68dc87-tw587" is forbidden: violates PodSecurity "restricted:latest":
        allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false),
        unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]),
        runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true),
        seccompProfile (pod or container "test" must set securityContext.seccompProfile.type
        to "RuntimeDefault" or "Localhost")'
      reason: FailedCreate
      status: "True"
      type: ReplicaFailure
...

Sowohl im Audit - als auch im Warn-Modus verhindern die Pod-Einschränkungen nicht, dass Pods erstellt und gestartet werden, die die Verletzung verletzen. In diesen Modi werden jedoch Audit-Anmerkungen zu API-Server-Audit-Log-Ereignissen und Warnungen an API-Serverclients wie kubectl jeweils ausgelöst, wenn Pods sowie Objekte, die Pods erstellen, PodSpecs enthalten, die Verstöße enthalten. Eine kubectl Warnmeldung ist unten zu sehen.

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/test created

Die PSA-Überwachungs - und Warnmodi sind bei der Einführung des PSS nützlich, ohne den Clusterbetrieb negativ zu beeinflussen.

Die PSA-Betriebsmodi schließen sich nicht gegenseitig aus und können kumulativ verwendet werden. Wie unten dargestellt, können die verschiedenen Modi in einem einzigen Namespace konfiguriert werden.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Im obigen Beispiel werden die benutzerfreundlichen Warnungen und Audit-Anmerkungen bei der Anwendung von Deployments bereitgestellt, und die Durchsetzung von Verstößen erfolgt auch auf Pod-Ebene. Tatsächlich können mehrere PSA-Labels unterschiedliche Profilebenen verwenden, wie unten dargestellt.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

Im obigen Beispiel ist PSA so konfiguriert, dass alle Pods erstellt werden können, die die Basisprofilebene erfüllen, und dann vor Pods (und Objekten, die Pods erstellen) gewarnt werden, die gegen die eingeschränkte Profilebene verstoßen. Dies ist ein nützlicher Ansatz, um die möglichen Auswirkungen zu ermitteln, wenn vom Basisprofil zu eingeschränkten Profilen gewechselt wird.

Bestehende Pods

Wenn ein Namespace mit vorhandenen Pods dahingehend geändert wird, dass er ein restriktiveres PSS-Profil verwendet, werden im Audit - und Warn-Modus entsprechende Meldungen ausgegeben. Im Erzwingungsmodus werden die Pods jedoch nicht gelöscht. Die Warnmeldungen sind unten aufgeführt.

Warning: existing pods in namespace "policy-test" violate the new PodSecurity enforce level "restricted:latest"
Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/policy-test configured

Ausnahmeregelungen

PSA verwendet Ausnahmen, um die Durchsetzung von Verstößen gegen Pods auszuschließen, die andernfalls verhängt worden wären. Diese Ausnahmen sind unten aufgeführt.

  • Benutzernamen: Anfragen von Benutzern mit einem ausgenommenen authentifizierten (oder nachgemachten) Benutzernamen werden ignoriert.

  • RuntimeClassNames: Pods und Workload-Ressourcen, die einen ausgenommenen Runtime-Klassennamen angeben, werden ignoriert.

  • Namespaces: Pods und Workload-Ressourcen in einem ausgenommenen Namespace werden ignoriert.

Diese Ausnahmen werden in der PSA-Zugangscontroller-Konfiguration als Teil der API-Serverkonfiguration statisch angewendet.

In der Implementierung von Validating Webhook können die Ausnahmen innerhalb einer ConfigMapKubernetes-Ressource konfiguriert werden, die als Volume in den Container gemountet wird. pod-security-webhook

apiVersion: v1
kind: ConfigMap
metadata:
  name: pod-security-webhook
  namespace: pod-security-webhook
data:
  podsecurityconfiguration.yaml: |
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
      enforce-version: "latest"
      audit: "restricted"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: ["kube-system","policy-test1"]

Wie im obigen ConfigMap YAML zu sehen ist, wurde die clusterweite Standard-PSS-Stufe für alle PSA-Modi „Audit“, „Enforce“ und „Warn“ auf „Restricted“ gesetzt. Dies betrifft alle Namespaces, mit Ausnahme der ausgenommenen:. namespaces: ["kube-system","policy-test1"] Darüber hinaus ist der pod-security-webhookNamespace in der unten abgebildeten ValidatingWebhookConfigurationRessource auch vom konfigurierten PSS ausgenommen.

...
webhooks:
  # Audit annotations will be prefixed with this name
  - name: "pod-security-webhook.kubernetes.io"
    # Fail-closed admission webhooks can present operational challenges.
    # You may want to consider using a failure policy of Ignore, but should
    # consider the security tradeoffs.
    failurePolicy: Fail
    namespaceSelector:
      # Exempt the webhook itself to avoid a circular dependency.
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["pod-security-webhook"]
...
Wichtig

Pod Security Admissions wurde in Kubernetes v1.25 auf Stable umgestellt. Wenn Sie die Pod Security Admission-Funktion verwenden wollten, bevor sie standardmäßig aktiviert wurde, mussten Sie den Dynamic Admission Controller (mutierender Webhook) installieren. Die Anweisungen zur Installation und Konfiguration des Webhooks finden Sie hier.

Wählen Sie zwischen den policy-as-code Sicherheitsstandards und den Pod-Sicherheitsstandards

Die Pod Security Standards (PSS) wurden entwickelt, um die Pod Security Policy (PSP) zu ersetzen, indem sie eine Lösung bieten, die in Kubernetes integriert war und keine Lösungen aus dem Kubernetes-Ökosystem erforderte. Davon abgesehen sind policy-as-code (PAC) -Lösungen erheblich flexibler.

Die folgende Liste mit Vor- und Nachteilen soll Ihnen helfen, eine fundiertere Entscheidung über Ihre Pod-Sicherheitslösung zu treffen.

Policy-as-code (im Vergleich zu den Pod-Sicherheitsstandards)

Vorteile:

  • Flexibler und detaillierter (bei Bedarf bis hin zu Ressourcenattributen)

  • Es konzentriert sich nicht nur auf Pods, sondern kann auch gegen verschiedene Ressourcen und Aktionen eingesetzt werden

  • Nicht nur auf Namespace-Ebene angewendet

  • Ausgereifter als die Pod-Sicherheitsstandards

  • Entscheidungen können auf beliebigen Angaben in der Nutzlast der API-Serveranforderung sowie auf vorhandenen Clusterressourcen und externen Daten (lösungsabhängig) basieren

  • Unterstützt mutierende API-Serveranfragen vor der Validierung (lösungsabhängig)

  • Kann ergänzende Richtlinien und Kubernetes-Ressourcen generieren (lösungsabhängig) — Aus Pod-Richtlinien kann Kyverno automatisch Richtlinien für übergeordnete Controller wie Deployments generieren. Kyverno kann mithilfe von Generate Rules auch zusätzliche Kubernetes-Ressourcen generieren, „wenn eine neue Ressource erstellt wird oder wenn die Quelle aktualisiert wird“.)

  • Kann verwendet werden, um nach links in die CICD-Pipelines zu wechseln, bevor der Kubernetes-API-Server aufgerufen wird (lösungsabhängig)

  • Kann verwendet werden, um Verhaltensweisen zu implementieren, die nicht unbedingt sicherheitsrelevant sind, wie z. B. bewährte Verfahren, Organisationsstandards usw.

  • Kann in Anwendungsfällen außerhalb von Kubernetes verwendet werden (lösungsabhängig)

  • Aufgrund der Flexibilität kann die Benutzererfahrung an die Bedürfnisse der Benutzer angepasst werden

Nachteile:

  • Nicht in Kubernetes integriert

  • Das Erlernen, Konfigurieren und Unterstützen ist komplexer

  • Für die Erstellung von Richtlinien sind möglicherweise neue erforderlich skills/languages/capabilities

Pod Security Admission (im Vergleich zu policy-as-code)

Vorteile:

  • In Kubernetes eingebaut

  • Einfacher zu konfigurieren

  • Es müssen keine neuen Sprachen verwendet oder Richtlinien erstellt werden

  • Wenn die Standard-Zugriffsebene des Clusters auf privilegiert konfiguriert ist, können Namespace-Labels verwendet werden, um Namespaces in die Pod-Sicherheitsprofile aufzunehmen.

Nachteile:

  • Nicht so flexibel oder granular wie policy-as-code

  • Nur 3 Stufen von Einschränkungen

  • Hauptsächlich auf Pods konzentriert

Übersicht

Wenn Sie derzeit über keine andere Pod-Sicherheitslösung als PSP verfügen und Ihr erforderlicher Sicherheitsstatus für den Pod dem in den Pod Security Standards (PSS) definierten Modell entspricht, ist es möglicherweise einfacher, anstelle einer Lösung das PSS einzuführen. policy-as-code Wenn Ihr Pod-Sicherheitsstatus jedoch nicht zum PSS-Modell passt oder Sie zusätzliche Kontrollen hinzufügen möchten, die über das von PSS definierte Maß hinausgehen, dann scheint eine policy-as-code Lösung besser geeignet zu sein.

Empfehlungen

Verwenden Sie mehrere Pod Security Admission (PSA) -Modi für eine bessere Benutzererfahrung

Wie bereits erwähnt, verhindert der PSA-Erzwingungsmodus, dass Pods mit PSS-Verstößen angewendet werden. Controller auf höherer Ebene, wie z. B. Bereitstellungen, werden jedoch nicht gestoppt. Tatsächlich wird die Bereitstellung erfolgreich angewendet, ohne dass es Hinweise darauf gibt, dass die Pods nicht angewendet wurden. Sie können zwar kubectl verwenden, um das Deployment-Objekt zu überprüfen und die Meldung über die fehlerhaften Pods vom PSA zu ermitteln, aber die Benutzererfahrung könnte besser sein. Um die Benutzererfahrung zu verbessern, sollten mehrere PSA-Modi (Audit, Enforce, Warn) verwendet werden.

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

Wenn im obigen Beispiel mit definiertem Erzwingungsmodus versucht wird, ein Deployment-Manifest mit PSS-Verstößen in der jeweiligen PodSpec auf den Kubernetes-API-Server anzuwenden, wird das Deployment erfolgreich angewendet, die Pods jedoch nicht. Und da die Modi Audit und Warn ebenfalls aktiviert sind, erhält der API-Server-Client eine Warnmeldung, und das Audit-Log-Ereignis des API-Servers wird ebenfalls mit einer Meldung versehen.

Schränken Sie die Container ein, die als privilegiert ausgeführt werden können

Wie bereits erwähnt, erben Container, die als privilegiert ausgeführt werden, alle Linux-Funktionen, die Root-Benutzern auf dem Host zugewiesen sind. In den seltensten Fällen benötigen Container diese Art von Rechten, um ordnungsgemäß zu funktionieren. Es gibt mehrere Methoden, mit denen die Berechtigungen und Funktionen von Containern eingeschränkt werden können.

Wichtig

Fargate ist ein Starttyp, mit dem Sie „serverlose“ Container ausführen können, wobei die Container eines Pods auf einer von AWS verwalteten Infrastruktur ausgeführt werden. Mit Fargate können Sie keinen privilegierten Container ausführen oder Ihren Pod für die Verwendung von HostNetwork oder HostPort konfigurieren.

Führen Sie Prozesse in Containern nicht als Root aus

Alle Container werden standardmäßig als Root ausgeführt. Dies könnte problematisch sein, wenn ein Angreifer in der Lage ist, eine Sicherheitslücke in der Anwendung auszunutzen und Shell-Zugriff auf den laufenden Container zu erhalten. Sie können dieses Risiko auf verschiedene Weise mindern. Zuerst, indem Sie die Shell aus dem Container-Image entfernen. Zweitens fügen Sie Ihrem Dockerfile die USER-Direktive hinzu oder führen Sie die Container im Pod als Nicht-Root-Benutzer aus. Die Kubernetes-PodSpec enthält unter eine Reihe von Feldern, mit denen Sie die and/or Benutzergruppe angeben könnenspec.securityContext, unter der Ihre Anwendung ausgeführt werden soll. Diese Felder sind jeweils und. runAsUser runAsGroup

Um die Verwendung von und den spec.securityContext zugehörigen Elementen innerhalb von Kubernetes zu erzwingen, können PodSpec policy-as-code - oder Pod-Sicherheitsstandards zu Clustern hinzugefügt werden. Mit diesen Lösungen können Sie Richtlinien oder Profile schreiben und/oder verwenden, mit denen eingehende Payloads für Kubernetes-API-Serveranfragen validiert werden können, bevor sie dauerhaft in etcd gespeichert werden. Darüber hinaus können policy-as-code Lösungen eingehende Anfragen mutieren und in einigen Fällen neue Anfragen generieren.

Führen Sie Docker niemals in Docker aus und mounten Sie den Socket niemals im Container

Auf diese Weise können Sie zwar bequem build/run Images in Docker-Containern erstellen, aber im Grunde geben Sie die vollständige Kontrolle über den Knoten an den Prozess ab, der im Container ausgeführt wird. Wenn Sie Container-Images auf Kubernetes erstellen müssen, verwenden Sie stattdessen Kaniko, buildah oder einen ähnlichen Build-Service. CodeBuild

Anmerkung

Kubernetes-Cluster, die für die CICD-Verarbeitung verwendet werden, z. B. für die Erstellung von Container-Images, sollten von Clustern isoliert werden, auf denen allgemeinere Workloads ausgeführt werden.

Beschränken Sie die Verwendung von HostPath oder, falls HostPath erforderlich ist, schränken Sie ein, welche Präfixe verwendet werden können, und konfigurieren Sie das Volume als schreibgeschützt

hostPathist ein Volume, das ein Verzeichnis vom Server direkt in den Container einhängt. Selten benötigen Pods diese Art von Zugriff, aber wenn doch, müssen Sie sich der Risiken bewusst sein. Standardmäßig haben Pods, die als Root ausgeführt werden, Schreibzugriff auf das von HostPath bereitgestellte Dateisystem. Dies könnte es einem Angreifer ermöglichen, die Kubelet-Einstellungen zu ändern, symbolische Links zu Verzeichnissen oder Dateien zu erstellen, die nicht direkt vom HostPath offengelegt werden, z. B. /etc/shadow, SSH-Schlüssel zu installieren, auf dem Host bereitgestellte Geheimnisse zu lesen und andere bösartige Dinge. Um die von HostPath ausgehenden Risiken zu minimieren, konfigurieren Sie das als, zum Beispiel: spec.containers.volumeMounts readOnly

volumeMounts:
- name: hostPath-volume
    readOnly: true
    mountPath: /host-path

Sie sollten auch policy-as-code Lösungen verwenden, um die Anzahl der Verzeichnisse, die von hostPath Volumes verwendet werden können, einzuschränken oder die hostPath Nutzung ganz zu verhindern. Sie können die Pod Security Standards-Richtlinien Baseline oder Restricted verwenden, um die Verwendung von zu verhindernhostPath.

Weitere Informationen zu den Gefahren einer privilegierten Eskalation finden Sie im Blog Bad Pods: Kubernetes Pod Privilege Escalation von Seth Art.

Legen Sie Anfragen und Limits für jeden Container fest, um Ressourcenkonflikte und DoS-Angriffe zu vermeiden

Ein Pod ohne Anfragen oder Limits kann theoretisch alle auf einem Host verfügbaren Ressourcen verbrauchen. Wenn zusätzliche Pods auf einem Knoten eingeplant werden, kann es auf dem Knoten zu einer CPU- oder Speicherauslastung kommen, was dazu führen kann, dass das Kubelet Pods beendet oder aus dem Knoten entfernt. Sie können zwar nicht verhindern, dass dies alles zusammen passiert, aber die Festlegung von Anforderungen und Grenzwerten trägt dazu bei, Ressourcenkonflikte zu minimieren und das Risiko zu verringern, das von schlecht geschriebenen Anwendungen ausgeht, die übermäßig viele Ressourcen verbrauchen.

Mit podSpec dieser können Sie Anforderungen und Grenzwerte für CPU und Arbeitsspeicher angeben. Die CPU wird als komprimierbare Ressource angesehen, da sie überlastet sein kann. Speicher ist inkomprimierbar, d. h. er kann nicht von mehreren Containern gemeinsam genutzt werden.

Wenn Sie Anforderungen für CPU oder Arbeitsspeicher angeben, legen Sie im Wesentlichen die Speichermenge fest, die Container garantiert erhalten. Kubernetes aggregiert die Anfragen aller Container in einem Pod, um zu bestimmen, auf welchem Knoten der Pod geplant werden soll. Wenn ein Container die angeforderte Speichermenge überschreitet, kann er beendet werden, wenn der Knoten unter Speicherdruck steht.

Grenzwerte sind die maximale Menge an CPU- und Speicherressourcen, die ein Container verbrauchen darf. Sie entsprechen direkt dem memory.limit_in_bytes Wert der für den Container erstellten Cgroup. Ein Container, der das Speicherlimit überschreitet, wird als OOM beendet. Wenn ein Container sein CPU-Limit überschreitet, wird er gedrosselt.

Anmerkung

Bei der Verwendung von Containern resources.limits wird dringend empfohlen, dass die Nutzung von Container-Ressourcen (auch bekannt als Resource Footprints) datengesteuert und korrekt erfolgt und auf Belastungstests basiert. In Ermangelung eines genauen und vertrauenswürdigen Ressourcenbedarfs kann der Container resources.limits aufgefüllt werden. Er resources.limits.memory könnte beispielsweise um 20 bis 30% höher als die beobachtbaren Höchstwerte aufgefüllt werden, um möglichen Ungenauigkeiten bei der Speicherressourcenbegrenzung Rechnung zu tragen.

Kubernetes verwendet drei Quality of Service (QoS) -Klassen, um die Workloads zu priorisieren, die auf einem Knoten ausgeführt werden. Dazu zählen:

  • garantierte

  • platzfähig

  • bestes Bemühen

Wenn keine Limits und Anfragen festgelegt sind, wird der Pod als Best-Effort (niedrigste Priorität) konfiguriert. Best-Effort-Pods sind die ersten, die beendet werden, wenn nicht genügend Speicher zur Verfügung steht. Wenn Grenzwerte für alle Container innerhalb des Pods festgelegt sind oder wenn die Anfragen und Grenzwerte auf dieselben Werte und nicht gleich 0 festgelegt sind, wird der Pod als garantiert konfiguriert (höchste Priorität). Garantierte Pods werden nicht beendet, es sei denn, sie überschreiten ihre konfigurierten Speichergrenzen. Wenn die Grenzwerte und Anfragen mit unterschiedlichen Werten konfiguriert sind und nicht gleich 0 sind, oder wenn ein Container innerhalb des Pods Grenzwerte festlegt und die anderen keine Grenzwerte für unterschiedliche Ressourcen haben oder keine Grenzwerte für unterschiedliche Ressourcen festgelegt haben, werden die Pods als Burstable (mittlere Priorität) konfiguriert. Für diese Pods gibt es einige Ressourcengarantien, sie können jedoch beendet werden, sobald sie den angeforderten Speicherplatz überschreiten.

Wichtig

Anfragen wirken sich nicht auf den memory_limit_in_bytes Wert der Cgroup des Containers aus. Das Cgroup-Limit ist auf die Menge des auf dem Host verfügbaren Speichers festgelegt. Ein zu niedriger Wert für Anfragen kann jedoch dazu führen, dass der Pod vom Kubelet als Terminierungsziel ausgewählt wird, wenn der Knoten Speicherauslastung ausgesetzt ist.

Klasse Priorität Bedingung Zustand beenden

Garantiert

höchste

Limit = Anfrage! = 0

Überschreite nur die Speichergrenzen

Burst-fähig

Medium

begrenzen! = Anfrage! = 0

Kann beendet werden, wenn der Anforderungsspeicher überschritten wird

Bestes Bemühen

niedrigste

Limit und Anfrage nicht festgelegt

Der Erste, der getötet wird, wenn nicht genügend Speicher zur Verfügung steht

Weitere Informationen zu Ressourcen-QoS finden Sie in der Kubernetes-Dokumentation.

Sie können die Verwendung von Anfragen und Limits erzwingen, indem Sie ein Ressourcenkontingent für einen Namespace festlegen oder einen Grenzbereich erstellen. Mit einem Ressourcenkontingent können Sie die Gesamtmenge der Ressourcen, z. B. CPU und RAM, angeben, die einem Namespace zugewiesen sind. Wenn es auf einen Namespace angewendet wird, müssen Sie Anforderungen und Grenzwerte für alle Container angeben, die in diesem Namespace bereitgestellt werden. Im Gegensatz dazu bieten Ihnen Grenzbereiche eine genauere Kontrolle über die Zuweisung von Ressourcen. Mit Grenzbereichen können Sie CPU min/max - und Speicherressourcen pro Pod oder pro Container innerhalb eines Namespace angeben. Sie können sie auch verwenden, um Standardanforderungs-/Grenzwerte festzulegen, falls keine angegeben sind.

Policy-as-code Lösungen können verwendet werden, um Anfragen und Limits durchzusetzen oder sogar Ressourcenkontingente und Grenzbereiche zu erstellen, wenn Namespaces erstellt werden.

Erlauben Sie keine privilegierte Eskalation

Die privilegierte Eskalation ermöglicht es einem Prozess, den Sicherheitskontext zu ändern, in dem er ausgeführt wird. Sudo ist ein gutes Beispiel dafür, ebenso wie Binärdateien mit dem SUID- oder SGID-Bit. Die privilegierte Eskalation ist im Grunde eine Möglichkeit für Benutzer, eine Datei mit den Rechten eines anderen Benutzers oder einer anderen Gruppe auszuführen. Sie können verhindern, dass ein Container die privilegierte Eskalation verwendet, indem Sie eine policy-as-code mutierende Richtlinie implementieren, die allowPrivilegeEscalation auf false oder durch die Einstellung securityContext.allowPrivilegeEscalation von. podSpec Policy-as-code Richtlinien können auch verwendet werden, um zu verhindern, dass API-Serveranfragen erfolgreich sind, wenn falsche Einstellungen erkannt werden. Pod-Sicherheitsstandards können auch verwendet werden, um zu verhindern, dass Pods die Rechteeskalation verwenden.

Deaktivieren Sie ServiceAccount Token-Mounts

Für Pods, die nicht auf die Kubernetes-API zugreifen müssen, können Sie das automatische Mounten eines ServiceAccount Tokens in einer Pod-Spezifikation oder für alle Pods, die einen bestimmten verwenden, deaktivieren. ServiceAccount

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-automount
spec:
  automountServiceAccountToken: false
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-no-automount
automountServiceAccountToken: false

Deaktivieren Sie die Diensterkennung

Für Pods, die keine Clusterdienste suchen oder aufrufen müssen, können Sie die Menge der an einen Pod übergebenen Informationen reduzieren. Sie können die DNS-Richtlinie des Pods so festlegen, dass CoreDNS nicht verwendet wird und Dienste im Namespace des Pods nicht als Umgebungsvariablen verfügbar gemacht werden. Weitere Informationen zu Service-Links finden Sie in den Kubernetes-Dokumenten zu Umgebungsvariablen. Der Standardwert für die DNS-Richtlinie eines Pods ist "ClusterFirst", wodurch Cluster-DNS verwendet wird, während der nicht standardmäßige Wert „Default“ die DNS-Auflösung des zugrunde liegenden Knotens verwendet. Weitere Informationen finden Sie in den Kubernetes-Dokumenten zur Pod-DNS-Richtlinie.

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-service-info
spec:
    dnsPolicy: Default # "Default" is not the true default value
    enableServiceLinks: false

Konfigurieren Sie Ihre Images mit einem schreibgeschützten Root-Dateisystem

Wenn Sie Ihre Bilder mit einem schreibgeschützten Root-Dateisystem konfigurieren, wird verhindert, dass ein Angreifer eine Binärdatei auf dem Dateisystem überschreibt, das Ihre Anwendung verwendet. Wenn Ihre Anwendung in das Dateisystem schreiben muss, sollten Sie in Erwägung ziehen, in ein temporäres Verzeichnis zu schreiben oder ein Volume anzuhängen und zu mounten. Sie können dies erzwingen, indem Sie die Pods SecurityContext wie folgt einstellen:

...
securityContext:
  readOnlyRootFilesystem: true
...

Policy-as-code und Pod-Sicherheitsstandards können verwendet werden, um dieses Verhalten durchzusetzen.

Gemäß Windows können Container in Kubernetes securityContext.readOnlyRootFilesystem nicht auf einen Container eingestellt werden, true der unter Windows ausgeführt wird, da Schreibzugriff erforderlich ist, damit Registrierungs- und Systemprozesse innerhalb des Containers ausgeführt werden können.

Tools und Ressourcen