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.

Netzwerksicherheit

Netzwerksicherheit hat mehrere Facetten. Die erste beinhaltet die Anwendung von Regeln, die den Fluss des Netzwerkverkehrs zwischen Diensten einschränken. Die zweite beinhaltet die Verschlüsselung des Datenverkehrs während der Übertragung. Die Mechanismen zur Umsetzung dieser Sicherheitsmaßnahmen auf EKS sind vielfältig, umfassen jedoch häufig die folgenden Elemente:

Steuerung des Verkehrs

Netzwerkverschlüsselung

Netzwerkrichtlinie

In einem Kubernetes-Cluster ist die gesamte Pod-to-Pod-Kommunikation standardmäßig zulässig. Diese Flexibilität kann zwar dazu beitragen, Experimente zu fördern, wird aber nicht als sicher angesehen. Kubernetes-Netzwerkrichtlinien bieten Ihnen einen Mechanismus, um den Netzwerkverkehr zwischen Pods (oft als East/West Verkehr bezeichnet) sowie zwischen Pods und externen Diensten einzuschränken. Die Kubernetes-Netzwerkrichtlinien funktionieren auf den Ebenen 3 und 4 des OSI-Modells. Netzwerkrichtlinien verwenden Pod-, Namespace-Selektoren und Labels, um Quell- und Ziel-Pods zu identifizieren, können aber auch IP-Adressen, Portnummern, Protokolle oder eine Kombination davon enthalten. Netzwerkrichtlinien können sowohl auf eingehende als auch auf ausgehende Verbindungen zum Pod angewendet werden. Sie werden häufig als Eingangs- und Ausgangsregeln bezeichnet.

Mit der nativen Netzwerkrichtlinien-Unterstützung des Amazon VPC CNI Plug-ins können Sie Netzwerkrichtlinien implementieren, um den Netzwerkverkehr in Kubernetes-Clustern abzusichern. Dies ist in die Upstream-Kubernetes-Netzwerkrichtlinien-API integriert und gewährleistet so die Kompatibilität und Einhaltung der Kubernetes-Standards. Sie können Richtlinien mithilfe verschiedener Identifikatoren definieren, die von der Upstream-API unterstützt werden. Standardmäßig ist der gesamte ein- und ausgehende Verkehr zu einem Pod zulässig. Wenn eine Netzwerkrichtlinie mit einem PolicyType Ingress angegeben ist, sind nur Verbindungen zum Pod zulässig, die vom Knoten des Pods ausgehen und die nach den Eingangsregeln zulässigen Verbindungen sind. Das Gleiche gilt für Ausgangsregeln. Wenn mehrere Regeln definiert sind, wird die Vereinigung aller Regeln bei der Entscheidung berücksichtigt. Somit hat die Reihenfolge der Bewertung keinen Einfluss auf das politische Ergebnis.

Empfehlungen

Erste Schritte mit Netzwerkrichtlinien — Folgen Sie dem Prinzip der geringsten Zugriffsrechte

Erstellen Sie eine Standard-Ablehnungsrichtlinie

Wie bei RBAC-Richtlinien wird empfohlen, bei Netzwerkrichtlinien die Prinzipien des geringsten Privilegierten Zugriffs zu befolgen. Erstellen Sie zunächst eine Deny-All-Richtlinie, die den gesamten eingehenden und ausgehenden Datenverkehr in einem Namespace einschränkt.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Standardmäßige Ablehnung

Erstellen Sie eine Regel, um DNS-Abfragen zuzulassen

Sobald Sie die Standard-Deny-All-Regel eingerichtet haben, können Sie zusätzliche Regeln hinzufügen, z. B. eine Regel, die es Pods ermöglicht, CoreDNS zur Namensauflösung abzufragen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

allow-dns-access

Fügen Sie schrittweise Regeln hinzu, um den Verkehrsfluss zwischen namespaces/pods

