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 Implementierung dieser Sicherheitsmaßnahmen auf EKS sind unterschiedlich, umfassen jedoch häufig die folgenden Elemente:

Steuerung des Verkehrs

Netzwerkverschlüsselung

Netzwerkrichtlinie

Innerhalb eines Kubernetes-Clusters ist die gesamte Pod-zu-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, mit dem Sie den Netzwerkverkehr zwischen Pods (oft als Ost-/West-Verkehr bezeichnet) sowie zwischen Pods und externen Diensten einschränken können. Kubernetes-Netzwerkrichtlinien funktionieren auf den Ebenen 3 und 4 des OSI-Modells. Netzwerkrichtlinien verwenden Pods, 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, was häufig als Eingangs- und Ausgangsregeln bezeichnet wird.

Mit der systemeigenen Unterstützung für Netzwerkrichtlinien durch das Amazon VPC CNI Plugin können Sie Netzwerkrichtlinien implementieren, um den Netzwerkverkehr in Kubernetes-Clustern zu sichern. Dies ist in die vorgelagerte Kubernetes Network Policy 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 eingehende und ausgehende Datenverkehr zu einem Pod zulässig. Wenn eine Netzwerkrichtlinie mit einem PolicyType Ingress angegeben ist, sind nur Verbindungen zum Pod zulässig, die vom Pod-Knoten ausgehen und die nach den Eingangsregeln zugelassenen Verbindungen. Das Gleiche gilt für Ausgangsregeln. Wenn mehrere Regeln definiert sind, wird bei der Entscheidung die Vereinigung aller Regeln 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 Rechte

Erstellen Sie eine standardmäßige Ablehnungsrichtlinie

Wie bei RBAC-Richtlinien wird auch bei Netzwerkrichtlinien empfohlen, die Prinzipien des geringsten 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 Standardregel „Alle ablehnen“ 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 selektiv zuzulassen

Machen Sie sich mit den Anwendungsanforderungen vertraut und erstellen Sie nach Bedarf detaillierte Eingangs- und Ausgangsregeln. Das folgende Beispiel zeigt, wie Sie den eingehenden Verkehr auf Port 80 auf von beschränken können. app-one client-one Dies trägt dazu bei, 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 Node-Agent-Protokolle vpc-network-policy-controller

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 mithilfe von CloudWatchLog Insights erweiterte Abfragen durchführen. In den Protokollen können Sie sehen, welche Pod-Endpunktobjekte in eine Netzwerkrichtlinie aufgelöst wurden, den Abgleichstatus der Richtlinien und das Debuggen, ob die Richtlinie erwartungsgemäß funktioniert.

Darüber hinaus können Sie mit Amazon VPC CNI die Erfassung und den Export von Protokollen zur Durchsetzung von Richtlinien aus den EKS-Worker-Knoten nach Amazon Cloudwatch aktivieren. Nach der Aktivierung können Sie CloudWatchContainer Insights nutzen, um Einblicke in Ihre Nutzung im Zusammenhang mit Netzwerkrichtlinien zu gewinnen.

Amazon VPC CNI bietet auch ein SDK, das eine Schnittstelle für die Interaktion mit eBPF-Programmen auf dem Knoten bereitstellt. Das SDK wird installiert, wenn es auf den aws-node Knoten bereitgestellt wird. Sie finden die SDK-Binärdatei, die im /opt/cni/bin Verzeichnis auf dem Knoten installiert ist. Bei der Markteinführung bietet das SDK Unterstützung für grundlegende Funktionen wie die Inspektion eBPF eBPF-Programmen und -Maps.

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

Protokollieren Sie Metadaten zum Netzwerkverkehr

AWS VPC Flow Logs erfasst Metadaten über den Datenverkehr, der durch eine VPC fließt, wie Quell- und Ziel-IP-Adresse und Port sowie akzeptierte/verworfene Pakete. 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 ausgetauscht werden, reichen Flow Logs allein möglicherweise nicht aus. Calico Enterprise erweitert die Flow Logs um Pod-Labels und andere Metadaten, was es einfacher macht, die Verkehrsflüsse zwischen Pods zu entziffern.

