Dienstsicherheit mit Envoy und den Load Balancing APIs (alt) einrichten
Folgen Sie der Anleitung in diesem Leitfaden, um die Authentifizierung und Autorisierung für Dienste zu konfigurieren, die mit Cloud Service Mesh- und Envoy-Proxys bereitgestellt wurden. Dabei werden die Load Balancing APIs verwendet. Wenn Sie die Routing-APIs für Dienste verwenden, lesen Sie Dienstsicherheit mit Envoy einrichten
Vollständige Informationen zu finden Sie unter Sicherheit von Cloud Service Mesh-Diensten mit den Load Balancing APIs.
Dieses Dokument bezieht sich auf Konfigurationen mit den Load Balancing APIs. Dies ist einem älteren Dokument.
Voraussetzungen
Prüfen Sie vor der Konfiguration der Dienstsicherheit für Cloud Service Mesh mit Envoy, ob Ihre Konfiguration die folgenden Voraussetzungen erfüllt:
Verwenden Sie Envoy-Version 1.20.0 oder höher für die xDS v3 API.
Sie können alle Anforderungen für die Bereitstellung von Cloud Service Mesh erfüllen. Für umfassende Informationen zu diesen Anforderungen erhalten Sie unter Einrichtung von Cloud Service Mesh mit Envoy vorbereiten
Sie haben ausreichende Berechtigungen zum Erstellen oder Aktualisieren der Cloud Service Mesh- und Google Cloud Service Mesh-Ressourcen für die Dienstsicherheit, wie unter Einrichten von Cloud Service Mesh mit Envoy vorbereiten beschrieben.
Einrichtung vorbereiten
In den folgenden Abschnitten werden die Aufgaben beschrieben, die Sie ausführen müssen, bevor Sie den Cloud Service Mesh-Sicherheitsdienst einrichten. Diese Aufgaben sind:
- Google Cloud CLI aktualisieren
- Variablen einrichten
- APIs aktivieren, die für Cloud Service Mesh erforderlich sind Certificate Authority Service
gcloud
-Befehlszeilentool aktualisieren
Führen Sie folgenden Befehl auf Ihrem lokalen Computer aus, um die Google Cloud CLI zu aktualisieren:
gcloud components update
Variablen einrichten
Legen Sie die folgenden Variablen fest, sodass Sie Code mit konsistenten Werten kopieren und einfügen können, wenn Sie das Beispiel in diesem Dokument durcharbeiten. Verwenden Sie die folgenden Werte:
- PROJECT_ID: Verwenden Sie die ID Ihres Projekts.
- CLUSTER_NAME: Verwenden Sie den Namen des Clusters, den Sie verwenden möchten, z. B.
secure-td-cluster
. - ZONE: Verwenden Sie die Zone, in der sich der Cluster befindet.
- GKE_CLUSTER_URL: Verwenden Sie
https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
. - WORKLOAD_POOL: Verwenden Sie
PROJECT_ID.svc.id.goog
. - K8S_NAMESPACE: Verwenden Sie
default
. - DEMO_CLIENT_KSA: Verwenden Sie den Namen Ihres Kubernetes-Dienstkontos für den Client.
- DEMO_SERVER_KSA: Verwenden Sie den Namen Ihres Kubernetes-Dienstkontos.
PROJNUM: Verwenden Sie die Projektnummer Ihres Projekts, die Sie in der Google Cloud Console oder mit diesem Befehl ermitteln können:
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
SA_GKE: Verwenden Sie
service-PROJNUM@container-engine-robot.iam.gserviceaccount.com
.CLUSTER_VERSION: Verwenden Sie die aktuellste verfügbare Version. Sie finden diese in den Rapid Channel-Versionshinweisen. Die erforderliche Mindestversion ist 1.21.4-gke.1801. Dies ist die GKE-Clusterversion, die in diesem Beispiel verwendet werden soll.
Legen Sie hier die Werte fest:
# Substitute your project ID PROJECT_ID=PROJECT_ID # GKE cluster name and zone for this example. CLUSTER_NAME=CLUSTER_NAME ZONE=ZONE # GKE cluster URL derived from the above GKE_CLUSTER_URL="https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME" # Workload pool to be used with the GKE cluster WORKLOAD_POOL="PROJECT_ID.svc.id.goog" # Kubernetes namespace to run client and server demo. K8S_NAMESPACE=K8S_NAMESPACE DEMO_CLIENT_KSA=DEMO_CLIENT_KSA DEMO_SERVER_KSA=DEMO_SERVER_KSA # Compute other values # Project number for your project PROJNUM=PROJNUM CLUSTER_VERSION=CLUSTER_VERSION SA_GKE=service-PROJNUM@container-engine-robot.iam.gserviceaccount.com
APIs aktivieren
Verwenden Sie den gcloud services enable
.
Befehl zum Aktivieren aller APIs, die Sie zum Einrichten von Cloud Service Mesh benötigen
mit Certificate Authority Service.
gcloud services enable \ container.googleapis.com \ cloudresourcemanager.googleapis.com \ compute.googleapis.com \ trafficdirector.googleapis.com \ networkservices.googleapis.com \ networksecurity.googleapis.com \ privateca.googleapis.com \ gkehub.googleapis.com
GKE-Cluster erstellen oder aktualisieren
Die Sicherheit von Cloud Service Mesh-Diensten hängt von der CA Service-Einbindung in GKE ab. Der GKE-Cluster muss zusätzlich zu den Anforderungen für die Einrichtung die folgenden Anforderungen erfüllen:
- Verwenden Sie eine Mindestclusterversion von 1.21.4-gke.1801. Wenn Sie Funktionen einer späteren Version benötigen, können Sie diese Version über den Rapid Release Channel abrufen.
- Der GKE-Cluster muss mit Mesh-Zertifikaten aktiviert und konfiguriert sein, wie unter Zertifizierungsstellen zum Ausstellen von Zertifikaten erstellen erläutert.
Erstellen Sie einen neuen Cluster, der die Identitätsföderation von Arbeitslasten für GKE verwendet. Wenn Sie einen vorhandenen Cluster aktualisieren, fahren Sie mit dem nächsten Schritt fort. Der Wert, den Sie für
--tags
angeben muss mit dem Namen übereinstimmen, der an das Flag--target-tags
für die Befehlfirewall-rules create
im Abschnitt Cloud Service Mesh mit Cloud Load Balancing-Komponenten konfigurieren# Create a GKE cluster with GKE managed mesh certificates. gcloud container clusters create CLUSTER_NAME \ --release-channel=rapid \ --scopes=cloud-platform \ --image-type=cos_containerd \ --machine-type=e2-standard-2 \ --zone=ZONE \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-mesh-certificates \ --cluster-version=CLUSTER_VERSION \ --enable-ip-alias \ --tags=allow-health-checks \ --workload-metadata=GKE_METADATA
Die Erstellung eines Clusters kann einige Minuten dauern.
Wenn Sie einen vorhandenen Cluster verwenden, aktivieren Sie die Identitätsföderation von Arbeitslasten für GKE und GKE-Mesh-Zertifikate. Achten Sie darauf, dass der Cluster mit dem Flag
--enable-ip-alias
erstellt wurde, das nicht mit dem Befehlupdate
verwendet werden kann.gcloud container clusters update CLUSTER_NAME \ --enable-mesh-certificates
Mit dem folgenden Befehl wechseln Sie zum neuen Cluster als Standardcluster für Ihre
kubectl
-Befehle:gcloud container clusters get-credentials CLUSTER_NAME \ --zone ZONE
In einer Multi-Cluster-Umgebung bereitstellen
Wenn Sie die Bereitstellung in einer Multi-Cluster-Umgebung vornehmen, folgen Sie der in diesem Abschnitt beschriebenen allgemeinen Vorgehensweise. In dieser Anleitung wird davon ausgegangen, dass Client-Pods in einem Cluster und Server-Pods im anderen Cluster ausgeführt werden.
Erstellen oder aktualisieren Sie die Cluster gemäß der Anleitung im vorherigen Abschnitt.
Erfassen Sie mit dem folgenden Befehl die Pod-IP-Adressbereiche für jeden Cluster:
gcloud compute firewall-rules list \ --filter="name~gke-{CLUSTER_NAME}-[0-9a-z]*-all" \ --format="value(sourceRanges)"
Für Cluster mit dem Namen
cluster-a
undcluster-b
geben die Befehle beispielsweise Ergebnisse wie die folgenden zurück:cluster-a, pod CIDR: 10.4.0.0/14, node network tag: gke-cluster-a-9cd18751-node cluster-b, pod CIDR: 10.8.0.0/14, node network tag: gke-cluster-b-acd14479-node
Erstellen Sie VPC-Firewallregeln, die den Clustern ermöglichen, miteinander zu kommunizieren. Mit dem folgenden Befehl wird beispielsweise eine Firewallregel erstellt, die es den Pod-IP-Adressen
cluster-a
ermöglicht, mitcluster-b
-Knoten zu kommunizieren:gcloud compute firewall-rules create per-cluster-a-pods \ --allow="tcp,udp,icmp,esp,ah,sctp" \ --target-tags="gke-cluster-b-acd14479-node"
Mit dem folgenden Befehl wird eine Firewallregel erstellt, die es den
cluster-b
-Pod-IP-Adressen ermöglicht, mitcluster-a
-Knoten zu kommunizieren:gcloud compute firewall-rules create per-cluster-b-pods \ --allow="tcp,udp,icmp,esp,ah,sctp" \ --target-tags="gke-cluster-a-9cd18751-node"
Cluster bei einer Flotte registrieren
Registrieren Sie den Cluster, den Sie unter GKE-Cluster erstellen erstellt oder aktualisiert haben bei einer Flotte. Durch Registrierung des Clusters lässt sich die projektübergreifende Konfiguration von Clustern vereinfachen.
Die Ausführung dieser Schritte kann bis zu zehn Minuten dauern.
Registrieren Sie den Cluster bei der Flotte:
gcloud container fleet memberships register CLUSTER_NAME \ --gke-cluster=ZONE/CLUSTER_NAME \ --enable-workload-identity --install-connect-agent \ --manifest-output-file=MANIFEST-FILE_NAME
Ersetzen Sie dabei folgende Variablen:
- CLUSTER_NAME: Der Name Ihres Clusters.
- ZONE: Die Zone Ihres Clusters.
- MANIFEST-FILE_NAME: Der Pfad, unter dem diese Befehle das Manifest für die Registrierung generieren.
Nach erfolgreicher Registrierung wird eine Meldung wie die folgende angezeigt:
Finished registering the cluster CLUSTER_NAME with the fleet.
Wenden Sie die generierte Manifestdatei auf Ihren Cluster an:
kubectl apply -f MANIFEST-FILE_NAME
Wenn der Anwendungsprozess erfolgreich ist, werden Meldungen wie die folgenden angezeigt:
namespace/gke-connect created serviceaccount/connect-agent-sa created podsecuritypolicy.policy/gkeconnect-psp created role.rbac.authorization.k8s.io/gkeconnect-psp:role created rolebinding.rbac.authorization.k8s.io/gkeconnect-psp:rolebinding created role.rbac.authorization.k8s.io/agent-updater created rolebinding.rbac.authorization.k8s.io/agent-updater created role.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created clusterrole.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-impersonation-20210416-01-00 created clusterrolebinding.rbac.authorization.k8s.io/gke-connect-feature-authorizer-20210416-01-00 created rolebinding.rbac.authorization.k8s.io/gke-connect-agent-20210416-01-00 created role.rbac.authorization.k8s.io/gke-connect-namespace-getter created rolebinding.rbac.authorization.k8s.io/gke-connect-namespace-getter created secret/http-proxy created deployment.apps/gke-connect-agent-20210416-01-00 created service/gke-connect-monitoring created secret/creds-gcp create
Rufen Sie die Mitgliedschaftsressource aus dem Cluster ab:
kubectl get memberships membership -o yaml
Die Ausgabe sollte den Workload Identity-Pool enthalten, der von der Flotte zugewiesen wurde, wobei PROJECT_ID Ihre Projekt-ID ist:
workload_identity_pool: PROJECT_ID.svc.id.goog
Das bedeutet, dass der Cluster erfolgreich registriert wurde.
Zertifizierungsstellen zum Ausstellen von Zertifikaten erstellen
Wenn Sie Zertifikate an Ihre Pods ausstellen möchten, erstellen Sie einen CA Service-Pool und die folgenden Zertifizierungsstellen (Certificate Authorities, CA):
- Stamm-CA. Dies ist der Root of Trust für alle ausgestellten Mesh-Zertifikate. Sie können eine vorhandene Stamm-CA verwenden, sofern vorhanden. Erstellen Sie die Stamm-CA auf der Ebene
enterprise
, die für die Ausgabe von langlebigen Zertifikaten mit geringem Volumen vorgesehen ist. - Untergeordnete CA. Diese Zertifizierungsstelle stellt Zertifikate für Arbeitslasten aus. Erstellen Sie die untergeordnete CA in der Region, in der Ihr Cluster bereitgestellt wird. Erstellen Sie die untergeordnete Zertifizierungsstelle (Certificate Authority, CA) auf der Ebene
devops
, die für die Ausstellung von kurzlebigen Zertifikaten mit hohem Volumen vorgesehen ist.
Das Erstellen einer untergeordneten CA ist optional. Wir empfehlen aber dringend, eine solche Zertifizierungsstelle zu verwenden, anstatt zum Ausstellen von GKE-Mesh-Zertifikaten Ihre Stamm-CA zu nutzen. Wenn Sie die Stamm-CA zum Ausstellen von Mesh-Zertifikaten verwenden, achten Sie darauf, dass der standardmäßige konfigurationsbasierte Ausstellungsmodus zulässig ist.
Die untergeordnete Zertifizierungsstelle kann sich in einer anderen Region als der Cluster befinden. Es wird jedoch dringend empfohlen, sie in der Region zu erstellen, in der sich auch Ihr Cluster befindet, um die Leistung zu optimieren. Stamm- und untergeordnete CAs können sich Sie dagegen in verschiedenen Regionen befinden. Die Leistung oder Verfügbarkeit wird damit nicht beeinträchtigt.
CA Service wird in diesen Regionen unterstützt:
Name der Region | Beschreibung der Region |
---|---|
asia-east1 |
Taiwan |
asia-east2 |
Hongkong |
asia-northeast1 |
Tokio |
asia-northeast2 |
Osaka |
asia-northeast3 |
Seoul |
asia-south1 |
Mumbai |
asia-south2 |
Delhi |
asia-southeast1 |
Singapur |
asia-southeast2 |
Jakarta |
australia-southeast1 |
Sydney |
australia-southeast2 |
Melbourne |
europe-central2 |
Warschau |
europe-north1 |
Finnland |
europe-southwest1 |
Madrid |
europe-west1 |
Belgien |
europe-west2 |
London |
europe-west3 |
Frankfurt |
europe-west4 |
Niederlande |
europe-west6 |
Zürich |
europe-west8 |
Mailand |
europe-west9 |
Paris |
europe-west10 |
Berlin |
europe-west12 |
Turin |
me-central1 |
Doha |
me-central2 |
Dammam |
me-west1 |
Tel Aviv |
northamerica-northeast1 |
Montreal |
northamerica-northeast2 |
Toronto |
southamerica-east1 |
São Paulo |
southamerica-west1 |
Santiago |
us-central1 |
Iowa |
us-east1 |
South Carolina |
us-east4 |
Northern Virginia |
us-east5 |
Columbus |
us-south1 |
Dallas |
us-west1 |
Oregon |
us-west2 |
Los Angeles |
us-west3 |
Salt Lake City |
us-west4 |
Las Vegas |
Die Liste der unterstützten Standorte können Sie auch mit folgendem Befehl prüfen:
gcloud privateca locations list
Weisen Sie den Personen, die einen CA-Pool und eine CA erstellen, die IAM-Rolle
roles/privateca.caManager
zu. Beachten Sie, dass für MEMBER das korrekte Format so lautet:user:userid@example.com
. Wenn diese Person der aktuelle Nutzer ist, können Sie die aktuelle Nutzer-ID mit dem Shell-Befehl$(gcloud auth list --filter=status:ACTIVE --format="value(account)")
abrufen.gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/privateca.caManager
Nutzern die Rolle
role/privateca.admin
für CA Service gewähren die IAM-Richtlinien ändern müssen, wobeiMEMBER
ein die diesen Zugriff benötigen, insbesondere Personen, die folgenden Schritte ausführen, um dieprivateca.auditor
undprivateca.certificateManager
-Rollen:gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/privateca.admin
Erstellen Sie einen Stamm-CA-Service-Pool.
gcloud privateca pools create ROOT_CA_POOL_NAME \ --location ROOT_CA_POOL_LOCATION \ --tier enterprise
Erstellen Sie eine Stamm-CA.
gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \ --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \ --key-algorithm="ec-p256-sha256" \ --max-chain-length=1 \ --location ROOT_CA_POOL_LOCATION
Verwenden Sie für diese Demoeinrichtung die folgenden Werte für die Variablen:
- ROOT_CA_POOL_NAME=td_sec_pool
- ROOT_CA_NAME=pkcs2-ca
- ROOT_CA_POOL_LOCATION=us-east1
- ROOT_CA_ORGANIZATION="TestCorpLLC"
Erstellen Sie einen untergeordneten Pool und eine untergeordnete CA. Achten Sie darauf, dass der konfigurationsbasierte Standardausstellungsmodus weiterhin zulässig ist.
gcloud privateca pools create SUBORDINATE_CA_POOL_NAME \ --location SUBORDINATE_CA_POOL_LOCATION \ --tier devops
gcloud privateca subordinates create SUBORDINATE_CA_NAME \ --pool SUBORDINATE_CA_POOL_NAME \ --location SUBORDINATE_CA_POOL_LOCATION \ --issuer-pool ROOT_CA_POOL_NAME \ --issuer-location ROOT_CA_POOL_LOCATION \ --subject "CN=SUBORDINATE_CA_NAME, O=SUBORDINATE_CA_ORGANIZATION" \ --key-algorithm "ec-p256-sha256" \ --use-preset-profile subordinate_mtls_pathlen_0
Verwenden Sie für diese Demoeinrichtung die folgenden Werte für die Variablen:
- SUBORDINATE_CA_POOL_NAME="td-ca-pool"
- SUBORDINATE_CA_POOL_LOCATION=us-east1
- SUBORDINATE_CA_NAME="td-ca"
- SUBORDINATE_CA_ORGANIZATION="TestCorpLLC"
- ROOT_CA_POOL_NAME=td_sec_pool
- ROOT_CA_POOL_LOCATION=us-east1
Weisen Sie die IAM-Rolle
privateca.auditor
für die Stamm-CA zu, um den Zugriff vom GKE-Dienstkonto zuzulassen:gcloud privateca pools add-iam-policy-binding ROOT_CA_POOL_NAME \ --location ROOT_CA_POOL_LOCATION \ --role roles/privateca.auditor \ --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"
Weisen Sie der untergeordneten CA die IAM-Rolle
privateca.certificateManager
zu, um den Zugriff vom GKE-Dienstkonto zuzulassen:gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \ --location SUBORDINATE_CA_POOL_LOCATION \ --role roles/privateca.certificateManager \ --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"
Speichern Sie die folgende
WorkloadCertificateConfig
-YAML-Konfiguration, um für Ihren Cluster festzulegen, wie Mesh-Zertifikate ausgegeben werden:apiVersion: security.cloud.google.com/v1 kind: WorkloadCertificateConfig metadata: name: default spec: # Required. The CA service that issues your certificates. certificateAuthorityConfig: certificateAuthorityServiceConfig: endpointURI: ISSUING_CA_POOL_URI # Required. The key algorithm to use. Choice of RSA or ECDSA. # # To maximize compatibility with various TLS stacks, your workloads # should use keys of the same family as your root and subordinate CAs. # # To use RSA, specify configuration such as: # keyAlgorithm: # rsa: # modulusSize: 4096 # # Currently, the only supported ECDSA curves are "P256" and "P384", and the only # supported RSA modulus sizes are 2048, 3072 and 4096. keyAlgorithm: rsa: modulusSize: 4096 # Optional. Validity duration of issued certificates, in seconds. # # Defaults to 86400 (1 day) if not specified. validityDurationSeconds: 86400 # Optional. Try to start rotating the certificate once this # percentage of validityDurationSeconds is remaining. # # Defaults to 50 if not specified. rotationWindowPercentage: 50
Dabei gilt:
- Die Projekt-ID des Projekts, in dem der Cluster ausgeführt wird.
PROJECT_ID
- Der voll qualifizierte URI der Zertifizierungsstelle, die Ihre Mesh-Zertifikate ausstellt (ISSUING_CA_POOL_URI). Dies kann entweder die untergeordnete CA (empfohlen) oder die Stamm-CA sein. Das Format dafür ist:
//privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
- Die Projekt-ID des Projekts, in dem der Cluster ausgeführt wird.
Speichern Sie die folgende
TrustConfig
-YAML-Konfiguration, damit Ihr Cluster weiß, wie den bereitgestellten Zertifikaten vertraut werden soll:apiVersion: security.cloud.google.com/v1 kind: TrustConfig metadata: name: default spec: # You must include a trustStores entry for the trust domain that # your cluster is enrolled in. trustStores: - trustDomain: PROJECT_ID.svc.id.goog # Trust identities in this trustDomain if they appear in a certificate # that chains up to this root CA. trustAnchors: - certificateAuthorityServiceURI: ROOT_CA_POOL_URI
Dabei gilt:
- Die Projekt-ID des Projekts, in dem der Cluster ausgeführt wird.
PROJECT_ID
- Der vollständig qualifizierte URI des Stamm-CA-Pools (ROOT_CA_POOL_URI). Das Format lautet:
//privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME
- Die Projekt-ID des Projekts, in dem der Cluster ausgeführt wird.
Wenden Sie die Konfigurationen auf Ihren Cluster an:
kubectl apply -f WorkloadCertificateConfig.yaml kubectl apply -f TrustConfig.yaml
Identitäts- und Zugriffsverwaltung konfigurieren
Zum Erstellen der für die Einrichtung erforderlichen Ressourcen benötigen Sie die Rolle compute.NetworkAdmin
. Diese Rolle enthält alle notwendigen Berechtigungen zum Erstellen, Aktualisieren, Löschen, Auflisten und Verwenden (d. h. zum Verweisen in anderen Ressourcen) der erforderlichen Ressourcen. Wenn Sie der Inhaber-Bearbeiter Ihres Projekts sind, wurde Ihnen diese Rolle automatisch zugewiesen.
Beachten Sie, dass networksecurity.googleapis.com.clientTlsPolicies.use
und networksecurity.googleapis.com.serverTlsPolicies.use
nicht erzwungen werden, wenn Sie auf diese Ressourcen im Backend-Dienst und Ziel-HTTPS-Proxy verweisen.
Wenn diese Berechtigungen in Zukunft erzwungen werden und Sie die Rolle compute.NetworkAdmin
verwenden, entstehen keine Probleme, wenn diese Prüfung erzwungen wird.
Wenn Sie benutzerdefinierte Rollen verwenden, müssen Sie die entsprechende Berechtigung .use
angeben, sollte diese Prüfung in Zukunft erzwungen werden. Andernfalls werden Sie in Zukunft möglicherweise feststellen, dass Ihre benutzerdefinierte Rolle nicht die erforderlichen Berechtigungen hat, um auf clientTlsPolicy
oder serverTlsPolicy
vom Backend-Dienst bzw. Ziel-HTTPS-Proxy zu verweisen.
Die folgende Anleitung ermöglicht es dem Standarddienstkonto, auf die Cloud Service Mesh Security API zuzugreifen und die Kubernetes-Dienstkonten zu erstellen.
IAM so konfigurieren, dass das Standarddienstkonto Zugriff erhält der Cloud Service Mesh Security API.
GSA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \ --filter='displayName:Compute Engine default service account') gcloud projects add-iam-policy-binding PROJECT_ID \ --member serviceAccount:${GSA_EMAIL} \ --role roles/trafficdirector.client
Richten Sie Kubernetes-Dienstkonten ein. Die Client- und Server-Deployments in den folgenden Abschnitten verwenden die Knames der Kubernetes-Server- und Clientdienstkonten.
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA
Erlauben Sie den Kubernetes-Dienstkonten, die Identität des standardmäßigen Compute Engine-Dienstkontos zu übernehmen, indem Sie eine IAM-Richtlinienbindung zwischen diesen beiden erstellen. Durch diese Bindung kann das Kubernetes-Dienstkonto als Compute Engine-Standarddienstkonto verwendet werden.
gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_SERVER_KSA]" ${GSA_EMAIL} gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/DEMO_CLIENT_KSA]" ${GSA_EMAIL}
Versehen Sie die Kubernetes-Dienstkonten mit Anmerkungen, um sie mit dem Compute Engine-Standarddienstkonto zu verknüpfen.
kubectl annotate --namespace K8S_NAMESPACE \ serviceaccount DEMO_SERVER_KSA \ iam.gke.io/gcp-service-account=${GSA_EMAIL} kubectl annotate --namespace K8S_NAMESPACE \ serviceaccount DEMO_CLIENT_KSA \ iam.gke.io/gcp-service-account=${GSA_EMAIL}
Cloud Service Mesh einrichten
Verwenden Sie die folgenden Anleitungen, um den Sidecar-Injektor zu installieren, einen Testdienst einzurichten und andere Deployment-Aufgaben auszuführen.
Envoy-Sidecar-Injektor im Cluster installieren
Folgen Sie der Anleitung in den beiden folgenden Abschnitten der Cloud Service Mesh-Einrichtung für GKE-Pods mit automatischer Envoy-Einschleusung zum Bereitstellen und Aktivieren der Envoy-Sidecar-Einfügung in Ihrem Cluster:
Führen Sie beide Anleitungen aus, bevor Sie einen Testdienst einrichten.
Testdienst einrichten
Nach Installation des Envoy-Sidecar-Injektors richten Sie mithilfe dieser Anleitung einen Testdienst für Ihr Deployment ein.
wget -q -O - https://storage.googleapis.com/traffic-director/security/ga/service_sample.yaml | sed -e s/DEMO_SERVER_KSA_PLACEHOLDER/DEMO_SERVER_KSA/g > service_sample.yaml kubectl apply -f service_sample.yaml
Die Datei service_sample.yaml
enthält die Pod-Spezifikation für Ihre Demoserveranwendung. Es gibt einige Anmerkungen speziell für die Cloud Service Mesh-Sicherheit.
Cloud Service Mesh-Proxy-Metadaten
Die Pod-Spezifikation gibt die Annotation proxyMetadata
an:
spec: ... annotations: cloud.google.com/proxyMetadata: '{"app": "payments"}' ...
Wenn der Pod initialisiert ist, übernimmt der Sidecar-Proxy diese Annotation und sendet sie an das Cloud Service Mesh. Cloud Service Mesh kann diese Informationen dann verwenden, um eine gefilterte Konfiguration zurückzusenden:
- Später in dieser Anleitung sehen Sie, dass die Endpunktrichtlinie einen Endpunkt-Matcher angibt.
- Der Endpunkt-Matcher gibt an, dass nur Clients mit einem Label mit dem Namen
app
und dem Wertpayments
die gefilterte Konfiguration erhalten.
Vom CA Service signierte Mesh-Zertifikate und Schlüssel verwenden
Die Pod-Spezifikation gibt die Annotation enableManagedCerts
an:
spec: ... annotations: ... cloud.google.com/enableManagedCerts: "true" ...
Wenn der Pod initialisiert wird, Schlüssel werden automatisch im lokalen Sidecar-Proxy-Dateisystem bereitgestellt.
Abfangport für eingehenden Traffic konfigurieren
Die Pod-Spezifikation gibt die Annotation includeInboundPorts
an:
spec: ... annotations: ... cloud.google.com/includeInboundPorts: "8000" ...
Dies ist der Port, den die Serveranwendung auf Verbindungen überwacht. Wann? wird der Pod initialisiert. Der Sidecar-Proxy erfasst diese Annotation an das Cloud Service Mesh. Cloud Service Mesh kann diese Informationen dann verwenden, um eine gefilterte Konfiguration zurückzusenden, die den gesamten eingehenden Traffic an diesen Port abfängt und Sicherheitsrichtlinien darauf anwenden kann.
Der Systemdiagnoseport muss sich vom Anwendungsport unterscheiden. Andernfalls gelten dieselben Sicherheitsrichtlinien für eingehende Verbindungen zum Systemdiagnoseport. Dies kann dazu führen, dass die Verbindungen abgelehnt werden, was dazu führt, dass der Server fälschlicherweise als fehlerhaft gekennzeichnet wird.
GKE-Dienste mit NEGs konfigurieren
GKE-Dienste müssen über Netzwerk-Endpunktgruppen (NEGs) verfügbar gemacht werden, damit Sie sie als Back-Ends eines Cloud Service Mesh-Back-End-Dienstes konfigurieren können. Das in dieser Einrichtungsanleitung bereitgestellte Paket service_sample.yaml
verwendet den NEG-Namen service-test-neg
in der folgenden Annotation:
... metadata: annotations: cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}' spec: ports: - port: 80 name: service-test protocol: TCP targetPort: 8000
Sie müssen die Datei service_sample.yaml
nicht ändern.
Name der NEG speichern
Speichern Sie den Namen der NEG in der Variable NEG_NAME:
NEG_NAME="service-test-neg"
Clientanwendung in GKE bereitstellen
Führen Sie den folgenden Befehl aus, um einen Democlient mit einem Envoy-Proxy als Sidecar zu starten. Damit müssen Sie die Sicherheitsfeatures demonstrieren.
wget -q -O - https://storage.googleapis.com/traffic-director/security/ga/client_sample.yaml | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > client_sample.yaml kubectl apply -f client_sample.yaml
Die Client-Pod-Spezifikation enthält nur die Annotation enableManagedCerts
. Dies ist erforderlich, um die notwendigen Volumes für von GKE verwaltete Mesh-Zertifikate und Schlüssel bereitzustellen, die von der CA Service-Instanz signiert sind.
Google Cloud-Ressourcen von Cloud Service Mesh konfigurieren
Führen Sie die Schritte unter Cloud Service Mesh mit Cloud Load Balancing-Komponenten konfigurieren aus. Prüfen Sie, ob der Traffic des Beispielclients an den Beispieldienst weitergeleitet wird.
Die Konfiguration von Cloud Service Mesh ist abgeschlossen. Sie können jetzt die Authentifizierungs- und Autorisierungsrichtlinien konfigurieren.
Dienst-zu-Dienst-Sicherheit einrichten
Richten Sie die Sicherheit von Dienst zu Dienst mithilfe der folgenden Abschnitte ein.
mTLS im Mesh-Netzwerk aktivieren
Zum Einrichten von mTLS in Ihrem Mesh-Netzwerk müssen Sie den ausgehenden Traffic zum Backend-Dienst und eingehenden Traffic an den Endpunkt sichern.
Format für Richtlinienverweise
Beachten Sie das folgende erforderliche Format für Verweise auf Server-TLS-, Client-TLS- und Autorisierungsrichtlinien:
projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies|authorizationPolicies]/[server-tls-policy|client-mtls-policy|authz-policy]
Beispiel:
projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
Ausgehenden Traffic zum Backend-Dienst schützen
Zum Sichern des ausgehenden Traffics erstellen Sie zuerst eine Client-TLS-Richtlinie, die Folgendes tut:
- Verwendet
google_cloud_private_spiffe
als Plug-in fürclientCertificate
, damit Envoy die von GKE verwalteten Mesh-Zertifikate als Clientidentität nutzt. - Verwendet
google_cloud_private_spiffe
als Plug-in fürserverValidationCa
, damit Envoy die von GKE verwalteten Mesh-Zertifikate zur Servervalidierung nutzt.
Als Nächstes hängen Sie die Client-TLS-Richtlinie an den Backend-Dienst an. Dies bewirkt Folgendes:
- Wendet die Authentifizierungsrichtlinie aus der Client-TLS-Richtlinie auf ausgehende Verbindungen zu Endpunkten des Back-End-Dienstes an.
- SAN (Subject Alternative Names) weist den Client an, die genaue Identität des Servers zu bestätigen, zu dem eine Verbindung hergestellt wird.
Erstellen Sie die Client-TLS-Richtlinie in der Datei
client-mtls-policy.yaml
:name: "client-mtls-policy" clientCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe serverValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Importieren Sie die Client-TLS-Richtlinie:
gcloud network-security client-tls-policies import client-mtls-policy \ --source=client-mtls-policy.yaml --location=global
Hängen Sie die Client-TLS-Richtlinie an den Back-End-Dienst an. Dadurch wird die mTLS-Authentifizierung für alle ausgehenden Anfragen vom Client an diesen Back-End-Dienst erzwungen.
gcloud compute backend-services export td-gke-service \ --global --destination=demo-backend-service.yaml
Hängen Sie die folgenden Zeilen an
demo-backend-service.yaml
an:securitySettings: clientTlsPolicy: projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy subjectAltNames: - "spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA"
Importieren Sie die Werte:
gcloud compute backend-services import td-gke-service \ --global --source=demo-backend-service.yaml
Führen Sie optional den folgenden Befehl aus, um zu prüfen, ob die Anfrage fehlschlägt. Dies ist ein unerwarteter Fehler, da der Client Zertifikate vom Endpunkt erwartet, aber der Endpunkt nicht mit einer Sicherheitsrichtlinie programmiert wurde.
# Get the name of the Podrunning Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Die Ausgabe sieht so aus:
wget: server returned error: HTTP/1.1 503 Service Unavailable
Eingehenden Traffic zum Endpunkt schützen
Erstellen Sie zuerst eine Server-TLS-Richtlinie, um den eingehenden Traffic zu sichern:
- Verwendet
google_cloud_private_spiffe
als Plug-in fürserverCertificate
, damit Envoy die von GKE verwalteten Mesh-Zertifikate als Serveridentität nutzt. - Verwendet
google_cloud_private_spiffe
als Plug-in fürclientValidationCa
, damit Envoy die von GKE verwalteten Mesh-Zertifikate zur Clientvalidierung verwendet.
Speichern Sie die Server-TLS-Richtlinienwerte in einer Datei mit dem Namen
server-mtls-policy.yaml
.name: "server-mtls-policy" serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe mtlsPolicy: clientValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Erstellen Sie die Server-TLS-Richtlinie:
gcloud network-security server-tls-policies import server-mtls-policy \ --source=server-mtls-policy.yaml --location=global
Erstellen Sie eine Datei mit dem Namen
ep_mtls.yaml
, die den Endpunkt-Matcher enthält, und hängen Sie die Server-TLS-Richtlinie an.endpointMatcher: metadataLabelMatcher: metadataLabelMatchCriteria: MATCH_ALL metadataLabels: - labelName: app labelValue: payments name: "ep" serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-mtls-policy type: SIDECAR_PROXY
Importieren Sie den Endpunkt-Matcher.
gcloud network-services endpoint-policies import ep \ --source=ep_mtls.yaml --location=global
Einrichtung validieren
Führen Sie dazu den Befehl curl
aus: Wenn die Anfrage erfolgreich ist, wird x-forwarded-client-cert
in der Ausgabe angezeigt. Der Header wird nur ausgegeben, wenn die Verbindung eine mTLS-Verbindung ist.
# Get the name of the Podrunning Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Die Ausgabe sieht in etwa so aus:
GET /get HTTP/1.1 Host: service-test content-length: 0 x-envoy-internal: true accept: */* x-forwarded-for: 10.48.0.6 x-envoy-expected-rq-timeout-ms: 15000 user-agent: curl/7.35.0 x-forwarded-proto: http x-request-id: redacted x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
Der Header x-forwarded-client-cert
wird vom serverseitigen Envoy eingefügt und enthält seine eigene Identität (Server) und die Identität des Quellclients. Da wir sowohl die Client- als auch die Serveridentitäten sehen, ist dies ein Signal für eine mTLS-Verbindung.
Zugriff auf Dienstebene mit einer Autorisierungsrichtlinie konfigurieren
In dieser Anleitung wird eine Autorisierungsrichtlinie erstellt, mit der Anfragen vom DEMO_CLIENT_KSA
-Konto zugelassen werden, in denen der Hostname service-test
lautet, der Port 8000
ist und die HTTP-Methode GET
lautet. Informieren Sie sich vor dem Erstellen von Autorisierungsrichtlinien über die Warnung unter Zugriff mithilfe der Autorisierung einschränken.
Erstellen Sie eine Autorisierungsrichtlinie, indem Sie eine Datei mit dem Namen
authz-policy.yaml
erstellen.action: ALLOW name: authz-policy rules: - sources: - principals: - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA destinations: - hosts: - service-test ports: - 8000 methods: - GET
Importieren Sie die Richtlinie:
gcloud network-security authorization-policies import authz-policy \ --source=authz-policy.yaml \ --location=global
Aktualisieren Sie die Endpunktrichtlinie so, dass sie auf die neue Autorisierungsrichtlinie verweist. Hängen Sie dazu Folgendes an die Datei
ep_mtls.yaml
an:authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
Die Endpunktrichtlinie gibt jetzt an, dass sowohl mTLS als auch die Autorisierungsrichtlinie für eingehende Anfragen an Pods erzwungen werden müssen, deren Envoy-Sidecar-Proxys das Label
app:payments
haben.Importieren Sie die Richtlinie:
gcloud network-services endpoint-policies import ep \ --source=ep_mtls.yaml --location=global
Einrichtung validieren
Führen Sie die folgenden Befehle aus, um die Einrichtung zu validieren.
# Get the name of the Podrunning Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test. # This is a valid request and will be allowed. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Die erwartete Ausgabe sieht in etwa so aus:
GET /get HTTP/1.1 Host: service-test content-length: 0 x-envoy-internal: true accept: */* x-forwarded-for: redacted x-envoy-expected-rq-timeout-ms: 15000 user-agent: curl/7.35.0 x-forwarded-proto: http x-request-id: redacted x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
Führen Sie die folgenden Befehle aus, um zu testen, ob die Autorisierungsrichtlinie ungültige Anfragen korrekt ablehnt:
# Failure case # Command to execute that tests connectivity to the service service-test. # This is an invalid request and server will reject because the server # authorization policy only allows GET requests. TEST_CMD="wget -q -O - service-test --post-data='' ; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Die erwartete Ausgabe sieht in etwa so aus:
<RBAC: access denied HTTP/1.1 403 Forbidden>
Ingress-Gateway-Sicherheit einrichten
In diesem Abschnitt wird davon ausgegangen, dass Sie den Abschnitt zur Sicherheit zwischen Diensten abgeschlossen haben, einschließlich der Einrichtung Ihres GKE-Clusters mit dem automatischen Sidecar-Injektor, der Erstellung einer Zertifizierungsstelle und der Erstellung einer Endpunktrichtlinie.
In diesem Abschnitt stellen Sie einen Envoy-Proxy als Ingress-Gateway bereit, das TLS-Verbindungen beendet und Anfragen von den internen Clients eines Clusters autorisiert.
So richten Sie ein Ingress-Gateway zum Beenden von TLS ein:
- Stellen Sie einen Kubernetes-Dienst bereit, der über eine interne Cluster-IP-Adresse erreichbar ist.
- Die Bereitstellung besteht aus einem eigenständigen Envoy-Proxy, der als Kubernetes-Dienst und stellt eine Verbindung zu Cloud Service Mesh her.
- Erstellen Sie eine Server-TLS-Richtlinie, um TLS zu beenden.
- Erstellen Sie eine Autorisierungsrichtlinie, um eingehende Anfragen zu autorisieren.
Ingress-Gateway-Dienst für GKE bereitstellen
Führen Sie den folgenden Befehl aus, um den Ingress-Gateway-Dienst in GKE bereitzustellen:
wget -q -O - https://storage.googleapis.com/traffic-director/security/ga/gateway_sample_xdsv3.yaml | sed -e s/PROJECT_NUMBER_PLACEHOLDER/PROJNUM/g | sed -e s/NETWORK_PLACEHOLDER/default/g | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > gateway_sample.yaml kubectl apply -f gateway_sample.yaml
Die Datei gateway_sample.yaml
ist die Spezifikation für das Ingress-Gateway. In den folgenden Abschnitten werden einige Ergänzungen der Spezifikation beschrieben.
Einschleusung der Cloud Service Mesh-Sidecar-Datei deaktivieren
Die Spezifikation gateway_sample.yaml
stellt einen Envoy-Proxy als einzigen Container bereit. In den vorherigen Schritten wurde Envoy als Sidecar in einen Anwendungscontainer eingefügt. Sie können die Sidecar-Injektion für diesen Kubernetes-Dienst mit der folgenden Anweisung deaktivieren, damit Anfragen nicht von mehreren Envoys verarbeitet werden:
sidecar.istio.io/inject: "false"
Das richtige Volume bereitstellen
Die Spezifikation gateway_sample.yaml
stellt das Volume gke-workload-certificates
bereit.
Dieses Volume wird auch bei der Sidecar-Bereitstellung verwendet, aber es wird automatisch vom Sidecar-Injektor hinzugefügt, wenn die Annotation cloud.google.com/enableManagedCerts: "true"
erkannt wird. Das Volume gke-workload-certificates
enthält die von GKE verwalteten SPIFFE-Zertifikate und -Schlüssel, die von der eingerichteten CA Service-Instanz signiert werden.
Interne IP-Adresse des Clusters festlegen
Konfigurieren Sie das Ingress-Gateway mit einem Dienst vom Typ ClusterInternal
. Dadurch wird ein intern auflösbarer DNS-Hostname für mesh-gateway
erstellt. Wenn ein Client eine Anfrage an mesh-gateway:443
sendet, leitet Kubernetes die Anfrage sofort an den Port 8080
der Ingress-Gateway-Bereitstellung weiter.
TLS für ein Ingress-Gateway aktivieren
Folgen Sie dieser Anleitung, um TLS für ein Ingress-Gateway zu aktivieren.
Erstellen Sie eine Server-TLS-Richtlinienressource, um TLS-Verbindungen zu beenden, mit den Werten in einer Datei mit dem Namen
server-tls-policy.yaml
:description: tls server policy name: server-tls-policy serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Importieren Sie die Server-TLS-Richtlinie:
gcloud network-security server-tls-policies import server-tls-policy \ --source=server-tls-policy.yaml --location=global
Erstellen Sie eine neue URL-Zuordnung, die alle Anfragen an den Back-End-Dienst
td-gke-service
weiterleitet. Das Ingress-Gateway verarbeitet eingehende Anfragen und sendet sie an Pods, die zum Back-End-Diensttd-gke-service
gehören.gcloud compute url-maps create td-gke-ig-url-map \ --default-service=td-gke-service
Erstellen Sie einen neuen Ziel-HTTPS-Proxy in der Datei
td-gke-https-proxy.yaml
und hängen Sie die zuvor erstellte URL-Zuordnung und die Server-TLS-Richtlinie an. Damit wird das Ingress-Gateway für den Envoy-Proxy konfiguriert, um eingehenden TLS-Traffic zu beenden.kind: compute#targetHttpsProxy name: td-gke-https-proxy proxyBind: true urlMap: https://www.googleapis.com/compute/beta/projects/PROJECT_ID/global/urlMaps/td-gke-ig-url-map serverTlsPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
Importieren Sie die Richtlinie:
gcloud compute target-https-proxies import td-gke-https-proxy \ --global --source=td-gke-https-proxy.yaml
Erstellen Sie eine neue Weiterleitungsregel und hängen Sie den Ziel-HTTPS-Proxy an. Dadurch wird der Envoy-Proxy so konfiguriert, dass er Port 8080 überwacht und die in
td-gke-https-proxy
definierten Routing- und Sicherheitsrichtlinien anwendet.gcloud compute forwarding-rules create td-gke-gateway-forwarding-rule --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED --address=0.0.0.0 \ --target-https-proxy=td-gke-https-proxy --ports 8080 \ --network default
Aktualisieren Sie optional die Autorisierungsrichtlinie für die Back-Ends, um Anfragen zuzulassen, wenn alle folgenden Bedingungen erfüllt sind:
- Anfragen von
DEMO_CLIENT_KSA
gesendet. Für die Bereitstellung des Ingress-Gateways wird das DienstkontoDEMO_CLIENT_KSA
verwendet. - Anfragen mit dem Host
mesh-gateway
oderservice-test
- Port:
8000
Sie müssen diese Befehle nur ausführen, wenn Sie eine Autorisierungsrichtlinie für Ihre Back-Ends konfiguriert haben. Wenn auf dem Endpunkt keine Autorisierungsrichtlinie vorhanden ist oder keine Übereinstimmung zwischen Host- und Quellprinzipal in der Autorisierungsrichtlinie vorliegt, wird eine Anfrage ohne diesen Schritt zulässig. Fügen Sie diese Werte zu
authz-policy.yaml
hinzu:action: ALLOW name: authz-policy rules: - sources: - principals: - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA destinations: - hosts: - service-test - mesh-gateway ports: - 8000 methods: - GET
- Anfragen von
Importieren Sie die Richtlinie:
gcloud network-security authorization-policies import authz-policy \ --source=authz-policy.yaml \ --location=global
Ingress-Gateway-Deployment validieren
Sie verwenden einen neuen Container mit dem Namen debug
, um Anfragen an das Ingress-Gateway zu senden, um die Bereitstellung zu validieren.
In der folgenden Spezifikation verhindert die Annotation "sidecar.istio.io/inject":"false"
, dass der Sidecar-Injektor von Cloud Service Mesh automatisch einen Sidecar-Proxy einfügt. Es gibt kein Sidecar, um den debug
-Container beim Anfragerouting zu unterstützen.
Der Container muss zum Routing mit dem Ingress-Gateway verbunden sein.
Die Spezifikation enthält das Flag --no-check-certificate
, das die Validierung des Serverzertifikats ignoriert. Der debug
-Container verfügt nicht über die Zertifikate zur CA-Validierung, die für gültige Zertifikate erforderlich sind, die von CA Service signiert wurden und vom Ingress-Gateway zum Beenden von TLS verwendet werden.
In einer Produktionsumgebung empfehlen wir Ihnen, das CA Service-Validierungszertifikat herunterzuladen und es auf Ihrem Client bereitzustellen oder zu installieren. Entfernen Sie nach der Installation des Validierungszertifikats die Option --no-check-certificate
des Befehls wget
.
Führen Sie dazu diesen Befehl aus:
kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"
Die Ausgabe sollte in etwa so aussehen:
GET / HTTP/1.1 Host: 10.68.7.132 x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA x-envoy-expected-rq-timeout-ms: 15000 x-envoy-internal: true x-request-id: 5ae429e7-0e18-4bd9-bb79-4e4149cf8fef x-forwarded-for: 10.64.0.53 x-forwarded-proto: https content-length: 0 user-agent: Wget
Führen Sie den folgenden Befehl für einen negativen Test aus:
# Negative test # Expect this to fail because gateway expects TLS. kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - http://mesh-gateway:443/headers; echo"
Die Ausgabe sollte in etwa so aussehen:
wget: error getting response: Connection reset by peer
Führen Sie den folgenden Befehl für einen negativen Test aus:
# Negative test. # AuthorizationPolicy applied on the endpoints expect a GET request. Otherwise # the request is denied authorization. kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway --post-data=''; echo"
Die Ausgabe sollte in etwa so aussehen:
HTTP/1.1 403 Forbidden wget: server returned error: HTTP/1.1 403 Forbidden
Autorisierungsrichtlinie für das Ingress-Gateway einrichten
Mit der hier eingerichteten Autorisierungsrichtlinie kann das Ingress-Gateway Anfragen an das Mesh-Netzwerk zulassen, wenn die folgenden Bedingungen erfüllt sind:
- Host:
mesh-gateway
- Port:
8080
- Pfad:
*
- HTTP-Methode = GET
Erstellen Sie eine Autorisierungsrichtlinie in der Datei
authz-gateway-policy.yaml
:action: ALLOW name: authz-gateway-policy rules: - destinations: - hosts: - mesh-gateway ports: - 8080 methods: - GET
Importieren Sie die Werte in die Datei:
gcloud network-security authorization-policies import authz-gateway-policy \ --source=authz-gateway-policy.yaml --location=global
Bearbeiten Sie die Datei
td-gke-https-proxy.yaml
, indem Sie Folgendes hinzufügen:authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-gateway-policy
Importieren Sie die Datei "td-gke-https-proxy.yaml" noch einmal:
gcloud compute target-https-proxies import td-gke-https-proxy \ --global --source=td-gke-https-proxy.yaml
Deployment validieren
Führen Sie den folgenden Befehl aus, um Ihr Deployment zu validieren:
# On your localhost. kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"
Die Ausgabe sollte in etwa so aussehen:
GET / HTTP/1.1 Host: 35.196.50.2 x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA x-envoy-expected-rq-timeout-ms: 15000 user-agent: curl/7.72.0 x-forwarded-proto: https content-length: 0 x-envoy-internal: true x-request-id: 98bec135-6df8-4082-8edc-b2c23609295a accept: */* x-forwarded-for: 10.142.0.7
Führen Sie den folgenden Befehl für einen negativen Test aus:
# Negative test. Expect failure because only POST method is allowed by \ # authz-gateway-policy kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway/ --post-data=''; echo"
Die Ausgabe sollte in etwa so aussehen:
wget: server returned error: HTTP/1.1 403 Forbidden
Deployment löschen
Optional können Sie diese Befehle ausführen, um die Bereitstellung zu löschen, die Sie in dieser Anleitung erstellt haben.
Führen Sie den folgenden Befehl aus, um den Cluster zu löschen:
gcloud container clusters delete CLUSTER_NAME --zone ZONE --quiet
Führen Sie die folgenden Befehle aus, um die von Ihnen erstellten Ressourcen zu löschen:
gcloud compute forwarding-rules delete td-gke-forwarding-rule --global --quiet gcloud compute forwarding-rules delete td-gke-gateway-forwarding-rule --global \ --quiet gcloud compute target-http-proxies delete td-gke-proxy --quiet gcloud compute target-https-proxies delete td-gke-https-proxy --quiet gcloud compute url-maps delete td-gke-url-map --quiet gcloud compute url-maps delete td-gke-ig-url-map --quiet gcloud compute backend-services delete td-gke-service --global --quiet cloud compute network-endpoint-groups delete service-test-neg --zone ZONE --quiet gcloud compute firewall-rules delete fw-allow-health-checks --quiet gcloud compute health-checks delete td-gke-health-check --quiet gcloud network-services endpoint-policies delete ep \ --location=global --quiet gcloud network-security authorization-policies delete authz-gateway-policy \ --location=global --quiet gcloud network-security authorization-policies delete authz-policy \ --location=global --quiet gcloud network-security client-tls-policies delete client-mtls-policy \ --location=global --quiet gcloud network-security server-tls-policies delete server-tls-policy \ --location=global --quiet gcloud network-security server-tls-policies delete server-mtls-policy \ --location=global --quiet
Beschränkungen
Die Sicherheit des Cloud Service Mesh-Dienstes wird nur unterstützt mit GKE Sie können die Dienstsicherheit nicht mit der Compute Engine bereitstellen.
Fehlerbehebung
Dieser Abschnitt enthält Informationen zur Behebung von Problemen, die während der Einrichtung des Sicherheitsdiensts auftreten können.
Verbindungsfehler
Wenn die Verbindung aufgrund des Fehlers upstream connect
oder disconnect/reset
before headers
fehlschlägt, sehen Sie sich die Envoy-Logs an. Möglicherweise wird eine der folgenden Lognachrichten angezeigt:
gRPC config stream closed: 5, Requested entity was not found
gRPC config stream closed: 2, no credential token is found
Wenn Sie diese Fehler im Envoy-Log sehen, ist es möglich, dass das Dienstkonto-Token falsch bereitgestellt wurde oder eine andere audience
verwendet wird oder beides.
Weitere Informationen finden Sie unter Fehlermeldungen in den Envoy-Logs weisen auf ein Konfigurationsproblem hin.
Pods nicht erstellt
Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei automatischen Bereitstellungen für GKE-Pods.
Envoy authentifiziert sich nicht bei Cloud Service Mesh
Wenn Envoy (envoy-proxy
) eine Verbindung zu Cloud Service Mesh herstellt, um xDS abzurufen
wird die Identitätsföderation von Arbeitslasten für GKE und die Compute Engine-VM verwendet.
Standarddienstkonto (es sei denn, das Bootstrap wurde geändert). Wenn die Authentifizierung fehlschlägt, erreicht Envoy nicht den Bereitschaftszustand.
Cluster kann nicht mit --workload-identity-certificate-authority flag
erstellt werden
Wenn dieser Fehler angezeigt wird, prüfen Sie, ob Sie die neueste Version der Google Cloud CLI ausführen:
gcloud components update
Pods verbleiben im Status „Ausstehend“
Wenn die Pods während der Einrichtung im Status "Ausstehend" verbleiben, erhöhen Sie die CPU- und Arbeitsspeicherressourcen für die Pods in der Deployment-Spezifikation.
Cluster mit dem Flag --enable-mesh-certificates
kann nicht erstellt werden
Prüfen Sie, ob die neueste Version der gcloud CLI ausgeführt wird:
gcloud components update
Beachten Sie, dass das Flag --enable-mesh-certificates
nur mit gcloud beta
funktioniert.
Pods werden nicht gestartet
Pods, die GKE-Mesh-Zertifikate verwenden, starten möglicherweise nicht, wenn die Zertifikatbereitstellung fehlschlägt. Das kann in Situationen wie den folgenden passieren:
WorkloadCertificateConfig
oderTrustConfig
ist falsch konfiguriert oder fehlt.- CSRs werden nicht genehmigt.
Sie können prüfen, ob die Zertifikatbereitstellung fehlschlägt, indem Sie die Pod-Ereignisse prüfen.
Prüfen Sie den Status Ihres Pods:
kubectl get pod -n POD_NAMESPACE POD_NAME
Dabei gilt:
POD_NAMESPACE
: der Namespace Ihres Pods.POD_NAME
: der Name Ihres Pods.
Prüfen Sie die letzten Ereignisse für den Pod:
kubectl describe pod -n POD_NAMESPACE POD_NAME
Wenn die Bereitstellung von Zertifikaten fehlschlägt, wird ein Ereignis mit
Type=Warning
,Reason=FailedMount
,From=kubelet
und mit einemMessage
-Feld angezeigt, das mitMountVolume.SetUp failed for volume "gke-workload-certificates"
beginnt. Das FeldMessage
enthält Informationen zur Fehlerbehebung.Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedMount 13s (x7 over 46s) kubelet MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)
Führen Sie die folgenden Schritte zur Fehlerbehebung aus, wenn die Pods nicht starten, weil falsch konfigurierte Objekte oder abgelehnte CSRs vorliegen.
WorkloadCertificateConfig
oder TrustConfig
ist falsch konfiguriert
Prüfen Sie, ob die WorkloadCertificateConfig
- und TrustConfig
-Objekte korrekt erstellt wurden. Sie können Fehlkonfigurationen für eines dieser Objekte mit kubectl
diagnostizieren.
Rufen Sie den aktuellen Status ab.
Für
WorkloadCertificateConfig
:kubectl get WorkloadCertificateConfig default -o yaml
Für
TrustConfig
:kubectl get TrustConfig default -o yaml
Prüfen Sie die Statusausgabe. Ein gültiges Objekt hat eine Bedingung mit
type: Ready
undstatus: "True"
.status: conditions: - lastTransitionTime: "2021-03-04T22:24:11Z" message: WorkloadCertificateConfig is ready observedGeneration: 1 reason: ConfigReady status: "True" type: Ready
Bei ungültigen Objekten wird stattdessen
status: "False"
angezeigt. Die Felderreason
undmessage
enthalten zusätzliche Informationen zur Fehlerbehebung.
CSRs sind nicht genehmigt
Wenn bei der CSR-Genehmigung ein Fehler auftritt, können Sie die Fehlerdetails in den Bedingungen type: Approved
und type: Issued
der CSR überprüfen.
Listen Sie die relevanten CSRs mithilfe von
kubectl
auf:kubectl get csr \ --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'
Wählen Sie eine CSR aus, für die entweder
Approved
und nichtIssued
gilt oder für dieApproved
nicht gilt.Rufen Sie mithilfe von kubectl Details zur ausgewählten CSR ab:
kubectl get csr CSR_NAME -o yaml
Ersetzen Sie
CSR_NAME
durch den Namen der ausgewählten CSR.
Eine gültige CSR hat eine Bedingung mit type: Approved
und status: "True"
und ein gültiges Zertifikat im Feld status.certificate
:
status:
certificate: <base64-encoded data>
conditions:
- lastTransitionTime: "2021-03-04T21:58:46Z"
lastUpdateTime: "2021-03-04T21:58:46Z"
message: Approved CSR because it is a valid SPIFFE SVID for the correct identity.
reason: AutoApproved
status: "True"
type: Approved
Informationen zur Fehlerbehebung für ungültige CSRs werden in den Feldern message
und reason
angezeigt.
Anwendungen können keine ausgestellten mTLS-Anmeldedaten verwenden
Prüfen Sie, ob das Zertifikat noch gültig ist:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Prüfen Sie, ob der verwendete Schlüsseltyp von der Anwendung unterstützt wird.
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
Prüfen Sie, ob die ausstellende Zertifizierungsstelle die gleiche Schlüsselfamilie wie der Zertifikatschlüssel verwendet.
Rufen Sie den Status der CA Service-Instanz (Vorschau) ab:
gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \ --location ISSUING_CA_LOCATION
Dabei gilt:
ISSUING_CA_TYPE
: der ausstellende CA-Typ, der entwedersubordinates
oderroots
sein muss.ISSUING_CA_NAME
: der Name der ausstellenden CA.ISSUING_CA_LOCATION
: die Region der ausstellenden Zertifizierungsstelle.
Prüfen Sie, ob der
keySpec.algorithm
in der Ausgabe der gleiche Schlüsselalgorithmus ist wie der, den Sie im YAML-ManifestWorkloadCertificateConfig
definiert haben. Sie erhalten folgende Ausgabe:config: ... subjectConfig: commonName: td-sub-ca subject: organization: TestOrgLLC subjectAltName: {} createTime: '2021-05-04T05:37:58.329293525Z' issuingOptions: includeCaCertUrl: true keySpec: algorithm: RSA_PKCS1_2048_SHA256 ...
Zertifikate werden abgelehnt
- Prüfen Sie, ob die Peer-Anwendung dasselbe Vertrauens-Bundle verwendet, um das Zertifikat zu verifizieren.
Prüfen Sie, ob das Zertifikat noch gültig ist:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Prüfen Sie, ob der Clientcode regelmäßig die Anmeldedaten aus dem Dateisystem aktualisiert, wenn die Go API für das Neuladen der Anmeldedaten für gRPC nicht verwendet wird.
Prüfen Sie, ob sich Ihre Arbeitslasten in derselben vertrauenswürdigen Domain wie Ihre Zertifizierungsstelle befinden. GKE-Mesh-Zertifikate unterstützen die Kommunikation zwischen Arbeitslasten in einer einzigen vertrauenswürdigen Domain.