Machen Sie sich mit den Anwendungsanforderungen vertraut und erstellen Sie nach Bedarf detaillierte Regeln für den Ein- und Ausgang. Das folgende Beispiel zeigt, wie der eingehende Verkehr über Port 80 auf von beschränkt wird. app-one client-one Dies hilft, die Angriffsfläche zu minimieren und das Risiko eines unbefugten Zugriffs zu verringern.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-app-one
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: app-one
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          k8s-app: client-one
    ports:
    - protocol: TCP
      port: 80

Allow-Ingress-App-One

Überwachung der Durchsetzung von Netzwerkrichtlinien

package kubernetes.admission
import data.kubernetes.networkpolicies

deny[msg] {
    input.request.kind.kind == "Pod"
    pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels}
    contains_label(pod_label_value, "sample-app")
    np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels}
    not contains_label(np_label_value, "sample-app")
    msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name])
}
contains_label(arr, val) {
    arr[_] == val
}

Fehlerbehebung

Überwachen Sie die Protokolle vpc-network-policy-controller und node-Agent

Aktivieren Sie die EKS Control Plane Controller Manager-Protokolle, um die Funktionalität der Netzwerkrichtlinien zu diagnostizieren. Sie können die Protokolle der Kontrollebene in eine CloudWatch Protokollgruppe streamen und CloudWatch Log Insights verwenden, um erweiterte Abfragen durchzuführen. In den Protokollen können Sie sehen, welche Pod-Endpunktobjekte in eine Netzwerkrichtlinie aufgelöst wurden, den Abstimmungsstatus der Richtlinien und debuggen, ob die Richtlinie erwartungsgemäß funktioniert.

Darüber hinaus ermöglicht Ihnen Amazon VPC CNI, die Erfassung und den Export von Protokollen zur Richtliniendurchsetzung von den EKS-Worker-Knoten aus zu Amazon Cloudwatch zu aktivieren. Nach der Aktivierung können Sie CloudWatch Container Insights nutzen, um Einblicke in Ihre Nutzung im Zusammenhang mit Netzwerkrichtlinien zu erhalten.

Amazon VPC CNI liefert auch ein SDK, das eine Schnittstelle für die Interaktion mit eBPF-Programmen auf dem Knoten bietet. Das SDK wird installiert, wenn es auf den aws-node Knoten bereitgestellt wird. Sie finden die installierte SDK-Binärdatei im /opt/cni/bin Verzeichnis auf dem Knoten. Beim Start unterstützt das SDK grundlegende Funktionen wie die Überprüfung von eBPF-Programmen und -Maps.

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Protokollieren Sie die Metadaten des Netzwerkverkehrs

AWS VPC Flow Logs erfasst Metadaten über den Datenverkehr, der durch eine VPC fließt, wie Quell- und Ziel-IP-Adresse und Port sowie Pakete. accepted/dropped Diese Informationen könnten analysiert werden, um nach verdächtigen oder ungewöhnlichen Aktivitäten zwischen Ressourcen innerhalb der VPC, einschließlich Pods, zu suchen. Da sich die IP-Adressen von Pods jedoch häufig ändern, wenn sie ersetzt werden, reichen Flow Logs allein möglicherweise nicht aus. Calico Enterprise erweitert die Flow Logs um Pod-Labels und andere Metadaten, wodurch es einfacher wird, die Verkehrsflüsse zwischen den Pods zu entschlüsseln.

Sicherheitsgruppen

EKS verwendet AWS VPC Security Groups (SGs), um den Verkehr zwischen der Kubernetes-Steuerungsebene und den Worker-Knoten des Clusters zu steuern. Sicherheitsgruppen werden auch verwendet, um den Verkehr zwischen Worker-Knoten und anderen VPC-Ressourcen sowie externen IP-Adressen zu steuern. Wenn Sie einen EKS-Cluster (mit Kubernetes-Version 1.14-eks.3 oder höher) bereitstellen, wird automatisch eine Cluster-Sicherheitsgruppe für Sie erstellt. Diese Sicherheitsgruppe ermöglicht die uneingeschränkte Kommunikation zwischen der EKS-Steuerungsebene und den Knoten aus verwalteten Knotengruppen. Der Einfachheit halber wird empfohlen, den Cluster SG allen Knotengruppen hinzuzufügen, einschließlich nicht verwalteter Knotengruppen.