Sicherheitsgruppen

EKS verwendet AWS VPC Security Groups (SGs), um den Verkehr zwischen der Kubernetes-Steuerebene und den Worker-Knoten des Clusters zu kontrollieren. Sicherheitsgruppen werden auch verwendet, um den Verkehr zwischen Worker-Knoten und anderen VPC-Ressourcen sowie externen IP-Adressen zu kontrollieren. 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-Steuerebene und den Knoten aus verwalteten Knotengruppen. Der Einfachheit halber wird empfohlen, den Cluster-SG zu allen Knotengruppen hinzuzufügen, einschließlich nicht verwalteter Knotengruppen.

Vor der Kubernetes-Version 1.14 und der 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 Kontrollebene und der Knotengruppen finden Sie unter -group-reqs.html. https://docs.aws.amazon.com/eks/ latest/userguide/sec Die Mindestregeln für die Sicherheitsgruppe der Kontrollebene lassen den eingehenden Port 443 vom Worker-Knoten SG zu. Diese Regel ermöglicht es den Kubelets, mit dem Kubernetes-API-Server zu kommunizieren. Sie umfasst auch Port 10250 für ausgehenden Datenverkehr zum Worker-Knoten SG; 10250 ist der Port, auf dem die Kubelets lauschen. In ähnlicher Weise ermöglichen die Mindestregeln für Knotengruppen den eingehenden Port 10250 von der Steuerungsebene SG und den ausgehenden Port 443 zur Steuerungsebene SG. 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 bestehende 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 in der SGs referenzierten SecurityGroupPolicy Objekte 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 Aufwand 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 bietet eine Option für die Zuordnung von Netzwerkrichtlinien zu AWS-Sicherheitsgruppen. Wenn Sie ein Service Mesh wie Istio implementiert haben, können Sie ein Ausgangsgateway verwenden, um den Netzwerkausgang auf bestimmte, voll 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 sollten Netzwerkrichtlinien und wann Sicherheitsgruppen für Pods verwendet werden?

Wann sollte die Kubernetes-Netzwerkrichtlinie verwendet werden

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

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

Wenn es um Netzwerksicherheit geht, ist ein mehrschichtiger Ansatz oft die effektivste Lösung. Die Kombination von Kubernetes-Netzwerkrichtlinien und SGP kann eine robuste defense-in-depth Strategie für Ihre Anwendungen bieten, die in EKS ausgeführt werden.

Durchsetzung von Service Mesh-Richtlinien oder Kubernetes-Netzwerkrichtlinien

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 Ebene 3 (Netzwerk) und Schicht 4 (Transport) angewendet werden. 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 auf DNS-Hostnamen basierende Regeln, 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 für 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 es in Istio integriert ist. 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 außerdem die Netzwerkrichtlinien erweitert und unterstützen nun teilweise 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, die innerhalb oder außerhalb Ihrer VPC laufen, einzuschränken. Im Gegensatz dazu enthält Calico Enterprise eine Funktion, mit der Sie eine Kubernetes-Netzwerkrichtlinie einer AWS-Sicherheitsgruppe sowie DNS-Hostnamen zuordnen können.

Eine Liste gängiger Kubernetes-Netzwerkrichtlinien finden Sie unter. https://github.com/ahmetb/kubernetes-network-policy-recipes Ein ähnliches Regelwerk für Calico ist unter https://docs.projectcalico verfügbar. org/security/calico-Netzwerkpolitik.

Migration zur Amazon VPC CNI Network Policy Engine

Um die Konsistenz aufrechtzuerhalten und ein unerwartetes Verhalten bei der Pod-Kommunikation 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 3P-Ressourcen in die NetworkPolicy Kubernetes-Ressourcen NetworkPolicy CRDs zu konvertieren, bevor Sie die VPC CNI-Netzwerkrichtlinienunterstützung aktivieren. Testen Sie außerdem die migrierten Richtlinien in einem separaten Testcluster, bevor Sie sie in Ihrer Produktionsumgebung anwenden. Auf diese Weise können Sie potenzielle Probleme oder Inkonsistenzen im Kommunikationsverhalten von Pods identifizieren und beheben.

