Schutz der Infrastruktur (Hosts) - Amazon EKS
EmpfehlungenAlternativenTools 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.

Schutz der Infrastruktur (Hosts)

So wichtig es ist, Ihre Container-Images zu sichern, ist es ebenso wichtig, die Infrastruktur zu schützen, auf der sie ausgeführt werden. In diesem Abschnitt werden verschiedene Möglichkeiten zur Minderung von Risiken untersucht, die von Angriffen ausgehen, die direkt gegen den Host gestartet werden. Diese Richtlinien sollten zusammen mit den Richtlinien verwendet werden, die im Abschnitt Runtime Security beschrieben werden.

Empfehlungen

Verwenden Sie ein Betriebssystem, das für die Ausführung von Containern optimiert ist

Erwägen Sie die Verwendung von Flatcar Linux, Project Atomic, RancherOS und Bottlerocket, einem speziellen Betriebssystem von AWS, das für den Betrieb von Linux-Containern entwickelt wurde. Es umfasst eine reduzierte Angriffsfläche, ein Festplatten-Image, das beim Systemstart verifiziert wird, und erzwungene Zugriffsgrenzen mithilfe von. SELinux

Verwenden Sie alternativ das für EKS optimierte AMI für Ihre Kubernetes-Worker-Knoten. Das für EKS optimierte AMI wird regelmäßig veröffentlicht und enthält eine minimale Anzahl von Betriebssystempaketen und Binärdateien, die für die Ausführung Ihrer containerisierten Workloads erforderlich sind.

In der Amazon EKS AMI RHEL Build Specification finden Sie ein Beispielkonfigurationsskript, mit dem Sie mithilfe von Hashicorp Packer ein benutzerdefiniertes Amazon EKS-AMI erstellen können, das auf Red Hat Enterprise Linux ausgeführt wird. Dieses Skript kann weiter genutzt werden, um benutzerdefinierte STIG-konforme EKS-Dateien zu erstellen. AMIs

Halten Sie das Betriebssystem Ihres Worker-Nodes auf dem neuesten Stand

Unabhängig davon, ob Sie ein containeroptimiertes Host-Betriebssystem wie Bottlerocket oder ein größeres, aber dennoch minimalistisches Amazon Machine Image wie das EKS-optimierte verwenden, empfiehlt es sich AMIs, diese Host-Betriebssystem-Images mit den neuesten Sicherheitspatches auf dem neuesten Stand zu halten.

Für die EKS-optimierte AMIs Version sollten Sie regelmäßig den CHANGELOG - und/oder Versionshinweise-Channel überprüfen und den Rollout aktualisierter Worker-Node-Images in Ihrem Cluster automatisieren.

Behandeln Sie Ihre Infrastruktur als unveränderlich und automatisieren Sie den Austausch Ihrer Worker-Knoten

Anstatt Upgrades vor Ort durchzuführen, sollten Sie Ihre Mitarbeiter austauschen, wenn ein neuer Patch oder ein neues Update verfügbar ist. Dies kann auf verschiedene Arten angegangen werden. Sie können entweder Instances zu einer vorhandenen Autoscaling-Gruppe hinzufügen, indem Sie das neueste AMI verwenden, während Sie Knoten sequenziell sperren und entleeren, bis alle Knoten in der Gruppe durch das neueste AMI ersetzt wurden. Alternativ können Sie Instances zu einer neuen Knotengruppe hinzufügen, während Sie nacheinander Knoten aus der alten Knotengruppe sperren und entfernen, bis alle Knoten ersetzt wurden. Die von EKS verwalteten Knotengruppen verwenden den ersten Ansatz und zeigen in der Konsole eine Meldung an, dass Sie Ihre Worker aktualisieren müssen, sobald ein neues AMI verfügbar ist. eksctlverfügt auch über einen Mechanismus zum Erstellen von Knotengruppen mit dem neuesten AMI und zum ordnungsgemäßen Sperren und Entleeren von Pods aus Knotengruppen, bevor die Instances beendet werden. Wenn Sie sich für eine andere Methode zum Austausch Ihrer Worker-Knoten entscheiden, wird dringend empfohlen, den Prozess zu automatisieren, um menschliche Aufsicht zu minimieren, da Sie wahrscheinlich regelmäßig Worker austauschen müssen, sobald neue veröffentlicht updates/patches werden und wenn die Steuerungsebene aktualisiert wird.