Vor Kubernetes-Version 1.14 und EKS-Version eks.3 wurden separate Sicherheitsgruppen für die EKS-Steuerungsebene und die Knotengruppen konfiguriert. Die Mindestregeln und die empfohlenen Regeln für die Sicherheitsgruppen der Steuerungsebene und der Knotengruppe finden Sie unter https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html. Die Mindestregeln für die Sicherheitsgruppe der Steuerungsebene erlauben den vom Worker-Knoten SG eingehenden Port 443. Diese Regel ermöglicht es den Kubelets, mit dem Kubernetes-API-Server zu kommunizieren. Es enthält auch Port 10250 für ausgehenden Verkehr zum Worker Node SG; 10250 ist der Port, auf dem die Kubelets lauschen. In ähnlicher Weise erlauben die Mindestregeln für Knotengruppen den Port 10250, der von der Steuerungsebene SG eingeht, und 443, der von der Steuerungsebene SG ausgeht. Schließlich gibt es eine Regel, die eine uneingeschränkte Kommunikation zwischen Knoten innerhalb einer Knotengruppe ermöglicht.

Wenn Sie die Kommunikation zwischen Diensten, die innerhalb des Clusters ausgeführt werden, und Diensten, die außerhalb des Clusters ausgeführt werden, wie z. B. einer RDS-Datenbank, kontrollieren müssen, sollten Sie Sicherheitsgruppen für Pods in Betracht ziehen. Mit Sicherheitsgruppen für Pods können Sie einer Sammlung von Pods eine vorhandene Sicherheitsgruppe zuweisen.

Sie können steuern, welche Pods einer Sicherheitsgruppe zugewiesen werden, indem Sie ein SecurityGroupPolicy Objekt erstellen und a PodSelector oder a angebenServiceAccountSelector. Wenn Sie die Selektoren auf setzen, {} werden die SGs, auf die in der verwiesen wirdSecurityGroupPolicy, allen Pods in einem Namespace oder allen Dienstkonten in einem Namespace zugewiesen. Stellen Sie sicher, dass Sie sich mit allen Überlegungen vertraut gemacht haben, bevor Sie Sicherheitsgruppen für Pods implementieren.

Sicherheitsgruppen für Pods bieten zwar eine AWS-native Möglichkeit, den Netzwerkverkehr innerhalb und außerhalb Ihres Clusters ohne den Overhead eines Policy-Daemons zu kontrollieren, aber es sind auch andere Optionen verfügbar. Mit der Cilium Policy Engine können Sie beispielsweise in einer Netzwerkrichtlinie auf einen DNS-Namen verweisen. Calico Enterprise beinhaltet eine Option für die Zuordnung von Netzwerkrichtlinien zu AWS-Sicherheitsgruppen. Wenn Sie ein Service Mesh wie Istio implementiert haben, können Sie ein Egress-Gateway verwenden, um den Netzwerkausgang auf bestimmte, vollständig qualifizierte Domänen oder IP-Adressen zu beschränken. Weitere Informationen zu dieser Option finden Sie in der dreiteiligen Serie zur Steuerung des ausgehenden Datenverkehrs in Istio.

Wann sollte man Network Policy im Vergleich zu Security Group für Pods verwenden?

Wann sollte die Kubernetes-Netzwerkrichtlinie verwendet werden

Wann sollten AWS-Sicherheitsgruppen für Pods (SGP) verwendet werden

Bewährte Methoden zur Verwendung von Sicherheitsgruppen für Pods und Netzwerkrichtlinien

Wenn es um Netzwerksicherheit geht, ist ein mehrstufiger Ansatz oft die effektivste Lösung. Die Kombination von Kubernetes-Netzwerkrichtlinien und SGP kann eine robuste, tiefgreifende Verteidigungsstrategie für Ihre in EKS ausgeführten Anwendungen bieten.

