Sicherheit - Best Practices

Best Practice: Risikohöhe planen

Es wird empfohlen, die folgenden Fragen zu beantworten, bevor Sie einen Sicherheitsplan für die Cluster implementieren, die Sie mit der Kubernetes-Engine erstellen:

• Wie viel Internet-Exposition möchten Cluster haben?
• Wie planen Sie, Workloads intern im VCN und/oder extern im Internet verfügbar zu machen?
• Wie planen Sie die Skalierung von Workloads?
• Welche Oracle-Services werden vom Cluster genutzt?

Nachdem Sie die oben genannten Fragen beantwortet haben, sollten Sie die folgenden Best Practices berücksichtigen:

• Best Practice: Private Cluster erstellen

  Wir empfehlen, dass Sie VCN-native Cluster mit dem Kubernetes-API-Endpunkt in einem privaten Subnetz erstellen, wenn Sie Workloads nur intern im VCN und nicht im Internet verfügbar machen möchten. Solche Cluster werden manchmal auch als private Cluster bezeichnet.

  Wenn Sie private Cluster konfigurieren, befinden sich alle Control-Plane-Komponenten (einschließlich des Kubernetes-API-Endpunkts des Clusters) in einem privaten RFC 1918-Netzwerkspeicher. Daher ist der Zugriff begrenzt, und der gesamte Traffic bleibt in den Netzwerken von Oracle. Sie können den Zugriff auf die Kubernetes-API auf ein bestimmtes VCN sperren.

  Wenn Sie keine privaten Cluster verwenden, weist der Kubernetes-API-Endpunkt des Clusters eine öffentliche IPv4-Adresse auf, und der gesamte Traffic zur API (einschließlich Traffic von den Knotenpools des Clusters) wird über den öffentlichen Netzwerkspeicher geleitet.

  Siehe Ankündigung privater Kubernetes-Cluster.

• Best Practice: Alle Anwendungen in privaten Subnetzen platzieren

  Wir empfehlen, dass Sie Worker-Knoten-Compute-Instanzen, die Anwendungs-Workloads in privaten Subnetzen ausführen, platzieren und Load Balancer für den Zugriff auf sie einrichten, wenn Sie das Risiko eines Service im Internet reduzieren möchten.

  Durch die Isolierung von Serviceinstanzen aus dem Internet wird die Angriffsfläche eines Service reduziert. Die meisten Serviceinstanzen benötigen keine direkte Internetverbindung.

  Siehe Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment.

• Best Practice: Clustertraffic mit Netzwerksicherheitsgruppen einschränken

  Es wird empfohlen, Sicherheitsregeln in Netzwerksicherheitsgruppen (und nicht in Sicherheitslisten) für das VCN zu definieren, in dem Sie Cluster erstellen und bereitstellen möchten.

  Kubernetes Engine erstellt standardmäßig erforderliche Sicherheitsregeln. Sie können diese jedoch ändern, um Ihre spezifischen Anforderungen zu erfüllen.

  Siehe Sicherheitsregelkonfiguration in Netzwerksicherheitsgruppen und/oder Sicherheitslisten.

Best Practice: Sicherheitspatches regelmäßig einspielen

Es wird empfohlen, das Betriebssystem, das auf Worker-Knoten ausgeführt wird, regelmäßig zu aktualisieren, um die neuesten Sicherheitspatches einzuspielen.

Worker-Knoten in Clustern, die von der Kubernetes-Engine erstellt werden, führen ein gehärtetes Linux-Image aus.

Es ist wichtig, das Betriebssystem des Worker-Knotens geschützt und sicher zu halten, da Services, die auf Worker-Knoten ausgeführt werden, Containerlaufzeit, Kubelet und Kube-Proxy umfassen.

Eine weitere gute Vorgehensweise ist die Verwendung der Center for Internet Security (CIS) Kubernetes-Benchmark für Worker-Knoten.

Siehe Worker-Knoten mit aktualisierten Attributen erstellen.

Best Practice: Eine Kombination aus Kubernetes-Netzwerk-Policys und Netzwerksicherheitsgruppen (NSGs) verwenden

Wir empfehlen, die Implementierung von Kubernetes-Netzwerkrichtlinien in Kombination mit OCI-Netzwerksicherheitsgruppen (empfohlen) und/oder Sicherheitslisten zu erwägen.

Eine Kombination aus Kubernetes-Netzwerk-Policys (zur Sicherung der Netzwerkkommunikation auf Podebene) und NSGs und/oder OCI-Sicherheitslisten (zur Sicherung der Netzwerkkommunikation auf Hostebene) kann die beste Netzwerksicherheit bieten.

Siehe Netzwerksicherheit.

Best Practice: Netzwerksicherheitsgruppen (NSGs) in Verbindung mit Infrastructure-as-Code-Tools (wie Terraform) verwenden