Mit EKS Fargate aktualisiert AWS die zugrunde liegende Infrastruktur automatisch, sobald Updates verfügbar sind. Oft kann dies problemlos erfolgen, aber es kann vorkommen, dass ein Update dazu führt, dass Ihr Pod verschoben wird. Daher empfehlen wir, Bereitstellungen mit mehreren Replikaten zu erstellen, wenn Sie Ihre Anwendung als Fargate-Pod ausführen.

Führen Sie kube-bench regelmäßig aus, um die Einhaltung der CIS-Benchmarks für Kubernetes zu überprüfen

kube-bench ist ein Open-Source-Projekt von Aqua, das Ihren Cluster anhand der CIS-Benchmarks für Kubernetes bewertet. Der Benchmark beschreibt die besten Methoden zur Sicherung nicht verwalteter Kubernetes-Cluster. Der CIS Kubernetes Benchmark umfasst die Steuerungsebene und die Datenebene. Da Amazon EKS eine vollständig verwaltete Kontrollebene bietet, sind nicht alle Empfehlungen des CIS Kubernetes Benchmark zutreffend. Um sicherzustellen, dass dieser Umfang die Implementierung von Amazon EKS widerspiegelt, hat AWS den CIS Amazon EKS Benchmark erstellt. Der EKS-Benchmark basiert auf CIS Kubernetes Benchmark und enthält zusätzliche Beiträge aus der Community mit spezifischen Überlegungen zur Konfiguration von EKS-Clustern.

Wenn Sie Kube-Bench auf einem EKS-Cluster ausführen, folgen Sie diesen Anweisungen von Aqua Security. Weitere Informationen finden Sie unter Einführung in den CIS Amazon EKS Benchmark.

Minimiert den Zugriff auf Worker-Knoten

Anstatt den SSH-Zugriff zu aktivieren, verwenden Sie SSM Session Manager, wenn Sie remote auf einen Host zugreifen müssen. Im Gegensatz zu SSH-Schlüsseln, die verloren gehen, kopiert oder gemeinsam genutzt werden können, können Sie mit Session Manager den Zugriff auf EC2 Instanzen mithilfe von IAM steuern. Darüber hinaus bietet er einen Audit-Trail und ein Protokoll der Befehle, die auf der Instanz ausgeführt wurden.

Seit dem 19. August 2020 unterstützen verwaltete Knotengruppen benutzerdefinierte Vorlagen AMIs und EC2 Startvorlagen. Auf diese Weise können Sie den SSM-Agenten in das AMI einbetten oder ihn installieren, während der Worker-Node gebootet wird. Wenn Sie das optimierte AMI oder die Startvorlage der ASG nicht ändern möchten, können Sie den SSM-Agenten DaemonSet wie in diesem Beispiel mit einem installieren.

Minimale IAM-Richtlinie für SSM-basierten SSH-Zugriff

Die von AmazonSSMManagedInstanceCore AWS verwaltete Richtlinie enthält eine Reihe von Berechtigungen, die für SSM Session Manager/SSM nicht erforderlich sind, RunCommand wenn Sie nur den SSH-Zugriff vermeiden möchten. Besonders besorgniserregend sind die * Berechtigungenssm:GetParameter(s), für die die Rolle den Zugriff auf alle Parameter im Parameter Store ermöglichen würde (auch SecureStrings wenn der von AWS verwaltete KMS-Schlüssel konfiguriert ist).

Die folgende IAM-Richtlinie enthält die Mindestberechtigungen, um den Knotenzugriff über SSM Systems Manager zu ermöglichen.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableAccessViaSSMSessionManager",
      "Effect": "Allow",
      "Action": [
        "ssmmessages:OpenDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:CreateControlChannel",
        "ssm:UpdateInstanceInformation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnableSSMRunCommand",
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ec2messages:SendReply",
        "ec2messages:GetMessages",
        "ec2messages:GetEndpoint",
        "ec2messages:FailMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:AcknowledgeMessage"
      ],
      "Resource": "*"
    }
  ]
}

