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](runtime-security.md) 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](https://github.com/bottlerocket-os/bottlerocket/), einem speziellen Betriebssystem von AWS, das für den Betrieb von Linux-Containern entwickelt wurde. Es umfasst eine reduzierte Angriffsfläche, ein Disk-Image, das beim Booten verifiziert wird, und erzwungene Zugriffsgrenzen mithilfe von SELinux.
Verwenden Sie alternativ das für [EKS optimierte AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-amis.html) 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](https://github.com/aws-samples/amazon-eks-ami-rhel) 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 STIG-konforme benutzerdefinierte EKS-AMIs zu erstellen.
### 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 die EKS-optimierten AMIs verwenden, empfiehlt es sich, diese Host-Betriebssystem-Images mit den neuesten Sicherheitspatches auf dem neuesten Stand zu halten.
Schauen Sie bei den EKS-optimierten AMIs regelmäßig im [and/or [CHANGELOG-Versionshinweise-Channel](https://github.com/awslabs/amazon-eks-ami/releases)](https://github.com/awslabs/amazon-eks-ami/blob/master/CHANGELOG.md) nach und automatisieren Sie den Rollout aktualisierter Worker-Node-Images in Ihrem Cluster.
### Behandeln Sie Ihre Infrastruktur als unveränderlich und automatisieren Sie den Austausch Ihrer Worker-Knoten
Anstatt Upgrades vor Ort durchzuführen, tauschen Sie Ihre Mitarbeiter aus, sobald 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](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) 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. `eksctl`verfü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](https://www.cisecurity.org/benchmark/kubernetes/) 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](https://github.com/aquasecurity/kube-bench) auf einem EKS-Cluster ausführen, folgen Sie [diesen](https://github.com/aquasecurity/kube-bench/blob/main/docs/running.md#running-cis-benchmark-in-an-eks-cluster) Anweisungen von Aqua Security. Weitere Informationen finden Sie unter [Einführung in den CIS Amazon EKS Benchmark](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark/).
### Minimiert den Zugriff auf Worker-Knoten
Anstatt den SSH-Zugriff zu aktivieren, verwenden Sie [SSM Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html), wenn Sie per Fernzugriff 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-Instances mithilfe von IAM steuern. Darüber hinaus bietet er einen Audit-Trail und ein Protokoll der Befehle, die auf der Instance ausgeführt wurden.
Seit dem 19. August 2020 unterstützen Managed Node Groups benutzerdefinierte 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](https://github.com/aws-samples/ssm-agent-daemonset-installer) 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 `*` Berechtigungen`ssm: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](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html) 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](https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-create-iam-instance-profile.html#create-iam-instance-profile-ssn-logging).
### 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](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) verwenden, um nach unbeabsichtigten Netzwerkzugriffen auf Ihre Knoten und nach Sicherheitslücken in den zugrunde liegenden Amazon EC2 EC2-Instances zu suchen.
Amazon Inspector kann CVE-Daten (Common Vulnerabilities and Exposures) für Ihre Amazon EC2-Instances nur bereitstellen, wenn der Amazon EC2 Systems Manager (SSM) -Agent installiert und aktiviert ist. Dieser Agent ist auf mehreren [Amazon Machine Images (AMIs)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) vorinstalliert, einschließlich [EKS-optimierter Amazon Linux-AMIs](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html). Unabhängig vom Status des SSM-Agenten werden alle Ihre Amazon EC2 EC2-Instances auf Probleme mit der Netzwerkerreichbarkeit überprüft. Weitere Informationen zur Konfiguration von Scans für Amazon EC2 finden Sie unter [Scannen von Amazon EC2 EC2-Instances](https://docs.aws.amazon.com/inspector/latest/user/enable-disable-scanning-ec2.html).
**Wichtig**
Inspector kann nicht auf der Infrastruktur ausgeführt werden, die für den Betrieb von Fargate-Pods verwendet wird.
## Alternativen
### Führen Sie SELinux aus
**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, obligatorische 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. Auf EKS kann SELinux verwendet werden, um zu verhindern, dass Container gegenseitig auf die Ressourcen zugreifen.
[Die SELinux-Richtlinien für Container sind im Paket container-selinux definiert.](https://github.com/containers/container-selinux) 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 in SELinux Ihr eigenes Profil erstellen, das einem Container Berechtigungen für bestimmte Bereiche des Dateisystems gewährt. Dies ist PSPs insofern ähnlich, als Sie unterschiedliche Profile für verschiedene erstellen können. containers/pods 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 | Description |
| --- | --- | --- |
| `container_connect_any` | `off` | Erlaubt 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 Label`container_var_lib_t`. Eine vollständige Liste der Standard-Labels finden Sie in der [Datei container.fc](https://github.com/containers/container-selinux/blob/master/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 den `:z` Wert oder angeben.
+ `:z`benennt die Dateien neu, sodass der Container read/write
+ `:Z`wird die Dateien neu beschriften, sodass **nur** der Container read/write
```
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, var/log von/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 [Beispiel-AMIs für Amazon EKS](https://github.com/aws-samples/amazon-eks-custom-amis) implementiert, für die SELinux auf CentOS 7 und RHEL 7 konfiguriert ist. 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
+ [SELinux Kubernetes RBAC und Versandsicherheitsrichtlinien für Anwendungen On-prem ](https://platform9.com/blog/selinux-kubernetes-rbac-and-shipping-security-policies-for-on-prem-applications/)
+ [Iteratives Härten von Kubernetes](https://jayunit100.blogspot.com/2019/07/iterative-hardening-of-kubernetes-and.html)
+ [Audit2Allow](https://linux.die.net/man/1/audit2allow)
+ [SEAlert](https://linux.die.net/man/8/sealert)
+ [Generate SELinux-Richtlinien für Container with Udica](https://www.redhat.com/en/blog/generate-selinux-policies-containers-with-udica) beschreibt ein Tool, das Container-Spezifikationsdateien für Linux-Funktionen, -Ports und Mount-Points durchsucht und eine Reihe von SELinux-Regeln generiert, die den ordnungsgemäßen Betrieb des Containers ermöglichen
+ [AMI Hardening-Playbooks](https://github.com/aws-samples/amazon-eks-custom-amis#hardening) zum Härten des Betriebssystems zur Erfüllung verschiedener regulatorischer Anforderungen
+ [Keiko Upgrade Manager](https://github.com/keikoproj/upgrade-manager) ist ein Open-Source-Projekt von Intuit, das die Rotation von Worker-Knoten orchestriert.
+ [Sysdig Secure](https://sysdig.com/products/kubernetes-security/)
+ [eksctl](https://eksctl.io/)