Wir empfehlen, Sicherheitsregeln in Netzwerksicherheitsgruppen (NSGs) anstelle von Sicherheitslisten zu verwenden, wenn Sie einen Load Balancing Controller in Verbindung mit Infrastructure-as-Code-Tools wie Terraform implementieren.

Um Kubernetes in großem Maßstab zu betreiben, verwenden Sie in der Regel Infrastructure-as-Code-Tools wie Terraform, um den Status von Infrastrukturressourcen zu verfolgen. Beispiel: Um die Infrastruktur im ursprünglichen und beabsichtigten Status beizubehalten, führen Sie in der Regel eine Terraform-Konfiguration aus und führen sie erneut aus. Ein potenzieller Konflikt entsteht jedoch für Kubernetes-Services vom Typ LoadBalancer, wenn der Cloud-Controller-Manager Sicherheitsregeln in der Sicherheitsliste hinzufügt oder aktualisiert, die ein Subnetz verwendet. Änderungen an Sicherheitsregeln in einer Sicherheitsliste werden in der Terraform-Konfiguration nicht berücksichtigt. Daher werden Änderungen an den Sicherheitsregeln in der Sicherheitsliste bei der nächsten Ausführung von Terraform als Abweichung vom ursprünglichen Status gekennzeichnet und verworfen, wenn Sie die Terraform-Konfiguration anwenden. Ohne die Sicherheitsregeln verlaufen Anwendungen, die in einem Cluster bereitgestellt werden, möglicherweise nicht erfolgreich, weil der Load Balancer oder Network Load Balancer, der den Service vom Typ LoadBalancer durch Provisioning bereitstellt, Traffic nicht verarbeiten oder mit Knoten kommunizieren kann, die die Anwendungspods hosten.

Sie können den Cloud-Controller-Manager so konfigurieren, dass er die Sicherheitsregeln in der Sicherheitsliste eines Subnetzes nicht verwaltet oder nur Egress-Sicherheitsregeln für den Load Balancer oder Network Load Balancer verwaltet. In beiden Fällen müssen Sie jedoch jedes Mal, wenn ein neuer Service im Cluster bereitgestellt wird, ausgewählte Ports manuell konfigurieren oder den Knotenportbereich insgesamt öffnen. Keine der beiden Lösungen ist ideal, da eine manuelle Arbeit zur Laufzeit beinhaltet und die andere eine potenzielle Sicherheitslücke einführt.

Um zu vermeiden, dass der Cloud-Controller-Manager eine Sicherheitslistenressource durch Hinzufügen oder Aktualisieren von Sicherheitsregeln verändert und diese Änderungen anschließend verworfen werden, wenn Sie eine Terraform-Konfiguration anwenden, wird daher empfohlen, dass der Cloud-Controller-Manager NSGs verwendet. Für eine NSG definierte Sicherheitsregeln sind Ressourcen mit ihren eigenen OCIDs und unabhängig von der NSG selbst. Da die Änderung von NSG-Sicherheitsregeln die NSG-Ressource selbst nicht mutiert, werden keine Änderungen verworfen, wenn Sie eine Terraform-Konfiguration anwenden.

Weitere Informationen finden Sie unter Sicherheitsregeln in NSGs und Sicherheitslisten mit der Annotation oci.oraclecloud.com/security-rule-management-mode verwalten.

Best Practice: Geheimnisse und Zertifikate regelmäßig rotieren

Wir empfehlen, dass Sie kurze Lebensdauer für Secrets, Zugangsdaten und Zertifikate festlegen und deren Rotation automatisieren.

Best Practice: Alle Anwendungen als nicht privilegierter Benutzer ausführen

Es wird empfohlen, alle Anwendungen als nicht privilegierter Benutzer auszuführen. Dies ist auch eine Anforderung in einer Reihe von Regulierungsstandards.

Die Ausführung von Anwendungen als nicht privilegierter Benutzer stellt sicher, dass ein Angreifer, wenn er eine Sicherheitslücke ausnutzt (z. B. eine Sicherheitslücke bei der Remotecodeausführung), auf den eingeschränkten Zugriff beschränkt ist, der dem nicht privilegierten Benutzer gewährt wird. Der Angreifer wird es auch schwieriger finden, einen Angriff zu eskalieren, um zusätzliche Berechtigungen zu erhalten, aus einem Container auszubrechen oder Root-Zugriff über einen Kernel-Bug zu erhalten.

Best Practice: Behältnisse als unveränderlich behandeln

Es wird empfohlen, Container-Root-Dateisysteme als schreibgeschützt zu definieren. Wenn Sie die Aktualisierung von Bibliotheken und Binärdateien im Root-Dateisystem eines Containers zulassen, machen Sie das gesamte Cluster anfällig für Angriffe.

