Versi 1.20

Versi yang tersedia

1.20 (terbaru)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.12

219}

Halaman ini diterjemahkan oleh Cloud Translation API.

Menyiapkan keamanan layanan dengan Envoy dan load balancing API (lama)

Gunakan petunjuk dalam panduan ini untuk mengonfigurasi autentikasi dan otorisasi untuk layanan yang di-deploy dengan proxy Cloud Service Mesh dan Envoy menggunakan load balancing Google Cloud Platform. Jika Anda menggunakan API perutean layanan, baca Menyiapkan keamanan layanan dengan Envoy.

Untuk informasi selengkapnya tentang, lihat Keamanan layanan Cloud Service Mesh dengan load balancing API.

Dokumen ini berlaku untuk konfigurasi yang menggunakan API load balancing. Ini adalah dokumen lama.

Persyaratan

Sebelum mengonfigurasi keamanan layanan untuk Cloud Service Mesh dengan Envoy, pastikan pastikan penyiapan Anda memenuhi prasyarat berikut:

Gunakan Envoy versi 1.20.0 atau yang lebih baru untuk xDS v3 API.
Anda dapat memenuhi semua persyaratan untuk men-deploy Cloud Service Mesh. Sebagai informasi lengkap tentang persyaratan ini, lihat Persiapan untuk menyiapkan Cloud Service Mesh dengan Envoy.
Anda memiliki izin yang memadai untuk membuat atau memperbarui Cloud Service Mesh dan Resource mesh layanan Google Cloud untuk menggunakan keamanan layanan, seperti yang dijelaskan di Persiapan untuk menyiapkan Cloud Service Mesh dengan Envoy.

Mempersiapkan penyiapan

Bagian berikut menjelaskan tugas yang perlu Anda selesaikan sebelum menyiapkan Layanan keamanan Cloud Service Mesh. Tugas-tugas tersebut adalah:

Mengupdate Google Cloud CLI
Menyiapkan variabel
Mengaktifkan API yang diperlukan agar dapat digunakan oleh Cloud Service Mesh {i>Certificate Authority Service<i}

Mengupdate alat command line `gcloud`

Untuk mengupdate Google Cloud CLI, jalankan perintah berikut di jaringan lokal Anda komputer:

gcloud components update

Menyiapkan variabel

Tetapkan variabel berikut sehingga Anda dapat menyalin dan menempelkan kode secara konsisten saat Anda mengerjakan contoh dalam dokumen ini. Gunakan yang berikut masing-masing.

PROJECT_ID: Mengganti ID project Anda.
CLUSTER_NAME: Mengganti nama cluster yang ingin Anda kita, misalnya, secure-td-cluster.
ZONE: Mengganti zona tempat cluster Anda berada. cluster Anda berada.
GKE_CLUSTER_URL: Pengganti https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
WORKLOAD_POOL: Pengganti PROJECT_ID.svc.id.goog
K8S_NAMESPACE: Ganti default.
DEMO_CLIENT_KSA: Mengganti nama klien Anda akun layanan Kubernetes.
DEMO_SERVER_KSA: Mengganti nama server Anda akun layanan Kubernetes.
PROJNUM: Ganti nomor project project Anda, yang dapat Anda tentukan dari konsol Google Cloud atau dengan perintah ini:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
SA_GKE: Pengganti service-PROJNUM@container-engine-robot.
CLUSTER_VERSION: Mengganti versi terbaru yang tersedia. Anda dapat menemukannya di Catatan rilis saluran cepat. Versi minimum yang diperlukan adalah 1.21.4-gke.1801. Ini adalah project GKE versi cluster yang akan digunakan dalam contoh ini.

Tetapkan nilai di sini:

# 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.

Mengaktifkan API

Menggunakan gcloud services enable untuk mengaktifkan semua API yang Anda perlukan guna menyiapkan Cloud Service Mesh keamanan dengan 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

Membuat atau mengupdate cluster GKE

Keamanan layanan Cloud Service Mesh bergantung pada CA Service integrasi Anda dengan GKE. Cluster GKE harus memenuhi persyaratan berikut selain persyaratan penyiapan:

Gunakan versi cluster minimum 1.21.4-gke.1801. Jika Anda membutuhkan fitur yang tersedia dalam versi yang lebih baru, Anda dapat memperoleh versi tersebut dari rilis cepat saluran TV Anda.
Cluster GKE harus diaktifkan dan dikonfigurasi dengan mesh sertifikat, seperti yang dijelaskan dalam Membuat certificate authority untuk menerbitkan sertifikat.

Buat cluster baru yang menggunakan Workload Identity Federation untuk GKE. Jika Anda memperbarui cluster yang ada, lanjutkan ke langkah berikutnya. Nilai yang Anda berikan untuk --tags harus cocok dengan nama yang diteruskan ke flag --target-tags untuk Perintah firewall-rules create di bagian Mengonfigurasi Cloud Service Mesh dengan komponen Cloud Load Balancing.

# 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

Mungkin perlu waktu beberapa menit untuk menyelesaikan pembuatan cluster.

Jika Anda menggunakan cluster yang ada, aktifkan Workload Identity Federation for GKE lalu Sertifikat mesh GKE. Pastikan cluster sudah dibuat dengan flag --enable-ip-alias, yang tidak dapat digunakan dengan update perintah.
```
gcloud container clusters update CLUSTER_NAME \
  --enable-mesh-certificates
```
Jalankan perintah berikut untuk beralih ke cluster baru sebagai cluster default untuk perintah kubectl Anda:
```
gcloud container clusters get-credentials CLUSTER_NAME \
  --zone ZONE
```

Men-deploy di lingkungan multi-cluster