Wenn diese Richtlinie eingerichtet und das Session Manager-Plug-In installiert ist, können Sie dann Folgendes ausführen

aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

um auf den Knoten zuzugreifen.

Anmerkung

Möglicherweise möchten Sie auch Berechtigungen hinzufügen, um die Session Manager-Protokollierung zu aktivieren.

Stellen Sie Worker in privaten Subnetzen bereit

Durch den Einsatz von Mitarbeitern in privaten Subnetzen minimieren Sie deren Gefährdung durch das Internet, wo Angriffe häufig ihren Ursprung haben. Ab dem 22. April 2020 wird die Zuweisung öffentlicher IP-Adressen zu Knoten in verwalteten Knotengruppen durch das Subnetz gesteuert, in dem sie bereitgestellt werden. Zuvor wurde Knoten in einer verwalteten Knotengruppe automatisch eine öffentliche IP zugewiesen. Wenn Sie sich dafür entscheiden, Ihre Worker-Knoten in öffentlichen Subnetzen bereitzustellen, implementieren Sie restriktive AWS-Sicherheitsgruppenregeln, um deren Gefährdung zu begrenzen.

Führen Sie Amazon Inspector aus, um Hosts auf Risiken, Sicherheitslücken und Abweichungen von bewährten Methoden zu untersuchen

Sie können Amazon Inspector verwenden, um nach unbeabsichtigten Netzwerkzugriffen auf Ihre Knoten und nach Sicherheitslücken in den zugrunde liegenden EC2 Amazon-Instances zu suchen.

Amazon Inspector kann CVE-Daten (Common Vulnerabilities and Exposures) für Ihre EC2 Amazon-Instances nur bereitstellen, wenn der Amazon EC2 Systems Manager (SSM) -Agent installiert und aktiviert ist. Dieser Agent ist auf mehreren Amazon Machine Images (AMIs) vorinstalliert, einschließlich EKS-optimiertem Amazon Linux AMIs. Unabhängig vom Status des SSM-Agenten werden alle Ihre EC2 Amazon-Instances auf Probleme mit der Netzwerkerreichbarkeit überprüft. Weitere Informationen zur Konfiguration von Scans für Amazon EC2 finden Sie unter EC2 Amazon-Instances scannen.

Wichtig

Inspector kann nicht auf der Infrastruktur ausgeführt werden, die für den Betrieb von Fargate-Pods verwendet wird.

Alternativen

Lauf SELinux

Anmerkung

Verfügbar auf Red Hat Enterprise Linux (RHEL), CentOS, Bottlerocket und Amazon Linux 2023

SELinux bietet eine zusätzliche Sicherheitsebene, um Container voneinander und vom Host zu isolieren. SELinux ermöglicht es Administratoren, verbindliche Zugriffskontrollen (MAC) für jeden Benutzer, jede Anwendung, jeden Prozess und jede Datei durchzusetzen. Stellen Sie sich das als Backstop vor, der die Operationen, die anhand einer Reihe von Labels ausgeführt werden können, auf bestimmte Ressourcen beschränkt. SELinux Kann auf EKS verwendet werden, um zu verhindern, dass Container gegenseitig auf die Ressourcen zugreifen.

SELinux Container-Richtlinien sind im Paket container-selinux definiert. Docker CE benötigt dieses Paket (zusammen mit seinen Abhängigkeiten), damit die von Docker (oder anderen Container-Laufzeiten) erstellten Prozesse und Dateien mit eingeschränktem Systemzugriff ausgeführt werden können. Container nutzen das container_t Label, das ein Alias für ist. svirt_lxc_net_t Diese Richtlinien verhindern effektiv, dass Container auf bestimmte Funktionen des Hosts zugreifen.

Wenn Sie SELinux für Docker konfigurieren, kennzeichnet Docker Workloads automatisch container_t als Typ und weist jedem Container eine eindeutige MCS-Ebene zu. Dadurch werden Container voneinander isoliert. Wenn Sie lockerere Einschränkungen benötigen, können Sie Ihr eigenes Profil erstellen SElinux , das einem Container Berechtigungen für bestimmte Bereiche des Dateisystems gewährt. Dies ist PSPs insofern vergleichbar, als Sie unterschiedliche Profile für verschiedene Container/Pods erstellen können. Sie können beispielsweise ein Profil für allgemeine Workloads mit einer Reihe von restriktiven Kontrollen und ein anderes für Dinge haben, die privilegierten Zugriff erfordern.