Die flüchtige Natur von Containern bietet erhebliche Sicherheitsvorteile. Da Anwendungen und ihre unmittelbare Umgebung als Ganzes bereitgestellt und aktualisiert werden, sind persistente Angriffe auf das Gesamtsystem schwieriger. Die Verhinderung einer Änderung des Root-Dateisystems stärkt die Sicherheit, indem sowohl die Wahrscheinlichkeit von Bedrohungen verringert als auch ihre potenziellen Auswirkungen verringert werden.

Best Practice: Sie sollten die SSL-Verarbeitung an Ingress-Controller oder Load Balancer auslagern (sofern zulässig)

Wir empfehlen, dass Sie die SSL-Verarbeitung an Ingress-Controller oder Load Balancer auslagern, wenn die Netzwerksicherheits-Policy Ihrer Organisation Ihnen die Flexibilität bietet.

Ingress-Controller (z.B. Traefik, NGINX Open Source) ermöglichen es Ihnen, HTTP/S-Traffic, der von außerhalb des Clusters ausgeht, intelligent an Services weiterzuleiten, die im Cluster ausgeführt werden. Der Oracle Cloud Infrastructure Load Balancer-Service unterstützt Transportverschlüsselungsprotokolle (SSL und TLS), um Daten während der Übertragung zu verschlüsseln.

Verschlüsselter Traffic kann an verschiedenen Stellen im Netzwerk beendet werden (z.B. am Load Balancer, in der Ingress-Ressource, im Pod). Wie und wo Sie SSL-Verbindungen beenden, hängt letztlich von der Netzwerksicherheitsrichtlinie Ihrer Organisation ab. Beispiel: Wenn die Netzwerksicherheits-Policy Ihrer Organisation eine Ende-zu-Ende-Verschlüsselung erfordert, muss der Traffic im Pod entschlüsselt werden. Durch die Entschlüsselung des Traffics wird der Pod zusätzlich belastet, da der Pod Zyklen für den anfänglichen Handshake ausgeben muss und die SSL-/TLS-Verarbeitung sehr CPU-intensiv ist. Wenn die Netzwerksicherheits-Policy Ihrer Organisation Ihnen die Flexibilität bietet, können Sie die SSL-Verarbeitung daher an den Ingress-Controller oder den Load Balancer auslagern.

Best Practices für Auditing, Logging und Überwachung

Wenn Sie Auditing, Logging und Monitoring aktivieren, sollten Sie die folgenden Best Practices berücksichtigen:

• Best Practice: Logs regelmäßig prüfen

  Es wird empfohlen, sowohl die Kubernetes-API-Serverauditlogs als auch die Anwendungslogs von Anwendungen, die auf Worker-Knoten im Cluster ausgeführt werden, regelmäßig zu prüfen. Wenn Sie die Logs regelmäßig prüfen, können Sie Bedrohungen oder Sicherheitslücken im Cluster identifizieren.

  Siehe Kubernetes-Cluster beobachten.

• Best Practice: Auditlogging aktivieren

  Es wird empfohlen, das Auditlogging zu aktivieren und die Auditlogs für zukünftige Analysen im Falle eines Kompromisses in einem sicheren Repository zu speichern.

  Siehe Auditlogs für Kubernetes-API-Server anzeigen

• Best Practice: Clusterbasiertes Kubernetes-Logging verwenden

  Es wird empfohlen, das clusterbasierte Kubernetes-Logging zu verwenden, um die Containeraktivität in einem zentralen Logging-Subsystem aufzuzeichnen. Die Standardausgabe und die Standardfehlerausgabe jedes Containers in einem Kubernetes-Cluster können (mit einem Agent wie Fluentd, der auf jedem Knoten ausgeführt wird) in Tools wie Elasticsearch aufgenommen und mit Kibana angezeigt werden.

  Siehe Logging-Architektur in der Kubernetes-Dokumentation.

• Best Practice: Clusterkomponenten überwachen

  Es wird empfohlen, Container, Pods, Anwendungen, Services und andere Clusterkomponenten mit Tools wie Prometheus, Grafana und Jaeger zu überwachen.

• Best Practice: Protokollieren Sie Metadaten zum Netzwerktraffic und analysieren Sie diese regelmäßig

  Es wird empfohlen, dass Sie VCN-Flowlogs im Oracle Cloud Infrastructure Logging-Service aktivieren, um Metadaten zum Traffic zu erfassen, der durch ein VCN fließt, wie Quell- und Ziel-IP-Adresse und -Port, sowie akzeptierte/abgeschlossene Pakete. Nachdem Sie die Metadaten erfasst haben, analysieren Sie sie regelmäßig, um verdächtige oder ungewöhnliche Aktivitäten zwischen Ressourcen im VCN zu identifizieren, einschließlich zwischen Pods. Siehe Network Traffic Monitoring mit Oracle-VCN-Flowlogs.