Durchsetzung der Service Mesh-Richtlinien oder Kubernetes-Netzwerkrichtlinie

A service mesh ist eine dedizierte Infrastrukturebene, die Sie Ihren Anwendungen hinzufügen können. Sie ermöglicht es Ihnen, Funktionen wie Beobachtbarkeit, Verkehrsmanagement und Sicherheit transparent hinzuzufügen, ohne sie Ihrem eigenen Code hinzufügen zu müssen.

Service Mesh setzt Richtlinien auf Ebene 7 (Anwendung) des OSI-Modells durch, wohingegen Kubernetes-Netzwerkrichtlinien auf Layer 3 (Netzwerk) und Layer 4 (Transport) operieren. In diesem Bereich gibt es viele Angebote wie AWSAppMesh, Istio, Linkerd usw.

Wann sollte Service Mesh zur Durchsetzung von Richtlinien verwendet werden

Wählen Sie die Kubernetes-Netzwerkrichtlinie für einfachere Anwendungsfälle

ThirdParty Engines für Netzwerkrichtlinien

Ziehen Sie eine Network Policy Engine eines Drittanbieters in Betracht, wenn Sie erweiterte Richtlinienanforderungen wie globale Netzwerkrichtlinien, Unterstützung für DNS-Hostnamen, Layer-7-Regeln, ServiceAccount basierte Regeln und explizite deny/log Aktionen usw. haben. Calico ist eine Open-Source-Policy-Engine von Tigera, die gut mit EKS zusammenarbeitet. Calico implementiert nicht nur alle Funktionen der Kubernetes-Netzwerkrichtlinien, sondern unterstützt auch erweiterte Netzwerkrichtlinien mit einem umfangreicheren Funktionsumfang, einschließlich der Unterstützung von Layer-7-Regeln, z. B. HTTP, wenn sie in Istio integriert sind. Calico-Richtlinien können auf Namespaces, Pods, Dienstkonten oder global beschränkt werden. Wenn Richtlinien auf ein Dienstkonto beschränkt sind, ordnet es diesem Dienstkonto eine Reihe von Regeln zu. ingress/egress Mit den richtigen RBAC-Regeln können Sie verhindern, dass Teams diese Regeln außer Kraft setzen, sodass IT-Sicherheitsexperten die Verwaltung von Namespaces sicher delegieren können. Isovalent, die Entwickler von Cilium, haben die Netzwerkrichtlinien ebenfalls erweitert und bieten nun teilweise Unterstützung für Layer-7-Regeln, z. B. HTTP. Cilium unterstützt auch DNS-Hostnamen, was nützlich sein kann, um den Verkehr zwischen Kubernetes Services/Pods und Ressourcen einzuschränken, die innerhalb oder außerhalb Ihrer VPC ausgeführt werden. Im Gegensatz dazu enthält Calico Enterprise eine Funktion, mit der Sie eine Kubernetes-Netzwerkrichtlinie sowie DNS-Hostnamen einer AWS-Sicherheitsgruppe zuordnen können.

Eine Liste gängiger Kubernetes-Netzwerkrichtlinien finden Sie unter. Ähnliche Regeln für https://github.com/ahmetb/kubernetes-network-policy-recipes. Calico finden Sie unter https://docs.projectcalico.org/security/calico-network-policy.

Migration zur Amazon VPC CNI Network Policy Engine

Um die Konsistenz aufrechtzuerhalten und ein unerwartetes Pod-Kommunikationsverhalten zu vermeiden, wird empfohlen, nur eine Network Policy Engine in Ihrem Cluster bereitzustellen. Wenn Sie von 3P zur VPC CNI Network Policy Engine migrieren möchten, empfehlen wir, Ihre vorhandenen NetworkPolicy 3P-CRDs in die NetworkPolicy Kubernetes-Ressourcen zu konvertieren, bevor Sie die VPC CNI-Netzwerkrichtlinienunterstützung aktivieren. Testen Sie die migrierten Richtlinien außerdem in einem separaten Testcluster, bevor Sie sie in Ihrer Produktionsumgebung anwenden. Auf diese Weise können Sie potenzielle Probleme oder Inkonsistenzen im Pod-Kommunikationsverhalten identifizieren und beheben.