SELinux for Containers verfügt über eine Reihe von Optionen, die konfiguriert werden können, um die Standardeinschränkungen zu ändern. Die folgenden SELinux Booleschen Werte können je nach Bedarf aktiviert oder deaktiviert werden:

Boolesch Standard Beschreibung

container_connect_any

off

Erlauben Sie Containern den Zugriff auf privilegierte Ports auf dem Host. Zum Beispiel, wenn Sie einen Container haben, der Ports 443 oder 80 auf dem Host zuordnen muss.

container_manage_cgroup

off

Erlauben Sie Containern, die Cgroup-Konfiguration zu verwalten. Für einen Container, auf dem systemd ausgeführt wird, muss dies beispielsweise aktiviert sein.

container_use_cephfs

off

Erlaubt Containern, ein Ceph-Dateisystem zu verwenden.

Standardmäßig ist es Containern erlaubt, die meisten Inhalte zu read/execute /usr unterschreiben und daraus /etc zu lesen. Die Dateien unter /var/lib/docker und /var/lib/containers haben das Labelcontainer_var_lib_t. Eine vollständige Liste der Standard-Labels finden Sie in der Datei container.fc.

docker container run -it \
  -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \
  centos:7 cat /host/repositories.json
# cat: /host/repositories.json: Permission denied

docker container run -it \
  -v /etc/passwd:/host/etc/passwd \
  centos:7 cat /host/etc/passwd
# cat: /host/etc/passwd: Permission denied

Dateien, die mit gekennzeichnet sind, container_file_t sind die einzigen Dateien, die von Containern beschreibbar sind. Wenn Sie möchten, dass ein Volume-Mount beschreibbar ist, müssen Sie :Z am Ende :z oder angeben.

  • :zbenennt die Dateien neu, sodass der Container lesen/schreiben kann

  • :Zbenennt die Dateien neu, sodass nur der Container lesen/schreiben kann

ls -Z /var/lib/misc
# -rw-r--r--. root root system_u:object_r:var_lib_t:s0   postfix.aliasesdb-stamp

docker container run -it \
  -v /var/lib/misc:/host/var/lib/misc:z \
  centos:7 echo "Relabeled!"

ls -Z /var/lib/misc
#-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp
docker container run -it \
  -v /var/log:/host/var/log:Z \
  fluentbit:latest

In Kubernetes ist das Umetikettieren etwas anders. Anstatt Docker die Dateien automatisch umbenennen zu lassen, können Sie ein benutzerdefiniertes MCS-Label angeben, um den Pod auszuführen. Volumes, die das Umbenennen unterstützen, werden automatisch neu beschriftet, sodass auf sie zugegriffen werden kann. Pods mit einem passenden MCS-Label können auf das Volume zugreifen. Wenn Sie eine strikte Isolierung benötigen, legen Sie für jeden Pod ein anderes MCS-Label fest.

securityContext:
  seLinuxOptions:
    # Provide a unique MCS label per container
    # You can specify user, role, and type also
    # enforcement based on type and level (svert)
    level: s0:c144:c154

In diesem Beispiel s0:c144:c154 entspricht dies einem MCS-Label, das einer Datei zugewiesen ist, auf die der Container zugreifen darf.

Auf EKS könnten Sie Richtlinien erstellen, die die Ausführung von privilegierten Containern ermöglichen, wie FluentD, und eine SELinux Richtlinie erstellen, die es ermöglicht, aus /var/log auf dem Host zu lesen, ohne das Hostverzeichnis neu benennen zu müssen. Pods mit derselben Bezeichnung können auf dieselben Host-Volumes zugreifen.

Wir haben ein Beispiel AMIs für Amazon EKS implementiert, das auf CentOS 7 und RHEL 7 SELinux konfiguriert wurde. Diese AMIs wurden entwickelt, um Beispielimplementierungen zu demonstrieren, die den Anforderungen stark regulierter Kunden entsprechen.

Warnung

SELinux ignoriert Container, bei denen der Typ nicht begrenzt ist.

Tools und Ressourcen