Siehe Kubernetes-Cluster beobachten.

Best Practice: Verwenden Sie kleine und sichere Container-Images

Es wird empfohlen, kleine und sichere Containerimages zu erstellen, die nur die Pakete, Bibliotheken und Tools enthalten, die von der Anwendung des Containers benötigt werden.

Ein neuer Entwickler macht oft den Fehler, das Basisimage zu verwenden, obwohl er nicht die meisten Pakete und Bibliotheken im Basisimage benötigt. Wir empfehlen, kleinere Bilder auszuwählen, die weniger Speicherplatz benötigen. Mit einem kleineren Bild können Sie das Image schneller abrufen und erstellen. Und mit einem kleineren Bild kommt die Wahrscheinlichkeit von Sicherheitsproblemen geringer.

Um die Container-Image-Größe weiter zu reduzieren, sollten Sie nur die Tools installieren, die für die Anwendung des Containers erforderlich sind. Nehmen Sie keine Debugging-Tools in Produktionscontainer auf.

Wenn Anwendungen nur zu Podstartzeit Netzwerktools benötigen, anstatt ausnutzbare Tools wie curl in einem Image für Anwendungen mit langer Ausführungszeit zu platzieren, wird empfohlen, separate Initialisierungscontainer zu verwenden oder die Daten mit einer nativeren Kubernetes-Methode (wie ConfigMaps) bereitzustellen.

Wir empfehlen Ihnen auch, Containerimages auf dem neuesten Stand zu halten und nach neuen Versionen des Basisimages und von Ihnen installierten Tools von Drittanbietern zu suchen.

Best Practice: Exposition bei Zugangsdaten begrenzen

Es wird empfohlen, keine Zugangsdaten im Anwendungscode zu definieren. Verwenden Sie stattdessen einen digitalen Vault (wie Oracle Cloud Infrastructure Vault), um digitale Schlüssel und Zugangsdaten zu speichern und abzurufen.

Best Practice: Mit einem geeigneten Authentifizierungstoken auf das Cluster zugreifen

Es wird empfohlen, nur das Authentifizierungstoken zu verwenden, das vom Befehl in der kubeconfig-Datei eines Clusters generiert wird, wenn Sie mit kubectl und dem Kubernetes-Dashboard auf das Cluster zugreifen. Wenn andere Prozesse und Tools auf das Cluster zugreifen, verwenden Sie ein nicht benutzerspezifisches Authentifizierungstoken für die Authentifizierung.

Wenn Sie die kubeconfig-Datei für ein Cluster einrichten, enthält die Datei standardmäßig einen Oracle Cloud Infrastructure-CLI-Befehl, mit dem ein kurzlebiges, clusterbezogenes und benutzerdefiniertes Authentifizierungstoken generiert wird. Das vom CLI-Befehl generierte Token ist für die Authentifizierung einzelner Benutzer geeignet, die mit kubectl und dem Kubernetes-Dashboard auf das Cluster zugreifen.

Das generierte Authentifizierungstoken ist jedoch nicht zur Authentifizierung von Prozessen und Tools geeignet, die auf das Cluster zugreifen, wie z.B. Tools für kontinuierliche Integration und Bereitstellung (CI/CD). Um Zugriff auf das Cluster sicherzustellen, erfordern derartige Tools langlebige, nicht benutzerspezifische Authentifizierungstoken. Eine Lösung ist die Verwendung eines Kubernetes-Serviceaccounts.

Siehe Authentifizierungstoken von Serviceaccount zu einer Kubeconfig-Datei hinzufügen.

Best Practice: Konfigurieren Sie den Zugriff mit den wenigsten Berechtigungen beim Erstellen von RoleBindings und ClusterRoleBindings

Es wird empfohlen, nur Kubernetes RoleBindings und ClusterRoleBindings zu definieren, die das Set von Berechtigungen enthalten, die zum Ausführen einer bestimmten Funktion erforderlich sind.

Standardmäßig sind Benutzern keine Kubernetes-RBAC-Rollen (oder clusterroles) zugewiesen. Bevor Sie also versuchen, eine neue Rolle (oder clusterrole) zu erstellen, muss Ihnen eine entsprechend privilegierte Rolle (oder clusterrole) zugewiesen worden sein. Eine Reihe solcher Rollen und clusterroles werden immer standardmäßig erstellt, einschließlich der clusterrole "cluster-admin" (siehe Standardrollen und Rollen-Bindings in der Kubernetes-Dokumentation). Die clusterrole "cluster-admin" gewährt im Wesentlichen Superuser-Berechtigungen. Ein Benutzer, dem die clusterrole "cluster-admin" erteilt wurde, kann in einem bestimmten Cluster jeden beliebigen Vorgang in sämtlichen Namespaces ausführen.

Siehe Info zu Access Control und Kubernetes Engine (OKE).