Tool zur Migration

Um Ihren Migrationsprozess zu unterstützen, haben wir ein Tool namens K8s Network Policy Migrator entwickelt, das Ihre vorhandenen Netzwerkrichtlinien-CRDs in native Calico/Cilium Kubernetes-Netzwerkrichtlinien umwandelt. Nach der Konvertierung können Sie die konvertierten Netzwerkrichtlinien direkt auf Ihren neuen Clustern testen, auf denen der VPC CNI Network Policy Controller ausgeführt wird. Das Tool soll Ihnen helfen, den Migrationsprozess zu optimieren und einen reibungslosen Übergang zu gewährleisten.

Bitte beachten Sie, dass das Migrationstool derzeit vom AWS VPC CNI Network Policy Engineering-Team nicht unterstützt wird. Es wird den Kunden nach bestem Bemühen zur Verfügung gestellt. Wir empfehlen Ihnen, dieses Tool zu verwenden, um Ihren Migrationsprozess zu vereinfachen. Für den Fall, dass Sie Probleme oder Bugs mit dem Tool haben, bitten wir Sie, ein GitHub Problem zu erstellen. Ihr Feedback ist für uns von unschätzbarem Wert und hilft bei der kontinuierlichen Verbesserung unserer Dienstleistungen.

Weitere Ressourcen

Verschlüsselung während der Übertragung

Anwendungen, die PCI-, HIPAA- oder anderen Vorschriften entsprechen müssen, müssen möglicherweise Daten während der Übertragung verschlüsseln. Heutzutage ist TLS de facto die erste Wahl für die Verschlüsselung von drahtgebundenem Datenverkehr. TLS bietet, wie sein Vorgänger SSL, sichere Kommunikation über ein Netzwerk mithilfe kryptografischer Protokolle. TLS verwendet eine symmetrische Verschlüsselung, bei der die Schlüssel zur Verschlüsselung der Daten auf der Grundlage eines gemeinsamen Geheimnisses generiert werden, das zu Beginn der Sitzung ausgehandelt wird. Im Folgenden finden Sie einige Möglichkeiten, wie Sie Daten in einer Kubernetes-Umgebung verschlüsseln können.

Nitro-Instanzen

Der zwischen den folgenden Nitro-Instance-Typen ausgetauschte Datenverkehr, z. B. C5n, G4, I3en, M5dn, M5n, P3dn, R5dn und R5n, wird standardmäßig automatisch verschlüsselt. Wenn es einen Zwischensprung gibt, z. B. ein Transit-Gateway oder einen Load Balancer, wird der Datenverkehr nicht verschlüsselt. Weitere Informationen zur Verschlüsselung bei der Übertragung sowie eine vollständige Liste der Instance-Typen, die standardmäßig Netzwerkverschlüsselung unterstützen, finden Sie unter Verschlüsselung bei der Übertragung.

Service Mesh

Die Verschlüsselung bei der Übertragung kann auch mit einem Service Mesh wie App Mesh, Linkerd v2 und Istio implementiert werden. AppMesh unterstützt mTLS mit X.509 Zertifikaten oder den Secret Discovery Service (SDS) von Envoy. Linkerd und Istio unterstützen beide mTLS.

Das aws-app-mesh-examples GitHub Repository bietet exemplarische Vorgehensweisen für die Konfiguration von mTLs mithilfe von Zertifikaten und SPIRE als SDS-Anbieter mit Ihrem Envoy-Container: X.509

App Mesh unterstützt auch die TLS-Verschlüsselung mit einem privaten Zertifikat, das von AWS Certificate Manager (ACM) ausgestellt wurde, oder einem Zertifikat, das im lokalen Dateisystem des virtuellen Knotens gespeichert ist.