Tool für die Migration

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

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

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 des Datenverkehrs auf der Leitung. 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 Datenverkehr, der zwischen den folgenden Nitro-Instance-Typen, z. B. C5n, G4, I3en, M5dn, M5n, P3dn, R5dn und R5n, ausgetauscht wird, wird standardmäßig automatisch verschlüsselt. Wenn es einen Intermediate-Hop gibt, wie ein Transit-Gateway oder ein Load Balancer, ist der Datenverkehr nicht verschlüsselt. Weitere Informationen zur Verschlüsselung bei der Übertragung sowie eine vollständige Liste der Instance-Typen, die Netzwerkverschlüsselung standardmäßig unterstützen, finden Sie unter Verschlüsselung bei der Übertragung.

Container-Netzwerkschnittstellen (CNIs)

WeaveNetkann so konfiguriert werden, dass der gesamte Datenverkehr automatisch verschlüsselt wird, wobei NaCl Verschlüsselung für Sleeve-Verkehr und IPsec ESP für schnellen Datenpfadverkehr verwendet wird.

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-examplesGitHub Repository bietet exemplarische Vorgehensweisen zur Konfiguration von mTLS mithilfe von X.509-Zertifikaten und SPIRE als SDS-Anbieter mit Ihrem Envoy-Container:

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 aws-app-mesh-examplesGitHub Repository bietet exemplarische Vorgehensweisen für die Konfiguration von TLS mithilfe von Zertifikaten, die von ACM ausgestellt wurden, und Zertifikaten, die in Ihrem Envoy-Container enthalten sind:

Ingress-Controller und Load Balancer

Ingress-Controller bieten Ihnen die Möglichkeit, die HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, e.g. at the load balancer, at the ingress resource, or the Pod. How and where you terminate your SSL connection will ultimately be dictated by your organization’s network security policy. For instance, if you have a policy that requires end-to-end encryption, you will have to decrypt the traffic at the Pod. This will place additional burden on your Pod as it will have to spend cycles establishing the initial handshake. Overall SSL/TLS Verarbeitung, die sehr CPU-intensiv ist, intelligent weiterzuleiten. Wenn Sie also die nötige Flexibilität haben, versuchen Sie, den SSL-Offload am Ingress oder am Load Balancer durchzuführen.

Verschlüsselung mit AWS Elastic Load Balancers verwenden

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 den ALB können Sie angeben, welche Zertifikate dem ALB hinzugefügt werden sollen. Wenn Sie die Anmerkung weglassen, versucht der Controller, Listenern, die dies 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 Anmerkung mit der 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 SSL/TLS eine Kündigung.

ACM Private CA mit Cert-Manager

Mithilfe von ACM Private Certificate Authority (CA) und cert-manager, einem beliebten Kubernetes-Add-on zum Verteilen, Erneuern und Widerrufen von Zertifikaten, können Sie TLS und mTLS aktivieren, um Ihre EKS-Anwendungsworkloads am Eingang, auf dem Pod und zwischen Pods zu sichern. ACM Private CA ist eine hochverfügbare, sichere und verwaltete CA ohne die Vorab- und Wartungskosten, die mit der Verwaltung Ihrer eigenen CA verbunden wären. Wenn Sie die standardmäßige Kubernetes-Zertifizierungsstelle verwenden, besteht die Möglichkeit, Ihre Sicherheit zu verbessern und die Compliance-Anforderungen mit 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 Standard-CA, die Schlüssel im Speicher speichert (weniger sicher). Eine zentralisierte CA bietet Ihnen außerdem mehr Kontrolle und verbesserte Überprüfbarkeit für private Zertifikate sowohl innerhalb als auch außerhalb einer Kubernetes-Umgebung.

Kurzlebiger CA-Modus für wechselseitiges TLS zwischen Workloads