Jika Anda men-deploy di lingkungan multi-cluster, ikuti persyaratan prosedur yang dijelaskan dalam bagian ini. Petunjuk ini mengasumsikan bahwa Pod klien berjalan di satu cluster dan Pod server berjalan di klaster lainnya.

Buat atau update cluster menggunakan petunjuk di bagian sebelumnya bagian.

Ambil rentang alamat IP Pod untuk setiap cluster menggunakan berikut:

gcloud compute firewall-rules list \
  --filter="name~gke-{CLUSTER_NAME}-[0-9a-z]*-all" \
  --format="value(sourceRanges)"

Misalnya, untuk cluster yang disebut cluster-a dan cluster-b, perintahnya tampilkan hasil seperti berikut:

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

Buat aturan firewall VPC yang memungkinkan cluster untuk berkomunikasi satu sama lain. Misalnya, perintah berikut akan membuat aturan firewall yang mengizinkan alamat IP pod cluster-a untuk berkomunikasi cluster-b node:
```
gcloud compute firewall-rules create per-cluster-a-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-b-acd14479-node"
```
Perintah berikut membuat aturan firewall yang mengizinkan cluster-b alamat IP pod untuk berkomunikasi dengan node cluster-a:
```
gcloud compute firewall-rules create per-cluster-b-pods \
  --allow="tcp,udp,icmp,esp,ah,sctp" \
  --target-tags="gke-cluster-a-9cd18751-node"
```

Mendaftarkan cluster dengan fleet

Mendaftarkan cluster yang Anda buat atau perbarui Membuat cluster GKE dengan fleet. Dengan mendaftarkan cluster, Anda akan lebih mudah untuk mengonfigurasi cluster di beberapa project.

Perhatikan bahwa setiap langkah ini dapat memerlukan waktu hingga sepuluh menit untuk diselesaikan.

Daftarkan cluster Anda ke fleet:
```
gcloud container fleet memberships register CLUSTER_NAME \
  --gke-cluster=ZONE/CLUSTER_NAME \
  --enable-workload-identity --install-connect-agent \
  --manifest-output-file=MANIFEST-FILE_NAME
```
Ganti variabel sebagai berikut:
- CLUSTER_NAME: Nama cluster Anda.
- ZONE: Zona cluster Anda.
- MANIFEST-FILE_NAME: Jalur tempat perintah ini membuat manifes untuk pendaftaran.
Ketika proses pendaftaran berhasil, Anda akan melihat pesan seperti berikut ini:
```
Finished registering the cluster CLUSTER_NAME with the fleet.
```

Terapkan file manifes yang dihasilkan ke cluster Anda:

kubectl apply -f MANIFEST-FILE_NAME

Ketika proses aplikasi berhasil, Anda akan melihat pesan seperti berikut ini:

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

Dapatkan resource keanggotaan dari cluster:
```
kubectl get memberships membership -o yaml
```
{i>Output<i} harus mencakup kumpulan {i>Workoad Identity<i} yang ditetapkan oleh armada, dengan PROJECT_ID adalah project ID Anda:
```
workload_identity_pool: PROJECT_ID.svc.id.goog
```
Artinya, cluster berhasil didaftarkan.

Membuat certificate authority untuk menerbitkan sertifikat

Guna menerbitkan sertifikat untuk Pod Anda, buat kumpulan CA Service dan otoritas sertifikat (CA) berikut:

CA root. Ini adalah root kepercayaan untuk semua sertifikat mesh yang diterbitkan. Anda dapat menggunakan CA {i>root<i} yang sudah ada jika Anda memilikinya. Membuat root CA di Tingkat enterprise, yang dimaksudkan untuk sertifikat bervolume rendah berumur panjang yang diterbitkan.
CA Subordinate. CA ini menerbitkan sertifikat untuk workload. Buat subordinate di region tempat cluster Anda di-deploy. Buat CA subordinat di tingkat devops, yang dimaksudkan untuk jangka pendek, penerbitan sertifikat dalam jumlah besar.

Pembuatan CA subordinat bersifat opsional, tetapi kami sangat menyarankan untuk membuatnya dan tidak menggunakan root CA untuk menerbitkan sertifikat mesh GKE. Jika Anda memutuskan untuk menggunakan CA {i>root<i} untuk menerbitkan sertifikat mesh, pastikan bahwa mode penerbitan berbasis konfigurasi default tetap diizinkan.

CA subordinat bisa berada di region yang berbeda dari cluster Anda, tetapi kami sebaiknya Anda membuatnya di region yang sama dengan cluster untuk mengoptimalkan tingkat tinggi. Namun, Anda dapat membuat CA {i>root<i} dan subordinate di berbagai region tanpa memengaruhi performa atau ketersediaan.

Region berikut didukung untuk CA Service:

Nama region	Deskripsi region
`asia-east1`	Taiwan
`asia-east2`	Hong Kong
`asia-northeast1`	Tokyo
`asia-northeast2`	Osaka
`asia-northeast3`	Seoul
`asia-south1`	Mumbai
`asia-south2`	Delhi
`asia-southeast1`	Singapura
`asia-southeast2`	Jakarta
`australia-southeast1`	Sydney
`australia-southeast2`	Melbourne
`europe-central2`	Warsawa
`europe-north1`	Finlandia
`europe-southwest1`	Madrid
`europe-west1`	Belgia
`europe-west2`	London
`europe-west3`	Frankfurt
`europe-west4`	Belanda
`europe-west6`	Zürich
`europe-west8`	Milan
`europe-west9`	Paris
`europe-west10`	Berlin
`europe-west12`	Turin
`me-central1`	Doha
`me-central2`	Dammam
`me-west1`	Tel Aviv
`northamerica-northeast1`	Montréal
`northamerica-northeast2`	Toronto
`southamerica-east1`	Sao 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