Das GitHub Repository aws-app-mesh-examples bietet exemplarische Vorgehensweisen für die Konfiguration von TLS mithilfe von von ACM ausgestellten Zertifikaten und Zertifikaten, die in Ihrem Envoy-Container enthalten sind:

Ingress-Controller und Load Balancer

Mit Ingress-Controllern können Sie den HTTP/S Datenverkehr, der von außerhalb des Clusters ausgeht, intelligent an Dienste weiterleiten, die innerhalb des Clusters ausgeführt werden. Oft werden diese Ingresses von einem Layer-4-Load Balancer wie dem Classic Load Balancer oder dem Network Load Balancer (NLB) unterstützt. Verschlüsselter Verkehr kann an verschiedenen Stellen im Netzwerk beendet werden, z. B. am Load Balancer, an der Eingangsressource oder am Pod. Wie und wo Sie Ihre SSL-Verbindung beenden, hängt letztlich von den Netzwerksicherheitsrichtlinien Ihres Unternehmens ab. Wenn Sie beispielsweise eine Richtlinie haben, die eine Ende-zu-Ende-Verschlüsselung erfordert, müssen Sie den Datenverkehr auf dem Pod entschlüsseln. Dies wird Ihren Pod zusätzlich belasten, da er Zyklen damit verbringen muss, den ersten Handshake herzustellen. SSL/TLS Die gesamte Verarbeitung ist sehr CPU-intensiv. Wenn Sie also die Flexibilität haben, versuchen Sie, den SSL-Offload am Ingress oder am Load Balancer durchzuführen.

Verwenden Sie Verschlüsselung mit AWS Elastic Load Balancern

Der AWS Application Load Balancer (ALB) und der Network Load Balancer (NLB) unterstützen beide die Transportverschlüsselung (SSL und TLS). Mit der alb.ingress.kubernetes.io/certificate-arn Anmerkung für das ALB können Sie angeben, welche Zertifikate dem ALB hinzugefügt werden sollen. Wenn Sie die Anmerkung weglassen, versucht der Controller, den Listenern, die sie benötigen, Zertifikate hinzuzufügen, indem er die verfügbaren AWS Certificate Manager (ACM) -Zertifikate mithilfe des Host-Felds abgleicht. Ab EKS v1.15 können Sie die service.beta.kubernetes.io/aws-load-balancer-ssl-cert Annotation mit dem NLB verwenden, wie im folgenden Beispiel gezeigt.

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: default
  labels:
    app: demo-app
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<certificate ARN>"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 80
    protocol: TCP
  selector:
    app: demo-app
//---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: default
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 443
              protocol: TCP
            - containerPort: 80
              protocol: TCP

Im Folgenden finden Sie weitere Beispiele für die SSL/TLS Kündigung.

ACM Private CA mit Zertifikatsmanager

Sie können TLS und mTLS aktivieren, um Ihre EKS-Anwendungsworkloads am Eingang, auf dem Pod und zwischen Pods zu sichern. Verwenden Sie dazu ACM Private Certificate Authority (CA) und cert-manager, ein beliebtes Kubernetes-Add-on zum Verteilen, Erneuern und Widerrufen von Zertifikaten. ACM Private CA ist eine hochverfügbare, sichere, verwaltete CA ohne die Vorab- und Wartungskosten, die für die Verwaltung Ihrer eigenen CA anfallen. Wenn Sie die standardmäßige Kubernetes-Zertifizierungsstelle verwenden, besteht die Möglichkeit, Ihre Sicherheit zu verbessern und die Compliance-Anforderungen von ACM Private CA zu erfüllen. ACM Private CA schützt private Schlüssel in FIPS 140-2 Level 3-Hardwaresicherheitsmodulen (sehr sicher), verglichen mit der Standardzertifizierungsstelle, die Schlüssel speichert, die im Speicher kodiert sind (weniger sicher). Eine zentralisierte CA bietet Ihnen außerdem mehr Kontrolle und eine verbesserte Überprüfbarkeit für private Zertifikate sowohl innerhalb als auch außerhalb einer Kubernetes-Umgebung.