Bei der Verwendung von ACM Private CA für mTLS in EKS wird empfohlen, kurzlebige Zertifikate im kurzlebigen CA-Modus zu verwenden. Es ist zwar möglich, kurzlebige Zertifikate im allgemeinen CA-Modus auszustellen, aber der kurzlebige CA-Modus ist 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 den technischen Dokumenten zu ACM Private CA beschriebenen Verfahren befolgen. Sobald Sie über eine private CA verfügen, 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 Installationsanweisungen unter folgen. GitHub Mit dem Plugin kann der Cert-Manager private Zertifikate von ACM Private CA anfordern.

Nachdem Sie nun 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 Ihrer privaten CA:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "<CA_ARN>"
        }
    ]
}

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 mit dem folgenden Text erstellen <CA_ARN> und <Region> die Informationen durch Ihre private CA ersetzen.

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 Aussteller bereit.

kubectl apply -f cluster-issuer.yaml

Ihr EKS-Cluster ist so konfiguriert, dass er Zertifikate von Private CA anfordert. Sie können jetzt die Certificate Ressource von cert-manager verwenden, um Zertifikate auszustellen, indem Sie die issuerRef Feldwerte auf den Private CA-Aussteller ändern, den Sie oben erstellt haben. Weitere Informationen zur Angabe und Anforderung von Zertifikatsressourcen finden Sie im Certificate Resources Guide von cert-manager. Beispiele finden Sie hier.

ACM Private CA mit Istio und Cert-Manager

Wenn Sie Istio in Ihrem EKS-Cluster ausführen, können Sie die Istio-Steuerebene (insbesondereistiod) so deaktivieren, dass sie als Stammzertifizierungsstelle (CA) fungiert, und ACM Private CA als Stammzertifizierungsstelle für mTLs zwischen Workloads konfigurieren. Wenn Sie sich für diesen Ansatz entscheiden, sollten Sie die Verwendung des kurzlebigen CA-Modus in ACM Private CA in Betracht ziehen. 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 hängen Dienstkonten automatisch ein zugeordnetes Token ein. Dieses Token wird vom Dienstkonto für Workloads verwendet, um sich gegenüber der Kubernetes-API zu authentifizieren. Das Dienstkonto kann als Identität für Kubernetes ausreichend sein, aber Istio verfügt über ein eigenes Identitätsverwaltungssystem und eine eigene Zertifizierungsstelle. 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 kann.

Um diese Identität von Istio zu erhalten, istio-agent sendet Istio 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 istiod der Registration Authority (oder RA) und der CA durchgeführt. Die RA dient als Gatekeeper, der sicherstellt, dass nur verifizierte CSR die CA erreicht. Sobald die CSR verifiziert ist, wird sie an die CA weitergeleitet, die dann ein Zertifikat ausstellt, das eine SPIFFE-Identität für das Dienstkonto enthält. Dieses Zertifikat wird als verifizierbares SPIFFE-Ausweisdokument (oder SVID) bezeichnet. Die SVID wird dem anfragenden Dienst zu Identifikationszwecken und zur Verschlüsselung des Transitverkehrs zwischen den kommunizierenden Diensten zugewiesen.

Standardablauf für Istio-Zertifikatsignieranfragen:

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 Kontrollebene mit Cert Manager-Ausstellern, in diesem Fall ACM Private CA, gesichert werden. Der istio-csr-Agent stellt denselben Dienst bereit, den istiod in der Standardkonfiguration für die Validierung eingehender Daten bereitstellt. CSRs Allerdings werden die Anfragen nach der Überprüfung in Ressourcen umgewandelt, die der Zertifizierungsmanager unterstützt (d. h. Integrationen mit externen CA-Ausstellern).

Immer wenn eine CSR von einem Workload eingeht, wird sie an istio-csr weitergeleitet, das 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. 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 Istio-Zertifikatsignieranfragen mit istio-csr

image:: istio-csr-with-acm -private-ca.png [Ablauf für Istio-Zertifikatsignieranfragen mit istio-csr]

Anweisungen zur Einrichtung von Istio mit privater CA

Anfragen zum Signieren von Istio-Zertifikaten

image: istio-csr-requests .png [Signaturanfragen für Istio-Zertifikate]

Tools und Ressourcen