Daftar lokasi yang didukung juga dapat diperiksa dengan menjalankan perintah berikut:

gcloud privateca locations list

Memberikan roles/privateca.caManager IAM ke individu yang membuat kumpulan CA dan CA. Perhatikan bahwa untuk MEMBER, format yang benar adalah user:userid@example.com. Jika orang tersebut adalah Anda bisa mendapatkan ID pengguna saat ini dengan perintah{i> shell<i} $(gcloud auth list --filter=status:ACTIVE --format="value(account)").
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.caManager
```
Berikan peran role/privateca.admin untuk CA Service kepada individu yang perlu mengubah kebijakan IAM, dengan MEMBER sebagai individu yang membutuhkan akses ini, khususnya, setiap individu yang melakukan langkah-langkah yang mengikutinya memberikan privateca.auditor dan Peran privateca.certificateManager:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.admin
```

Membuat kumpulan root CA Service.

gcloud privateca pools create ROOT_CA_POOL_NAME \
  --location ROOT_CA_POOL_LOCATION \
  --tier enterprise

Membuat root 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

Untuk penyiapan demonstrasi ini, gunakan nilai berikut untuk variabel:

ROOT_CA_POOL_NAME=td_sec_pool
ROOT_CA_NAME=pkcs2-ca
ROOT_CA_POOL_LOCATION=us-east1
ROOT_CA_ORGANIZATION="TestCorpLLC"

Membuat kumpulan subordinate dan CA subordinate. Pastikan bahwa mode penerbitan berbasis konfigurasi tetap diizinkan.

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

Untuk penyiapan demonstrasi ini, gunakan nilai berikut untuk variabel:

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

Memberikan peran IAM privateca.auditor untuk kumpulan root CA ke mengizinkan akses dari akun layanan GKE:

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."

Memberikan IAM privateca.certificateManager bagi kumpulan CA subordinate untuk mengizinkan akses dari GKE akun layanan:

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."

Simpan konfigurasi YAML WorkloadCertificateConfig berikut untuk memberi tahu cara menerbitkan sertifikat mesh pada cluster Anda:

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

Ganti kode berikut:

Project ID project tempat cluster Anda berjalan:
```
PROJECT_ID
```
URI CA yang sepenuhnya memenuhi syarat yang menerbitkan sertifikat mesh Anda (ISSUING_CA_POOL_URI). CA ini bisa berupa subordinate CA (direkomendasikan) atau root CA Anda. Formatnya adalah:
```
//privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
```

Simpan konfigurasi YAML TrustConfig berikut untuk memberi tahu cluster Anda cara untuk memercayai sertifikat yang diterbitkan:

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

Ganti kode berikut:

Project ID project tempat cluster Anda berjalan:
```
PROJECT_ID
```

URI yang sepenuhnya memenuhi syarat dari kumpulan root CA (ROOT_CA_POOL_URI). Formatnya adalah:

//privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME

Terapkan konfigurasi tersebut ke cluster Anda:

kubectl apply -f WorkloadCertificateConfig.yaml
kubectl apply -f TrustConfig.yaml

Mengonfigurasi Identity and Access Management

Untuk membuat resource yang diperlukan untuk penyiapan, Anda harus memiliki Peran compute.NetworkAdmin. Peran ini berisi semua izin yang diperlukan untuk membuat, memperbarui, menghapus, membuat daftar, dan menggunakan (yaitu, merujuk ini di resource) resource yang diperlukan. Jika Anda adalah pemilik-editor proyek, Anda secara otomatis memiliki peran ini.

Perhatikan bahwa networksecurity.googleapis.com.clientTlsPolicies.use dan networksecurity.googleapis.com.serverTlsPolicies.use tidak diterapkan saat Anda merujuk ke resource ini di layanan backend dan proxy HTTPS target Google Cloud Platform.

Jika izin ini diberlakukan di masa mendatang dan Anda menggunakan compute.NetworkAdmin peran, maka Anda tidak akan melihat masalah apa pun saat pemeriksaan ini diberlakukan.

Jika menggunakan peran khusus dan pemeriksaan ini diberlakukan di masa mendatang, Anda harus pastikan untuk menyertakan izin .use yang sesuai. Jika tidak, di masa mendatang, Anda mungkin mendapati bahwa peran khusus Anda tidak memiliki izin yang diperlukan untuk merujuk ke clientTlsPolicy atau serverTlsPolicy dari layanan backend atau menargetkan proxy HTTPS.

Petunjuk berikut memungkinkan akun layanan default mengakses Cloud Service Mesh Security API dan membuat akun layanan Kubernetes.

Mengonfigurasi IAM untuk mengizinkan akun layanan default mengakses 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

Menyiapkan akun layanan Kubernetes. Implementasi klien dan server pada bagian berikut menggunakan Kname dari server dan klien Kubernetes akun layanan.

kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA

Mengizinkan akun layanan Kubernetes meniru identitas Compute Engine default akun layanan Anda dengan membuat ikatan kebijakan IAM di antara keduanya. Ini Dengan binding memungkinkan akun layanan Kubernetes bertindak sebagai default menggunakan akun layanan Compute Engine.

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}

Menganotasi akun layanan Kubernetes untuk mengaitkannya dengan akun layanan default menggunakan akun layanan Compute Engine.

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}

Menyiapkan Cloud Service Mesh

Gunakan petunjuk berikut untuk menginstal injektor file bantuan, menyiapkan pengujian layanan deployment, dan menyelesaikan tugas deployment lainnya.

Memasang injektor file bantuan Envoy di cluster

Gunakan petunjuk di kedua bagian berikut dalam Penyiapan Cloud Service Mesh untuk Pod GKE dengan injeksi Envoy otomatis untuk men-deploy dan mengaktifkan injeksi file bantuan Envoy di cluster Anda:

Pastikan Anda menyelesaikan kedua rangkaian petunjuk sebelum menyiapkan layanan pengujian.

Menyiapkan layanan pengujian

Setelah Anda menginstal injektor file bantuan Envoy, gunakan petunjuk ini untuk menyiapkan layanan pengujian untuk deployment Anda.

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

File service_sample.yaml berisi podspec untuk server demo Anda aplikasi. Ada beberapa anotasi khusus untuk Cloud Service Mesh keamanan.

Metadata proxy Cloud Service Mesh

Podspec menentukan anotasi proxyMetadata:

spec:
...
      annotations:
        cloud.google.com/proxyMetadata: '{"app": "payments"}'
...

Saat Pod diinisialisasi, proxy file bantuan mengambil anotasi ini dan mentransmisikannya ke Cloud Service Mesh. Cloud Service Mesh selanjutnya dapat menggunakan untuk mengirim kembali konfigurasi yang difilter:

Di bagian selanjutnya dalam panduan ini, perhatikan bahwa kebijakan endpoint menentukan pencocok endpoint.
Pencocok endpoint menentukan bahwa hanya klien yang menampilkan label nama app dan nilai payments akan menerima konfigurasi yang difilter.

Gunakan sertifikat mesh dan kunci yang ditandatangani oleh CA Service

Podspec menentukan anotasi enableManagedCerts:

spec:
...
      annotations:
        ...
        cloud.google.com/enableManagedCerts: "true"
...

Saat Pod diinisialisasi, CA Service menandatangani sertifikat dan kunci secara otomatis dipasang pada sistem file proxy file bantuan lokal.

Mengonfigurasi port intersepsi traffic masuk

Podspec menentukan anotasi includeInboundPorts:

spec:
...
      annotations:
        ...
        cloud.google.com/includeInboundPorts: "8000"
...

Ini adalah porta yang digunakan aplikasi server Anda untuk mendengarkan koneksi. Kapan Pod diinisialisasi, proxy file bantuan mengambil anotasi ini dan mengirimkan ke Cloud Service Mesh. Cloud Service Mesh kemudian dapat menggunakan informasi ini untuk mengirim kembali konfigurasi yang difilter yang mencegat semua lalu lintas yang masuk ke porta ini dan dapat menerapkan kebijakan keamanan padanya.

Port health check harus berbeda dengan port aplikasi. Jika tidak, kebijakan keamanan yang sama akan berlaku untuk koneksi masuk ke layanan memeriksa porta yang dapat menyebabkan koneksi ditolak yang menyebabkan server yang salah ditandai sebagai tidak responsif.

Mengonfigurasi layanan GKE dengan NEG

Layanan GKE harus diekspos melalui grup endpoint jaringan (NEG) agar Anda dapat mengonfigurasinya sebagai backend dari backend Cloud Service Mesh layanan. Paket service_sample.yaml yang disediakan dengan panduan penyiapan ini menggunakan nama NEG service-test-neg dalam anotasi berikut:

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Anda tidak perlu mengubah file service_sample.yaml.

Menyimpan nama NEG

Simpan nama NEG di variabel NEG_NAME:

NEG_NAME="service-test-neg"

Men-deploy aplikasi klien ke GKE

Jalankan perintah berikut untuk meluncurkan klien demonstrasi dengan proxy Envoy sebagai file bantuan, di mana Anda perlu mendemonstrasikan fitur keamanannya.

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

Podspec klien hanya menyertakan anotasi enableManagedCerts. Ini adalah yang diperlukan untuk memasang volume yang diperlukan untuk mesh terkelola GKE sertifikat dan kunci yang ditandatangani oleh {i>instance<i} CA Service.

Mengonfigurasi resource Google Cloud Cloud Service Mesh

Ikuti langkah-langkah di Mengonfigurasi Cloud Service Mesh dengan komponen Cloud Load Balancing. Pastikan untuk memverifikasi bahwa traffic dari klien contoh dirutekan ke layanan contoh.

Konfigurasi Cloud Service Mesh selesai dan sekarang Anda dapat mengonfigurasi kebijakan otentikasi dan otorisasi.

Menyiapkan keamanan antarlayanan

Gunakan petunjuk di bagian berikut untuk menyiapkan layanan-ke-layanan keamanan.

Mengaktifkan mTLS di mesh

Untuk menyiapkan mTLS di mesh, Anda harus mengamankan traffic keluar ke backend dan traffic masuk yang aman ke endpoint.

Format untuk referensi kebijakan

Perhatikan format yang dibutuhkan berikut ini untuk merujuk ke TLS server, TLS klien, dan kebijakan otorisasi:

projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies|authorizationPolicies]/[server-tls-policy|client-mtls-policy|authz-policy]

Contoh:

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

Mengamankan traffic keluar ke layanan backend

Untuk mengamankan traffic keluar, pertama-tama Anda membuat kebijakan TLS klien yang melakukan berikut ini:

Menggunakan google_cloud_private_spiffe sebagai plugin untuk clientCertificate, yang memprogram Envoy untuk menggunakan sertifikat mesh terkelola GKE sebagai identitas klien.
Menggunakan google_cloud_private_spiffe sebagai plugin untuk serverValidationCa yang memprogram Envoy untuk menggunakan sertifikat mesh terkelola GKE untuk validasi server.

Selanjutnya, lampirkan kebijakan TLS klien ke layanan backend. Hal ini melakukan berikut ini:

Menerapkan kebijakan autentikasi dari kebijakan TLS klien ke kebijakan keluar koneksi ke endpoint layanan backend.
SAN (Nama Alternatif Subjek) menginstruksikan klien untuk menegaskan identitas server yang tersambung.