Short-Lived CA-Modus für gegenseitiges TLS zwischen Workloads

Wenn Sie ACM Private CA for mTLS in EKS verwenden, wird empfohlen, kurzlebige Zertifikate im kurzlebigen CA-Modus zu verwenden. Obwohl es möglich ist, kurzlebige Zertifikate im allgemeinen CA-Modus auszustellen, ist der kurzlebige CA-Modus kostengünstiger (~ 75% günstiger als der allgemeine Modus) für Anwendungsfälle, in denen häufig neue Zertifikate ausgestellt werden müssen. Darüber hinaus sollten Sie versuchen, die Gültigkeitsdauer der privaten Zertifikate an die Lebensdauer der Pods in Ihrem EKS-Cluster anzupassen. Erfahren Sie hier mehr über ACM Private CA und seine Vorteile.

Anweisungen zur Einrichtung von ACM

Erstellen Sie zunächst eine private CA, indem Sie die in der technischen Dokumentation von ACM Private CA beschriebenen Verfahren befolgen. Sobald Sie eine private CA haben, installieren Sie cert-manager mithilfe der regulären Installationsanweisungen. Installieren Sie nach der Installation von cert-manager das Private CA Kubernetes Cert-Manager-Plugin, indem Sie den Setup-Anweisungen unter folgen. GitHub Mit dem Plugin können Cert-Manager private Zertifikate von ACM Private CA anfordern.

Jetzt, da Sie eine private CA und einen EKS-Cluster mit installiertem Cert-Manager und dem Plugin haben, ist es an der Zeit, die Berechtigungen festzulegen und den Aussteller zu erstellen. Aktualisieren Sie die IAM-Berechtigungen der EKS-Knotenrolle, um den Zugriff auf ACM Private CA zu ermöglichen. Ersetzen Sie das <CA_ARN> durch den Wert aus Ihrer privaten CA:

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"
        }
    ]
}

Servicerollen für IAM-Konten oder IRSA können ebenfalls verwendet werden. Vollständige Beispiele finden Sie im Abschnitt „Zusätzliche Ressourcen“ weiter unten.

Erstellen Sie einen Aussteller in Amazon EKS, indem Sie eine benutzerdefinierte Ressourcendefinitionsdatei mit dem Namen cluster-issuer.yaml erstellen, die den folgenden Text enthält <CA_ARN> und <Region> die Informationen durch Ihre private CA ersetzt.

apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
          name: demo-test-root-ca
spec:
          arn: <CA_ARN>
          region: <Region>

Stellen Sie den von Ihnen erstellten Issuer bereit.

kubectl apply -f cluster-issuer.yaml

Ihr EKS-Cluster ist so konfiguriert, dass Zertifikate von Private CA angefordert werden. Sie können jetzt die Certificate Ressource von cert-manager verwenden, um Zertifikate auszustellen, indem Sie die issuerRef Feldwerte auf den oben erstellten Private CA Issuer ändern. Weitere Informationen zum Angeben und Anfordern von Zertifikatsressourcen finden Sie im Leitfaden für Zertifikatsressourcen von cert-manager. https://cert-manager.io/docs/usage/certificate/ Beispiele finden Sie hier.

ACM Private CA mit Istio und Cert-Manager

Wenn Sie Istio in Ihrem EKS-Cluster ausführen, können Sie (insbesondereistiod) die Istio-Steuerungsebene daran hindern, als Root-Zertifizierungsstelle (CA) zu fungieren, und ACM Private CA als Root-CA für MTLs zwischen Workloads konfigurieren. Wenn Sie diesen Ansatz wählen, sollten Sie erwägen, den kurzlebigen CA-Modus in ACM Private CA zu verwenden. Weitere Informationen finden Sie im vorherigen Abschnitt und in diesem Blogbeitrag.

So funktioniert das Signieren von Zertifikaten in Istio (Standard)