Buat kebijakan TLS klien dalam file client-mtls-policy.yaml:

name: "client-mtls-policy"
clientCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
serverValidationCa:
- certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

Impor kebijakan TLS klien:

gcloud network-security client-tls-policies import client-mtls-policy \
    --source=client-mtls-policy.yaml --location=global

Lampirkan kebijakan TLS klien ke layanan backend. Setelan ini memberlakukan mTLS autentikasi pada semua permintaan keluar dari klien ke backend ini layanan.

gcloud compute backend-services export td-gke-service \
    --global --destination=demo-backend-service.yaml

Tambahkan baris berikut ke demo-backend-service.yaml:

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"

Impor nilai:

gcloud compute backend-services import td-gke-service \
    --global --source=demo-backend-service.yaml

Atau, jalankan perintah berikut untuk memeriksa apakah permintaan gagal. Ini adalah kegagalan yang sudah diperkirakan, karena klien mengharapkan sertifikat dari endpoint, tetapi endpoint tidak diprogram dengan kebijakan keamanan.

# 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"

Anda akan melihat output seperti ini:

wget: server returned error: HTTP/1.1 503 Service Unavailable

Mengamankan traffic masuk ke endpoint

Untuk mengamankan lalu lintas masuk, pertama-tama Anda membuat kebijakan TLS server yang melakukan berikut ini:

Menggunakan google_cloud_private_spiffe sebagai plugin untuk serverCertificate, yang memprogram Envoy untuk menggunakan sertifikat mesh terkelola GKE sebagai identitas server.
Menggunakan google_cloud_private_spiffe sebagai plugin untuk clientValidationCa, yang memprogram Envoy untuk menggunakan sertifikat mesh terkelola GKE untuk validasi klien.

Simpan nilai kebijakan TLS server dalam file bernama server-mtls-policy.yaml.

name: "server-mtls-policy"
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe
mtlsPolicy:
  clientValidationCa:
  - certificateProviderInstance:
      pluginInstance: google_cloud_private_spiffe

Buat kebijakan TLS server:

gcloud network-security server-tls-policies import server-mtls-policy \
    --source=server-mtls-policy.yaml --location=global

Buat file bernama ep_mtls.yaml yang berisi pencocok endpoint dan melampirkan kebijakan TLS server.

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

Impor pencocok endpoint.

gcloud network-services endpoint-policies import ep \
    --source=ep_mtls.yaml --location=global

Memvalidasi penyiapan

Jalankan perintah curl berikut. Jika permintaan berhasil diselesaikan, Anda lihat x-forwarded-client-cert dalam output. {i>Header<i} hanya dicetak ketika koneksinya adalah koneksi mTLS.

# 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"

Anda akan melihat output seperti berikut:

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

Perhatikan bahwa header x-forwarded-client-cert disisipkan oleh sisi server Envoy dan berisi identitasnya sendiri (server) serta identitas sumbernya dengan klien besar. Karena kita melihat identitas klien dan server, ini adalah sinyal dari koneksi mTLS.

Mengonfigurasi akses tingkat layanan dengan kebijakan otorisasi

Petunjuk ini membuat kebijakan otorisasi yang mengizinkan permintaan yang dikirim oleh akun DEMO_CLIENT_KSA tempat nama host-nya service-test, port-nya adalah 8000, dan metode HTTP-nya adalah GET. Sebelum Anda membuat kebijakan otorisasi, baca hati-hati di Batasi akses menggunakan otorisasi.

Buat kebijakan otorisasi dengan membuat file bernama authz-policy.yaml.

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

Impor kebijakan:

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

Update kebijakan endpoint untuk merujuk kebijakan otorisasi baru dengan menambahkan kode berikut ke file ep_mtls.yaml:
```
authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
```
Kebijakan endpoint sekarang menentukan bahwa mTLS dan otorisasi kebijakan harus diterapkan terhadap permintaan masuk ke Pod yang file bantuan Envoy proxy menampilkan label app:payments.

Impor kebijakan:

gcloud network-services endpoint-policies import ep \
    --source=ep_mtls.yaml --location=global

Memvalidasi penyiapan

Jalankan perintah berikut untuk memvalidasi penyiapan.

# 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"

Output yang diharapkan mirip dengan ini:

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

Jalankan perintah berikut untuk menguji apakah kebijakan otorisasi menolak permintaan yang tidak valid dengan benar:

# 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"

Output yang diharapkan mirip dengan ini:

<RBAC: access denied HTTP/1.1 403 Forbidden>

Menyiapkan keamanan gateway masuk

Bagian ini mengasumsikan bahwa Anda telah menyelesaikan bagian keamanan {i>service-to-service<i}, termasuk menyiapkan cluster GKE Anda dengan injector otomatis file bantuan, membuat otoritas sertifikat, dan membuat kebijakan endpoint.

Di bagian ini, Anda akan men-deploy proxy Envoy sebagai gateway masuk yang menghentikan koneksi TLS dan mengizinkan permintaan dari klien internal cluster.

Menghentikan TLS pada gateway masuk (klik untuk memperbesar) — Menghentikan TLS di gateway masuk (klik untuk memperbesar)

Untuk menyiapkan gateway masuk guna menghentikan TLS, lakukan hal berikut:

Men-deploy layanan Kubernetes yang dapat dijangkau menggunakan IP internal cluster alamat IPv6
1. Deployment ini terdiri dari proxy Envoy mandiri yang diekspos sebagai layanan Kubernetes dan terhubung ke Cloud Service Mesh.
Buat kebijakan TLS server untuk menghentikan TLS.
Buat kebijakan otorisasi untuk mengizinkan permintaan masuk.

Men-deploy layanan gateway masuk ke GKE

Jalankan perintah berikut untuk men-deploy layanan gateway masuk pada GKE:

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

File gateway_sample.yaml adalah spesifikasi untuk gateway masuk. Hal berikut ini menjelaskan beberapa tambahan pada spesifikasi.

Menonaktifkan injeksi file bantuan Cloud Service Mesh

Spesifikasi gateway_sample.yaml men-deploy proxy Envoy sebagai container satu-satunya. Di beberapa di langkah sebelumnya, Envoy dimasukkan sebagai file bantuan ke container aplikasi. Kepada menghindari beberapa Envoys menangani permintaan, Anda dapat menonaktifkan injeksi file bantuan untuk layanan Kubernetes ini menggunakan pernyataan berikut:

sidecar.istio.io/inject: "false"

Memasang volume yang benar

Spesifikasi gateway_sample.yaml memasang gke-workload-certificates volume. Volume ini juga digunakan dalam deployment file bantuan, tetapi ditambahkan secara otomatis oleh injektor file bantuan saat melihat anotasi cloud.google.com/enableManagedCerts: "true". gke-workload-certificates berisi sertifikat dan kunci SPIFFE yang dikelola GKE yang ditandatangani oleh CA Service yang Anda siapkan.

Menetapkan alamat IP internal cluster

Konfigurasikan gateway masuk dengan layanan jenis ClusterInternal. Ini membuat nama host DNS yang dapat diselesaikan secara internal untuk mesh-gateway. Ketika seorang klien mengirimkan permintaan ke mesh-gateway:443, Kubernetes segera merutekan permintaan ke port deployment Envoy gateway masuk 8080.

Mengaktifkan TLS pada gateway masuk

Gunakan petunjuk ini untuk mengaktifkan TLS pada gateway masuk.

Buat resource kebijakan TLS server untuk menghentikan koneksi TLS, dengan metode nilai dalam file yang bernama server-tls-policy.yaml:

description: tls server policy
name: server-tls-policy
serverCertificate:
  certificateProviderInstance:
    pluginInstance: google_cloud_private_spiffe

Impor kebijakan TLS server:

gcloud network-security server-tls-policies import server-tls-policy \
    --source=server-tls-policy.yaml --location=global

Buat peta URL baru yang merutekan semua permintaan ke backend td-gke-service layanan. Gateway masuk menangani permintaan masuk dan mengirimkannya ke Pod yang termasuk dalam layanan backend td-gke-service.
```
gcloud compute url-maps create td-gke-ig-url-map \
   --default-service=td-gke-service
```

Buat proxy HTTPS target baru dalam file td-gke-https-proxy.yaml dan lampirkan peta URL yang telah dibuat sebelumnya dan kebijakan TLS server. Ini mengonfigurasi gateway masuk proxy Envoy untuk menghentikan lalu lintas TLS yang masuk.

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

Impor kebijakan:

gcloud compute target-https-proxies import td-gke-https-proxy \
   --global --source=td-gke-https-proxy.yaml

Buat aturan penerusan baru dan lampirkan proxy HTTPS target. Ini mengkonfigurasi {i>proxy<i} Envoy untuk mendengarkan di porta 8080 dan menerapkan perutean dan kebijakan keamanan yang ditentukan di td-gke-https-proxy.

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

Anda juga dapat memperbarui kebijakan otorisasi di backend untuk mengizinkan permintaan jika semua kondisi berikut terpenuhi:
- Permintaan dikirim oleh DEMO_CLIENT_KSA. (Deployment gateway masuk menggunakan akun layanan DEMO_CLIENT_KSA.)
- Permintaan dengan host mesh-gateway atau service-test
- Port: 8000
Anda tidak perlu menjalankan perintah ini kecuali Anda mengonfigurasi otorisasi kebijakan untuk backend Anda. Jika tidak ada kebijakan otorisasi pada endpoint atau tidak berisi host atau utama sumber yang cocok dalam otorisasi , permintaan akan diizinkan tanpa langkah ini. Tambahkan nilai-nilai ini ke authz-policy.yaml.
```
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
```

Impor kebijakan:

gcloud network-security authorization-policies import authz-policy \
  --source=authz-policy.yaml \
  --location=global

Memvalidasi deployment gateway masuk

Anda menggunakan penampung baru bernama debug untuk mengirim permintaan ke gateway masuk memvalidasi deployment.

Dalam spesifikasi berikut, anotasi "sidecar.istio.io/inject":"false" menyimpan injektor file bantuan Cloud Service Mesh agar tidak otomatis memasukkan file bantuan {i>proxy<i}. Tidak ada file bantuan untuk membantu penampung debug dalam perutean permintaan. Container harus terhubung ke gateway masuk untuk perutean.

Spesifikasi menyertakan tanda --no-check-certificate, yang mengabaikan server validasi sertifikat. Penampung debug tidak memiliki sertifikat sertifikat validasi otoritas yang diperlukan untuk sertifikat valid yang ditandatangani oleh CA Service yang digunakan oleh gateway masuk untuk menghentikan TLS.

Di lingkungan produksi, sebaiknya unduh CA Service sertifikat validasi, lalu memasang atau menginstalnya di dengan klien Anda. Setelah Anda menginstal sertifikat validasi, hapus Opsi --no-check-certificate dari perintah wget.

Jalankan perintah berikut:

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"

Anda akan melihat output yang mirip dengan ini:

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

Jalankan perintah pengujian negatif berikut:

# 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"

Anda akan melihat output yang mirip dengan berikut ini:

wget: error getting response: Connection reset by peer

Jalankan perintah pengujian negatif berikut:

# 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"

Anda akan melihat output yang mirip dengan berikut ini:

HTTP/1.1 403 Forbidden
wget: server returned error: HTTP/1.1 403 Forbidden

Menyiapkan kebijakan otorisasi untuk gateway masuk

Kebijakan otorisasi yang Anda atur di sini memungkinkan gateway masuk permintaan ke dalam mesh jika semua kondisi berikut terpenuhi:

Host: mesh-gateway
Port: 8080
jalur: *
Metode HTTP GET

Buat kebijakan otorisasi dalam file authz-gateway-policy.yaml:

action: ALLOW
name: authz-gateway-policy
rules:
- destinations:
  - hosts:
    - mesh-gateway
    ports:
    - 8080
    methods:
    - GET

Impor nilai dalam file:

gcloud network-security authorization-policies import authz-gateway-policy \
   --source=authz-gateway-policy.yaml  --location=global

Edit file td-gke-https-proxy.yaml dengan menambahkannya ke dalamnya:

authorizationPolicy: projects/PROJECT_ID/locations/global/authorizationPolicies/authz-gateway-policy

Impor file td-gke-https-proxy.yaml lagi:

gcloud compute target-https-proxies import td-gke-https-proxy \
   --global --source=td-gke-https-proxy.yaml

Memvalidasi deployment

Jalankan perintah berikut untuk memvalidasi deployment Anda.

# 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"

Anda akan melihat output yang mirip dengan berikut ini:

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

Jalankan perintah pengujian negatif berikut:

# 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"

Anda akan melihat output yang mirip dengan berikut ini:

wget: server returned error: HTTP/1.1 403 Forbidden

Menghapus deployment

Anda juga dapat menjalankan perintah ini untuk menghapus deployment yang dibuat menggunakan panduan ini.

Untuk menghapus cluster, jalankan perintah ini:

gcloud container clusters delete CLUSTER_NAME --zone ZONE --quiet

Untuk menghapus resource yang Anda buat, jalankan perintah berikut:

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

Batasan

Keamanan layanan Cloud Service Mesh hanya didukung dengan hanya pada container yang tepercaya. Anda tidak dapat men-deploy keamanan layanan dengan Compute Engine.

Pemecahan masalah

Bagian ini berisi informasi tentang cara memperbaiki masalah yang Anda alami selama pengaturan layanan keamanan.

Kegagalan koneksi

Jika koneksi gagal dengan error upstream connect atau error disconnect/reset before headers, periksa log Envoy, di mana Anda mungkin melihat salah satu pesan log berikut:

gRPC config stream closed: 5, Requested entity was not found

gRPC config stream closed: 2, no credential token is found

Jika Anda melihat error ini di log Envoy, kemungkinan layanan token akun tidak dipasang dengan benar, atau menggunakan audience yang berbeda, atau keduanya.

Untuk informasi selengkapnya, lihat Pesan error di log Envoy menunjukkan konfigurasi masalah.

Pod tidak dibuat

Untuk memecahkan masalah ini, lihat Memecahkan masalah deployment otomatis untuk Pod GKE.

Envoy tidak melakukan autentikasi dengan Cloud Service Mesh

Saat Envoy (envoy-proxy) terhubung ke Cloud Service Mesh untuk mengambil xDS Cloud Build menggunakan Workload Identity Federation untuk GKE dan VM Compute Engine akun layanan default (kecuali jika bootstrap diubah). Jika autentikasi gagal, maka Envoy tidak masuk ke status siap.

Tidak dapat membuat cluster dengan `--workload-identity-certificate-authority flag`

Jika melihat pesan error ini, pastikan Anda menjalankan versi terbaru Google Cloud CLI:

gcloud components update

Pod tetap dalam status tertunda

Jika Pod tetap dalam status tertunda selama proses penyiapan, tingkatkan Resource memori dan CPU untuk Pod dalam spesifikasi deployment Anda.

Tidak dapat membuat cluster dengan tanda `--enable-mesh-certificates`

Pastikan Anda menjalankan gcloud CLI versi terbaru:

gcloud components update

Perhatikan bahwa tanda --enable-mesh-certificates hanya berfungsi dengan gcloud beta.

Pod tidak dapat dimulai

Pod yang menggunakan sertifikat mesh GKE mungkin gagal dimulai jika penyediaan sertifikat gagal. Hal ini dapat terjadi dalam situasi seperti berikut:

WorkloadCertificateConfig atau TrustConfig salah dikonfigurasi atau tidak ada.
CSR tidak disetujui.

Anda dapat memeriksa apakah penyediaan sertifikat gagal dengan memeriksa Pod peristiwa.

Memeriksa status Pod:
```
kubectl get pod -n POD_NAMESPACE POD_NAME
```
Ganti kode berikut:
- POD_NAMESPACE: namespace Pod Anda.
- POD_NAME: nama Pod.

Memeriksa peristiwa terbaru untuk Pod:

kubectl describe pod -n POD_NAMESPACE POD_NAME

Jika penyediaan sertifikat gagal, Anda akan melihat peristiwa dengan Kolom Type=Warning, Reason=FailedMount, From=kubelet, dan Message yang diawali dengan MountVolume.SetUp failed for volume "gke-workload-certificates". Kolom Message berisi informasi pemecahan masalah.

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)

Lihat langkah pemecahan masalah berikut jika penyebab Pod tidak dapat dimulai adalah karena obyek yang salah dikonfigurasi, atau karena CSR yang ditolak.

`WorkloadCertificateConfig` atau `TrustConfig` salah dikonfigurasi

Pastikan Anda membuat WorkloadCertificateConfig dan TrustConfig objek dengan benar. Anda dapat mendiagnosis kesalahan konfigurasi pada objek menggunakan kubectl.

Mengambil status saat ini.

Untuk WorkloadCertificateConfig:

kubectl get WorkloadCertificateConfig default -o yaml

Untuk TrustConfig:

kubectl get TrustConfig default -o yaml

Periksa output status. Objek yang valid akan memiliki kondisi dengan type: Ready dan status: "True".
```
status:
  conditions:
  - lastTransitionTime: "2021-03-04T22:24:11Z"
    message: WorkloadCertificateConfig is ready
    observedGeneration: 1
    reason: ConfigReady
    status: "True"
    type: Ready
```
Untuk objek yang tidak valid, status: "False" akan muncul. reasondan Kolom message berisi detail pemecahan masalah tambahan.

CSR tidak disetujui

Jika ada yang tidak beres selama proses persetujuan CSR, Anda dapat memeriksa kesalahannya detail dalam kondisi type: Approved dan type: Issued CSR.

Buat daftar CSR yang relevan menggunakan kubectl:

kubectl get csr \
  --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'

Pilih CSR yang merupakan Approved dan bukan Issued, atau bukan Approved.
Dapatkan detail untuk CSR yang dipilih menggunakan kubectl:
```
kubectl get csr CSR_NAME -o yaml
```
Ganti CSR_NAME dengan nama CSR yang Anda pilih.

CSR yang valid memiliki kondisi dengan type: Approved dan status: "True", serta sertifikat yang valid di kolom 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

Informasi pemecahan masalah untuk CSR yang tidak valid muncul di message dan reason kolom.

Aplikasi tidak dapat menggunakan kredensial mTLS yang diterbitkan

Pastikan masa berlaku sertifikat belum berakhir:

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

Pastikan jenis kunci yang Anda gunakan didukung oleh aplikasi Anda.

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3

Pastikan CA penerbit menggunakan jenis kunci yang sama dengan kunci sertifikat.
1. Mendapatkan status CA Service (Pratinjau) :
```
gcloud privateca ISSUING_CA_TYPE describe ISSUING_CA_NAME \
  --location ISSUING_CA_LOCATION
```
  Ganti kode berikut:
  - ISSUING_CA_TYPE: jenis CA penerbit, yang harus subordinates atau roots.
  - ISSUING_CA_NAME: nama CA penerbit.
  - ISSUING_CA_LOCATION: region CA penerbit.
2. Memastikan keySpec.algorithm dalam output merupakan algoritma kunci yang sama yang Anda tentukan dalam manifes YAML WorkloadCertificateConfig. Outputnya akan terlihat seperti ini:
```
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
 ...
```

Sertifikat ditolak

Pastikan bahwa aplikasi peer menggunakan paket kepercayaan yang sama untuk memverifikasi sertifikat.

Pastikan masa berlaku sertifikat belum berakhir:

cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"

Pastikan kode klien, jika tidak menggunakan Credentials Reloading API gRPC Go, akan memperbarui kredensial dari sistem file secara berkala.
Pastikan workload Anda berada di domain kepercayaan yang sama dengan CA Anda. Sertifikat mesh GKE mendukung komunikasi antar-beban kerja dalam satu domain kepercayaan.

Menyiapkan keamanan layanan dengan Envoy dan load balancing API (lama)

Persyaratan

Mempersiapkan penyiapan

Mengupdate alat command line gcloud

Menyiapkan variabel

Mengaktifkan API

Membuat atau mengupdate cluster GKE

Men-deploy di lingkungan multi-cluster

Mendaftarkan cluster dengan fleet

Membuat certificate authority untuk menerbitkan sertifikat

Mengonfigurasi Identity and Access Management

Menyiapkan Cloud Service Mesh

Memasang injektor file bantuan Envoy di cluster

Menyiapkan layanan pengujian

Metadata proxy Cloud Service Mesh

Gunakan sertifikat mesh dan kunci yang ditandatangani oleh CA Service

Mengonfigurasi port intersepsi traffic masuk

Mengonfigurasi layanan GKE dengan NEG

Menyimpan nama NEG

Men-deploy aplikasi klien ke GKE

Mengonfigurasi resource Google Cloud Cloud Service Mesh

Menyiapkan keamanan antarlayanan

Mengaktifkan mTLS di mesh

Format untuk referensi kebijakan

Mengamankan traffic keluar ke layanan backend

Mengamankan traffic masuk ke endpoint

Memvalidasi penyiapan

Mengonfigurasi akses tingkat layanan dengan kebijakan otorisasi

Memvalidasi penyiapan

Menyiapkan keamanan gateway masuk

Men-deploy layanan gateway masuk ke GKE

Menonaktifkan injeksi file bantuan Cloud Service Mesh

Memasang volume yang benar

Menetapkan alamat IP internal cluster

Mengaktifkan TLS pada gateway masuk

Memvalidasi deployment gateway masuk

Menyiapkan kebijakan otorisasi untuk gateway masuk

Memvalidasi deployment

Menghapus deployment

Batasan

Pemecahan masalah

Kegagalan koneksi

Pod tidak dibuat

Envoy tidak melakukan autentikasi dengan Cloud Service Mesh

Tidak dapat membuat cluster dengan --workload-identity-certificate-authority flag

Pod tetap dalam status tertunda

Tidak dapat membuat cluster dengan tanda --enable-mesh-certificates

Pod tidak dapat dimulai

WorkloadCertificateConfig atau TrustConfig salah dikonfigurasi

CSR tidak disetujui

Aplikasi tidak dapat menggunakan kredensial mTLS yang diterbitkan

Sertifikat ditolak

Mengupdate alat command line `gcloud`

Tidak dapat membuat cluster dengan `--workload-identity-certificate-authority flag`

Tidak dapat membuat cluster dengan tanda `--enable-mesh-certificates`

`WorkloadCertificateConfig` atau `TrustConfig` salah dikonfigurasi