Workloads in Kubernetes werden mithilfe von Dienstkonten identifiziert. Wenn Sie kein Dienstkonto angeben, weist Kubernetes Ihrem Workload automatisch eines zu. Außerdem mounten Dienstkonten automatisch ein zugehöriges Token. Dieses Token wird vom Dienstkonto für Workloads verwendet, um sich gegenüber der Kubernetes-API zu authentifizieren. Das Dienstkonto mag als Identität für Kubernetes ausreichen, aber Istio hat ein eigenes Identitätsverwaltungssystem und eine eigene CA. Wenn ein Workload mit seinem Envoy-Sidecar-Proxy gestartet wird, benötigt er eine von Istio zugewiesene Identität, damit er als vertrauenswürdig eingestuft wird und mit anderen Diensten im Mesh kommunizieren darf.

Um diese Identität von Istio zu erhalten, istio-agent sendet der eine Anfrage, die als Certificate Signing Request (oder CSR) bezeichnet wird, an die Istio-Steuerebene. Diese CSR enthält das Dienstkonto-Token, sodass die Identität des Workloads vor der Verarbeitung überprüft werden kann. Dieser Überprüfungsprozess wird von einer Behörde durchgeführtistiod, die sowohl als Registration Authority (oder RA) als auch als CA fungiert. Die RA dient als Gatekeeper, der sicherstellt, dass nur verifizierte CSR die CA erreicht. Sobald der CSR verifiziert ist, wird er an die CA weitergeleitet, die dann ein Zertifikat ausstellt, das eine https://spiffe.io/ SPIFFE-Identität für das Dienstkonto enthält. Dieses Zertifikat wird als verifizierbares SPIFFE-Identitätsdokument (oder SVID) bezeichnet. Die SVID wird dem anfragenden Dienst zu Identifikationszwecken und zur Verschlüsselung des Datenverkehrs zwischen den kommunizierenden Diensten zugewiesen.

Standardablauf für Istio-Anfragen zum Signieren von Zertifikaten:

So funktioniert das Signieren von Zertifikaten in Istio mit ACM Private CA

Sie können ein Cert-Manager-Add-on namens Istio Certificate Signing Request Agent (istio-csr) verwenden, um Istio in ACM Private CA zu integrieren. Mit diesem Agenten können Istio-Workloads und Komponenten der Steuerungsebene mithilfe von Zertifikatsmanagern, in diesem Fall ACM Private CA, gesichert werden. Der istio-csr-Agent stellt denselben Dienst zur Verfügung, den Istiod in der Standardkonfiguration für die Validierung eingehender CSRs bereitstellt. Außer dass er die Anfragen nach der Überprüfung in Ressourcen umwandelt, die der Cert Manager unterstützt (d. h. Integrationen mit externen CA-Ausstellern).

Immer wenn ein CSR von einem Workload eingeht, wird dieser an istio-csr weitergeleitet, das dann Zertifikate von ACM Private CA anfordert. Diese Kommunikation zwischen istio-csr und ACM Private CA wird durch das AWS Private CA Issuer Plugin ermöglicht. https://github.com/cert-manager/aws-privateca-issuer Cert Manager verwendet dieses Plugin, um TLS-Zertifikate von ACM Private CA anzufordern. Das Aussteller-Plugin kommuniziert mit dem ACM Private CA-Dienst, um ein signiertes Zertifikat für den Workload anzufordern. Sobald das Zertifikat signiert wurde, wird es an istio-csr zurückgegeben, das die signierte Anfrage liest und sie an den Workload zurücksendet, der den CSR initiiert hat.

Ablauf für Anfragen zum Signieren von Istio-Zertifikaten mit istio-csr

image: :istio-csr-with-acm-private-ca.png [Ablauf für Anfragen zur Signierung von Istio-Zertifikaten mit istio-csr]

Anweisungen zur Einrichtung von Istio mit einer privaten Zertifizierungsstelle

Anfragen zum Signieren von Istio-Zertifikaten

image: :istio-csr-requests.png [Anfragen zum Signieren von Istio-Zertifikaten]

Tools und Ressourcen