Menyiapkan keamanan layanan dengan gRPC tanpa proxy (lama)

Panduan ini menunjukkan cara mengonfigurasi layanan keamanan untuk aplikasi tanpa proxy Mesh layanan gRPC.

Dokumen ini berlaku untuk Cloud Service Mesh dengan API load balancing saja. Ini adalah dokumen lama.

Persyaratan

Sebelum mengonfigurasi keamanan layanan untuk mesh layanan tanpa proxy gRPC, pastikan bahwa Anda memenuhi persyaratan berikut.

• Deployment Anda memenuhi persyaratan dalam Bersiaplah untuk menyiapkan Cloud Service Mesh dengan gRPC tanpa proxy.
• Anda harus menggunakan xDS v3.
• Anda memiliki akses ke penyedia sertifikat dan versi xDS yang diperlukan dengan salah satu bahasa berikut:
  • Java gRPC
  • C++ gRPC
  • Python gRPC
  • gRPC Go Anda dapat menemukan versi bahasa yang diperlukan di github
• Anda memiliki akses ke generator bootstrap, versi 0.13.0. Bootstrap image generator terletak di repositori container Google Cloud.
• Anda memenuhi semua prasyarat untuk Load balancing mesh layanan tanpa proxy gRPC.
• Anda memiliki izin yang memadai untuk membuat atau memperbarui Cloud Service Mesh dan Resource mesh layanan Google Cloud untuk menggunakan keamanan mesh layanan tanpa proxy (PSM). Untuk penyelesaian informasi tentang izin yang diperlukan, lihat Persiapan untuk menyiapkan Cloud Service Mesh dengan layanan gRPC tanpa proxy.
• Anda memiliki izin yang diperlukan untuk menggunakan Certificate Authority Service, yang yang dijelaskan dalam Membuat certificate authority untuk menerbitkan sertifikat

Mengonfigurasi Identity and Access Management

Anda harus memiliki izin yang diperlukan untuk menggunakan Google Kubernetes Engine. Minimal, Anda harus memiliki peran berikut:

• roles/container.clusterAdmin peran GKE
• roles/compute.instanceAdmin peran Compute Engine
• roles/iam.serviceAccountUser peran

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 hal ini diterapkan pada masa mendatang dan Anda menggunakan compute.NetworkAdmin peran tersebut, maka Anda tidak akan melihat masalah apa pun saat pemeriksaan ini diterapkan.

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.

Mempersiapkan penyiapan

Keamanan {i>Proxyless Service Mesh <i}(PSM) menambahkan keamanan ke mesh layanan yang lakukan penyiapan untuk load balancing per layanan gRPC tanpa proxy dokumentasi tambahan. Dalam mode tanpa proxy klien gRPC menggunakan skema xds: di URI untuk mengakses , yang mengaktifkan fitur load balancing dan penemuan endpoint PSM.

Mengupdate klien dan server gRPC ke versi yang benar

Bangun atau bangun ulang aplikasi Anda menggunakan versi gRPC minimum yang didukung untuk bahasa Anda.

Mengupdate file bootstrap

Aplikasi gRPC menggunakan satu file bootstrap, yang harus memiliki semua yang diwajibkan oleh kode sisi klien dan server gRPC. Bootstrap generator secara otomatis menghasilkan file bootstrap untuk menyertakan flag dan nilai yang dibutuhkan oleh keamanan PSM. Untuk informasi selengkapnya, lihat Bootstrap file, yang mencakup contoh file bootstrap.

Ringkasan penyiapan

Proses penyiapan ini adalah perpanjangan dari Penyiapan Cloud Service Mesh dengan GKE dan layanan gRPC tanpa proxy. Langkah-langkah yang belum diubah prosedur pengaturan itu dirujuk di mana pun berlaku.

Penyempurnaan utama untuk penyiapan Cloud Service Mesh dengan GKE adalah sebagai berikut:

1. Menyiapkan CA Service, tempat Anda membuat kumpulan CA pribadi dan otoritas sertifikat yang diwajibkan.
2. Membuat cluster GKE dengan GKE Workload Identity Federation untuk GKE dan fitur sertifikat mesh serta Layanan CA integrasi.
3. Mengonfigurasi penerbitan sertifikat mesh di cluster.
4. Membuat akun layanan klien dan server.
5. Menyiapkan server contoh yang menggunakan xDS API dan kredensial server xDS untuk memperoleh dari Cloud Service Mesh.
6. Menyiapkan klien contoh yang menggunakan kredensial xDS.
7. Memperbarui konfigurasi Cloud Service Mesh untuk menyertakan konfigurasi keamanan.

Anda dapat melihat contoh kode penggunaan kredensial xDS di lokasi berikut:

• Java telah selesai.
• C++
• Go
• Python

Update Google Cloud CLI

Untuk mengupdate Google Cloud CLI, jalankan perintah berikut:

gcloud components update

Menyiapkan variabel lingkungan

Dalam panduan ini, Anda akan menggunakan perintah Cloud Shell, dan mengulang informasi di perintah diwakili oleh berbagai variabel lingkungan. Tetapkan nilai ke variabel lingkungan berikut di lingkungan shell sebelum Anda menjalankan perintah. Setiap baris komentar mengindikasikan variabel lingkungan terkait.

# Your project ID
PROJECT_ID=YOUR_PROJECT_ID

# GKE cluster name and zone for this example.
CLUSTER_NAME="secure-psm-cluster"
ZONE="us-east1-d"

# 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='default'
DEMO_BACKEND_SERVICE_NAME='grpc-gke-helloworld-service'

# Compute other values
# Project number for your project
PROJNUM=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

# VERSION is the GKE cluster version. Install and use the most recent version
# from the rapid release channel and substitute its version for
# CLUSTER_VERSION, for example:
# VERSION=latest available version
# Note that the minimum required cluster version is 1.21.4-gke.1801.
VERSION="CLUSTER_VERSION"
SA_GKE=service-${PROJNUM}@container-engine-robot.

Mengaktifkan akses ke API yang diperlukan

Bagian ini memberi tahu Anda cara mengaktifkan akses ke API yang diperlukan.

1. Jalankan perintah berikut untuk mengaktifkan Cloud Service Mesh dan API lainnya yang diperlukan untuk keamanan mesh layanan gRPC tanpa proxy.

   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
   

2. Jalankan perintah berikut untuk mengizinkan akun layanan default mengakses API keamanan Cloud Service Mesh.

   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
   

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.

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

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

3. Jalankan perintah berikut untuk beralih ke cluster baru sebagai cluster default untuk perintah kubectl Anda:

   gcloud container clusters get-credentials CLUSTER_NAME \
     --zone ZONE
   

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.

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

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

3. 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:

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

gcloud privateca locations list

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

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

3. Membuat kumpulan root CA Service.

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

4. 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=&quot;TestCorpLLC&quot;

5. 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=&quot;td-ca-pool&quot;
   • SUBORDINATE_CA_POOL_LOCATION=us-east1
   • SUBORDINATE_CA_NAME=&quot;td-ca&quot;
   • SUBORDINATE_CA_ORGANIZATION=&quot;TestCorpLLC&quot;
   • ROOT_CA_POOL_NAME=td_sec_pool
   • ROOT_CA_POOL_LOCATION=us-east1

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

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

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

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

10. Terapkan konfigurasi tersebut ke cluster Anda:

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

Membuat layanan gRPC tanpa proxy dengan NEG

Untuk keamanan PSM, Anda memerlukan server gRPC tanpa proxy yang mampu menggunakan xDS untuk memperoleh konfigurasi keamanan dari Cloud Service Mesh. Langkah ini mirip dengan Mengonfigurasi layanan GKE dengan NEG di penyiapan load balancing PSM panduan, tetapi Anda menggunakan server helloworld yang mendukung xDS di Contoh xDS di grpc-java repositori bukan gambar java-example-hostname.

Anda mem-build dan menjalankan server ini dalam container yang dibuat dari image openjdk:8-jdk. Anda juga dapat menggunakan fitur NEG bernama, yang memungkinkan Anda menentukan nama untuk NEG. Ini menyederhanakan langkah-langkah berikutnya karena deployment Anda mengetahui nama NEG tanpa harus mencarinya.

Berikut adalah contoh lengkap spesifikasi Kubernetes server gRPC. Perhatikan hal berikut:

• Spesifikasi membuat akun layanan Kubernetes example-grpc-server yang yang digunakan oleh Pod server gRPC.
• Spesifikasi menggunakan kolom name dalam anotasi cloud.google.com/neg dari untuk menentukan nama NEG example-grpc-server.
• Variabel ${PROJNUM} mewakili nomor project Anda.
• Spesifikasi menggunakan bagian initContainers untuk menjalankan generator bootstrap mengisi file bootstrap yang diperlukan library gRPC tanpa proxy. Ini File bootstrap berada di /tmp/grpc-xds/td-grpc-bootstrap.json dalam gRPC penampung server bernama example-grpc-server.

Tambahkan anotasi berikut ke spesifikasi Pod Anda:

 annotations:
   security.cloud.google.com/use-workload-certificates: ""

Anda dapat melihat penempatan yang benar dalam spesifikasi lengkap berikut ini.

Saat pembuatan, setiap Pod mendapatkan volume sebesar /var/run/secrets/workload-spiffe-credentials. Volume ini berisi hal berikut:

• private_key.pem adalah kunci pribadi yang dibuat secara otomatis.
• certificates.pem adalah paket sertifikat berformat PEM yang dapat disajikan ke Pod lain sebagai rantai sertifikat klien, atau digunakan sebagai server rantai sertifikat.
• ca_certificates.pem adalah paket sertifikat berformat PEM yang akan digunakan sebagai kepercayaan anchor saat memvalidasi rantai sertifikat klien yang diberikan oleh Pod lain, atau rantai sertifikat server yang diterima saat terhubung ke Pod lain.

Perhatikan bahwa ca_certificates.pem berisi sertifikat untuk domain kepercayaan lokal untuk workload, yang merupakan kumpulan workload cluster.

leaf certificate di certificates.pem berisi teks biasa berikut Pernyataan identitas SPIFFE:

spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT

Dalam pernyataan ini:

• WORKLOAD_POOL adalah nama kumpulan workload cluster.
• NAMESPACE adalah namespace akun layanan Kubernetes Anda.
• KUBERNETES_SERVICE_ACCOUNT adalah nama Kubernetes Anda akun layanan Anda.

Petunjuk untuk bahasa Anda berikut akan membuat spesifikasi yang akan digunakan dalam contoh.

1. Terapkan spesifikasi:

   kubectl apply -f example-grpc-server.yaml
   

2. Berikan peran yang diperlukan ke akun layanan:

   gcloud iam service-accounts add-iam-policy-binding \
     --role roles/iam.workloadIdentityUser \
     --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-server]" \
     ${PROJNUM}-compute@
   
   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
     --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-server]" \
     --role roles/trafficdirector.client
   

3. Jalankan perintah berikut untuk memastikan bahwa layanan dan Pod sudah dibuat dengan benar:

   kubectl get deploy/example-grpc-server
   kubectl get svc/example-grpc-server
   

4. Pastikan bahwa nama NEG sudah benar:

   gcloud compute network-endpoint-groups list \
       --filter "name=example-grpc-server" --format "value(name)"
   

   Perintah sebelumnya diharapkan menampilkan nama NEG example-grpc-server.

Mengonfigurasi Cloud Service Mesh dengan komponen Google Cloud Load Balancing

Langkah-langkah di bagian ini mirip dengan yang ada di Mengonfigurasi Cloud Service Mesh dengan komponen load balancing, tetapi ada beberapa perubahan, seperti yang dijelaskan di bagian berikut.

Membuat health check, aturan firewall, dan layanan backend

Jika server gRPC dikonfigurasi untuk menggunakan mTLS, health check gRPC tidak akan berfungsi karena klien health check tidak dapat memberikan sertifikat klien yang valid ke server. Anda dapat mengatasi masalah ini dengan salah satu dari dua cara berikut.

Pada pendekatan pertama, Anda meminta server membuat port inferensi tambahan yang ditetapkan sebagai port health check. Hal ini dilampirkan dalam layanan health check, sebagai teks polos atau TLS ke porta tersebut.

Server contoh helloworld xDS menggunakan PORT_NUMBER + 1 sebagai port health check teks biasa. Contoh ini menggunakan 50052 sebagai port health check karena 50051 adalah server aplikasi gRPC porta.

Pada pendekatan kedua, Anda mengonfigurasi health check untuk hanya memeriksa TCP konektivitas ke porta penyaluran aplikasi. Perintah ini hanya memeriksa konektivitas, dan itu juga menghasilkan lalu lintas yang tidak perlu ke server ketika ada TLS handshake. Karena alasan ini, kami menyarankan Anda menggunakan pendekatan pertama.

1. Buat health check. Perhatikan bahwa health check tidak dimulai hingga Anda membuat dan memulai server.

   • Jika Anda membuat port penayangan yang ditetapkan untuk health check, yang adalah pendekatan yang kami rekomendasikan, gunakan perintah ini:

     gcloud compute health-checks create grpc grpc-gke-helloworld-hc \
      --enable-logging --port 50052
     

   • Jika Anda membuat health check TCP, yang tidak kami rekomendasikan, gunakan perintah berikut:

     gcloud compute health-checks create tcp grpc-gke-helloworld-hc \
     --use-serving-port
     

2. Membuat firewall. Pastikan nilai --target-tags cocok dengan nilai yang Anda berikan untuk --tags di bagian Membuat atau mengupdate cluster GKE.

   gcloud compute firewall-rules create grpc-gke-allow-health-checks \
     --network default --action allow --direction INGRESS \
     --source-ranges 35.191.0.0/16,130.211.0.0/22 \
     --target-tags allow-health-checks \
     --rules tcp:50051-50052
   

3. Buat layanan backend:

   gcloud compute backend-services create grpc-gke-helloworld-service \
      --global \
      --load-balancing-scheme=INTERNAL_SELF_MANAGED \
      --protocol=GRPC \
      --health-checks grpc-gke-helloworld-hc
   

4. Lampirkan NEG ke layanan backend:

   gcloud compute backend-services add-backend grpc-gke-helloworld-service \
      --global \
      --network-endpoint-group example-grpc-server \
      --network-endpoint-group-zone ${ZONE} \
      --balancing-mode RATE \
      --max-rate-per-endpoint 5
   

Membuat peta aturan pemilihan rute

Hal ini mirip dengan cara membuat peta aturan perutean di Penyiapan Cloud Service Mesh dengan Google Kubernetes Engine dan layanan gRPC tanpa proxy.

1. Buat peta URL:

   gcloud compute url-maps create grpc-gke-url-map \
      --default-service grpc-gke-helloworld-service
   

2. Tambahkan pencocok jalur ke peta URL:

   gcloud compute url-maps add-path-matcher grpc-gke-url-map \
      --default-service grpc-gke-helloworld-service \
      --path-matcher-name grpc-gke-path-matcher \
      --new-hosts helloworld-gke:8000
   

3. Buat proxy gRPC target:

   gcloud compute target-grpc-proxies create grpc-gke-proxy \
      --url-map grpc-gke-url-map --validate-for-proxyless
   

4. Buat aturan penerusan:

   gcloud compute forwarding-rules create grpc-gke-forwarding-rule \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --address=0.0.0.0 \
     --target-grpc-proxy=grpc-gke-proxy \
     --ports 8000 \
     --network default
   

Mengonfigurasi Cloud Service Mesh dengan Keamanan gRPC tanpa proxy

Contoh ini menunjukkan cara mengonfigurasi mTLS di sisi klien dan server.

Format untuk referensi kebijakan

Perhatikan format yang diperlukan berikut untuk merujuk ke TLS server dan TLS klien kebijakan:

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

Contoh:

projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy

Mengonfigurasi mTLS di sisi server

Pertama, Anda membuat kebijakan TLS server. Kebijakan ini meminta sisi server gRPC untuk menggunakan konfigurasi plugin certificateProvicerInstance yang diidentifikasi berdasarkan nama google_cloud_private_spiffe untuk sertifikat identitas, yang merupakan bagian dari serverCertificate. Bagian mtlsPolicy menunjukkan keamanan dan penggunaan mTLS google_cloud_private_spiffe yang sama dengan konfigurasi plugin untuk clientValidationCa, yang merupakan spesifikasi sertifikat root (validasi).

Selanjutnya, Anda akan membuat kebijakan endpoint. Ini menentukan bahwa backend, misalnya Server gRPC, yang menggunakan port 50051 dengan atau tanpa label metadata, menerima kebijakan TLS server terlampir bernama server-mtls-policy. Anda menentukan metadata label menggunakan MATCH_ALL. Anda membuat kebijakan endpoint dengan file sementara ep-mtls-psms.yaml yang berisi nilai untuk resource kebijakan endpoint menggunakan kebijakan yang telah Anda tetapkan.

1. Buat file sementara server-mtls-policy.yaml di direktori saat ini dengan nilai resource kebijakan TLS server:

   name: "projects/${PROJECT_ID}/locations/global/serverTlsPolicies/server-mtls-policy"
   serverCertificate:
     certificateProviderInstance:
       pluginInstance: google_cloud_private_spiffe
   mtlsPolicy:
     clientValidationCa:
     - certificateProviderInstance:
         pluginInstance: google_cloud_private_spiffe
   

2. Buat resource kebijakan TLS server yang disebut server-mtls-policy dengan mengimpor file sementara server-mtls-policy.yaml:

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

3. Membuat kebijakan endpoint dengan membuat file sementara ep-mtls-psms.yaml:

   name: "ep-mtls-psms"
   type: "GRPC_SERVER"
   serverTlsPolicy: "projects/${PROJECT_ID}/locations/global/serverTlsPolicies/server-mtls-policy"
   trafficPortSelector:
     ports:
     - "50051"
   endpointMatcher:
     metadataLabelMatcher:
       metadataLabelMatchCriteria: "MATCH_ALL"
       metadataLabels:
       - labelName: app
         labelValue: helloworld
   

4. Buat resource kebijakan endpoint dengan mengimpor file ep-mtls-psms.yaml:

   gcloud beta network-services endpoint-policies import ep-mtls-psms \
     --source=ep-mtls-psms.yaml --location=global
   

Mengonfigurasi mTLS di sisi klien

Kebijakan keamanan sisi klien terpasang ke layanan backend. Ketika klien mengakses backend (server gRPC) melalui layanan backend, kebijakan keamanan sisi klien dikirim ke klien.

1. Membuat konten resource kebijakan TLS klien dalam file sementara yang bernama client-mtls-policy.yaml dalam direktori saat ini:

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

2. Buat resource kebijakan TLS klien yang disebut client-mtls-policy dengan mengimpor file sementara client-mtls-policy.yaml:

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

3. Buat cuplikan dalam file sementara untuk merujuk kebijakan ini dan tambahkan detail untuk subjectAltNames dalam pesan SecuritySettings seperti dalam contoh berikut. Ganti ${PROJECT_ID} dengan nilai project ID Anda, yaitu nilai variabel lingkungan ${PROJECT_ID} yang dijelaskan sebelumnya. Catatan bahwa example-grpc-server dalam subjectAltNames adalah layanan Kubernetes nama akun yang digunakan untuk Pod server gRPC dalam spesifikasi deployment.

   if [ -z "$PROJECT_ID" ] ; then echo Please make sure PROJECT_ID is set. ; fi
   cat << EOF > client-security-settings.yaml
   securitySettings:
     clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client-mtls-policy
     subjectAltNames:
       - "spiffe://${PROJECT_ID}.svc.id.goog/ns/default/sa/example-grpc-server"
   EOF
   

4. Tambahkan pesan securitySettings ke layanan backend yang sudah Anda dibuat. Langkah-langkah ini akan mengekspor konten layanan backend saat ini, tambahkan pesan securitySetting klien dan mengimpor ulang konten baru untuk diperbarui layanan backend.

   gcloud compute backend-services export grpc-gke-helloworld-service --global \
     --destination=/tmp/grpc-gke-helloworld-service.yaml
   
   cat /tmp/grpc-gke-helloworld-service.yaml client-security-settings.yaml \
     >/tmp/grpc-gke-helloworld-service1.yaml
   
   gcloud compute backend-services import grpc-gke-helloworld-service --global \
     --source=/tmp/grpc-gke-helloworld-service1.yaml -q
   

Memverifikasi konfigurasi

Konfigurasi Cloud Service Mesh sekarang sudah selesai, termasuk keamanan sisi klien. Selanjutnya, Anda akan menyiapkan dan menjalankan beban kerja server dan klien. Langkah ini melengkapi contoh tersebut.

Membuat klien gRPC tanpa proxy

Langkah ini mirip dengan bagian sebelumnya Membuat layanan gRPC tanpa proxy. Anda menggunakan klien helloworld yang mendukung xDS dari contoh xDS dalam repositori grpc-java. Anda membuat dan menjalankan klien dalam sebuah container dibuat dari image openjdk:8-jdk. Spesifikasi Kubernetes klien gRPC melakukan mengikuti.

• Perintah ini membuat akun layanan Kubernetes example-grpc-client yang digunakan oleh Pod klien gRPC.
• ${PROJNUM} mewakili nomor project project Anda dan harus diganti dengan angka yang sebenarnya.

Tambahkan anotasi berikut ke spesifikasi Pod Anda:

  annotations:
    security.cloud.google.com/use-workload-certificates: ""

Saat pembuatan, setiap Pod mendapatkan volume sebesar /var/run/secrets/workload-spiffe-credentials. Volume ini berisi hal berikut:

• private_key.pem adalah kunci pribadi yang dibuat secara otomatis.
• certificates.pem adalah paket sertifikat berformat PEM yang dapat disajikan ke Pod lain sebagai rantai sertifikat klien, atau digunakan sebagai server rantai sertifikat.
• ca_certificates.pem adalah paket sertifikat berformat PEM yang akan digunakan sebagai kepercayaan anchor saat memvalidasi rantai sertifikat klien yang diberikan oleh Pod lain, atau rantai sertifikat server yang diterima saat terhubung ke Pod lain.

Perlu diperhatikan bahwa ca_certificates.pem berisi root certificate untuk lokal domain tepercaya untuk workload ini, yang merupakan kumpulan workload cluster.

leaf certificate di certificates.pem berisi teks biasa berikut Pernyataan identitas SPIFFE:

spiffe://WORKLOAD_POOL/ns/NAMESPACE/sa/KUBERNETES_SERVICE_ACCOUNT

Dalam pernyataan ini:

• WORKLOAD_POOL adalah nama kumpulan workload cluster.
• NAMESPACE adalah nama akun layanan Kubernetes Anda.
• KUBERNETES_SERVICE_ACCOUNT adalah namespace Kubernetes Anda akun layanan Anda.

Petunjuk untuk bahasa Anda berikut akan membuat spesifikasi yang akan digunakan dalam contoh.

Selesaikan proses sebagai berikut.

1. Terapkan spesifikasi:

   kubectl apply -f example-grpc-client.yaml
   

2. Berikan peran yang diperlukan ke akun layanan:

   gcloud iam service-accounts add-iam-policy-binding \
     --role roles/iam.workloadIdentityUser \
     --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-client]" \
     ${PROJNUM}-compute@
   
   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
     --member "serviceAccount:${PROJECT_ID}.svc.id.goog[default/example-grpc-client]" \
     --role roles/trafficdirector.client
   

3. Pastikan Pod klien sedang berjalan:

   kubectl get pods
   

   Perintah tersebut menampilkan teks yang mirip dengan yang berikut ini:

   NAMESPACE   NAME                                    READY   STATUS    RESTARTS   AGE
   default     example-grpc-client-7c969bb997-9fzjv    1/1     Running   0          104s
   [..skip..]
   

Menjalankan server

Membangun dan menjalankan server helloworld yang mendukung xDS di Pod server yang Anda buat sebelumnya.

Proses health check memerlukan waktu 3 hingga 5 menit untuk menunjukkan bahwa layanan Anda responsif setelah server dimulai.

Menjalankan klien dan memverifikasi konfigurasi

Membangun dan menjalankan klien helloworld yang mendukung xDS di Pod klien yang Anda buat sebelumnya.

Mengonfigurasi akses tingkat layanan dengan kebijakan otorisasi

Dukungan gRFC A41 diperlukan untuk dukungan kebijakan otorisasi. Anda dapat menemukan versi bahasa yang diperlukan di github

Gunakan petunjuk ini untuk mengonfigurasi akses tingkat layanan dengan otorisasi kebijakan izin yang relevan. Sebelum membuat kebijakan otorisasi, baca peringatan di Batasi akses menggunakan otorisasi.

Untuk mempermudah verifikasi konfigurasi, buat nama host tambahan yang dapat digunakan klien untuk merujuk ke layanan helloworld-gke.

gcloud compute url-maps add-host-rule grpc-gke-url-map \
   --path-matcher-name grpc-gke-path-matcher \
   --hosts helloworld-gke-noaccess:8000

Petunjuk berikut membuat kebijakan otorisasi yang mengizinkan permintaan yang dikirim oleh akun example-grpc-client tempat nama host berada helloworld-gke:8000 dan port-nya adalah 50051.

Validasi kebijakan otorisasi

Gunakan petunjuk ini untuk mengonfirmasi bahwa kebijakan otorisasi berfungsi dengan benar.

Menggunakan TLS, bukan mTLS

Penggunaan TLS dalam contoh ini hanya memerlukan perubahan kecil.

1. Di ServerTlsPolicy, lepaskan mtlsPolicy:

   cat << EOF > server-tls-policy.yaml
   name: "server-tls-policy"
   serverCertificate:
     certificateProviderInstance:
       pluginInstance: google_cloud_private_spiffe
   EOF
   

2. Gunakan kebijakan ini di EndpointPolicy sebagai gantinya:

   cat << EOF > ep-tls-psms.yaml
   name: "ep-mtls-psms"
   type: "GRPC_SERVER"
   serverTlsPolicy: "projects/${PROJECT_ID}/locations/global/serverTlsPolicies/server-tls-policy"
   trafficPortSelector:
     ports:
     - "50051"
   endpointMatcher:
     metadataLabelMatcher:
       metadataLabelMatchCriteria: "MATCH_ALL"
       metadataLabels: []
   EOF
   

3. ClientTlsPolicy untuk mTLS juga berfungsi di kasus TLS tetapi Bagian clientCertificate dari kebijakan dapat dihapus karena tidak yang diperlukan untuk TLS:

   cat << EOF > client-tls-policy.yaml
   name: "client-tls-policy"
   serverValidationCa:
   - certificateProviderInstance:
       pluginInstance: google_cloud_private_spiffe
   EOF
   

Menggunakan keamanan layanan dengan contoh Wallet

Bagian ini memberikan ringkasan umum tentang cara mengaktifkan contoh Wallet dengan keamanan layanan, untuk Java, C++, dan Go.

File bootstrap

Proses pengaturan dalam panduan ini menggunakan generator bootstrap untuk membuat file bootstrap yang diperlukan. Bagian ini memberikan informasi referensi tentang file {i>bootstrap<i} itu sendiri.

File bootstrap berisi informasi konfigurasi yang diperlukan oleh gRPC tanpa proxy kode, termasuk informasi koneksi untuk server xDS. File bootstrap berisi konfigurasi keamanan yang diperlukan oleh keamanan gRPC tanpa proxy aplikasi baru. Server gRPC memerlukan satu kolom tambahan, seperti yang dijelaskan dalam bagian berikut ini. Contoh file bootstrap terlihat seperti ini:

{
  "xds_servers": [
    {
      "server_uri": "trafficdirector.googleapis.com:443",
      "channel_creds": [
        {
          "type": "google_default"
        }
      ],
      "server_features": [
        "xds_v3"
      ]
    }
  ],
  "node": {
    "cluster": "cluster",
    "id": "projects/9876012345/networks/default/nodes/client1",
    "metadata": {
      "TRAFFICDIRECTOR_GCP_PROJECT_NUMBER": "9876012345",
      "TRAFFICDIRECTOR_NETWORK_NAME": "default",
      "INSTANCE_IP": "10.0.0.3"
    },
    "locality": {
      "zone": "us-central1-a"
    }
  },
  "server_listener_resource_name_template": "grpc/server?xds.resource.listening_address=%s",
  "certificate_providers": {
    "google_cloud_private_spiffe": {
      "plugin_name": "file_watcher",
      "config": {
        "certificate_file": "/var/run/secrets/workload-spiffe-credentials/certificates.pem",
        "private_key_file": "/var/run/secrets/workload-spiffe-credentials/private_key.pem",
        "ca_certificate_file": "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem",
        "refresh_interval": "600s"
      }
    }
  }
}

Update pada file bootstrap untuk layanan keamanan

Kolom berikut menunjukkan perubahan yang terkait dengan keamanan dan penggunaan xDS v3:

Kolom id di dalam node memberikan identitas unik bagi klien gRPC untuk dan Cloud Service Mesh. Anda harus memberikan nomor project Google Cloud dan nama jaringan menggunakan ID node dalam format ini:

projects/{project number}/networks/{network name}/nodes/[UNIQUE_ID]

Contoh untuk nomor project 1234 dan jaringan default adalah:

projects/1234/networks/default/nodes/client1

Kolom INSTANCE_IP adalah alamat IP Pod, atau 0.0.0.0 untuk menunjukkan INADDR_ANY. Kolom ini digunakan oleh server gRPC untuk mengambil Pemroses resource dari Cloud Service Mesh untuk keamanan sisi server.

Kolom konfigurasi keamanan di file bootstrap

Konten struktur JSON config untuk plugin file_watcher adalah:

• certificate_file: String yang diperlukan. Nilai ini adalah lokasi sertifikat identitas.
• private_key_file: String yang diperlukan. Nilainya adalah lokasi file kunci, yang harus sesuai dengan sertifikat identitas.
• ca_certificate_file: String yang diperlukan. Nilainya adalah lokasi {i>root certificate<i}, yang juga dikenal sebagai paket kepercayaan.
• refresh_interval: String opsional. Nilainya menunjukkan interval pembaruan, yang ditentukan menggunakan representasi string dari pemetaan JSON Durasi. Nilai defaultnya adalah "600 dtk", durasi 10 menit.

Generator Bootstrap

Image container generator bootstrap tersedia di gcr.io/trafficdirector-prod/td-grpc-bootstrap:0.16.0. Kode sumbernya adalah tersedia di https://github.com/GoogleCloudPlatform/traffic-director-grpc-bootstrap. Opsi command line yang paling umum digunakan adalah:

• --output: Gunakan opsi ini untuk menentukan lokasi file bootstrap output ditulis, misalnya, perintah --output /tmp/bootstrap/td-grpc-bootstrap.json menghasilkan file bootstrap ke /tmp/bootstrap/td-grpc-bootstrap.json di sistem file Pod.
• --node-metadata: Gunakan flag ini untuk mengisi metadata node di file {i>bootstrap<i}. Ini diperlukan ketika Anda menggunakan pencocok label {i>metadata<i} di EndpointPolicy tempat Cloud Service Mesh menggunakan data label yang disediakan di bagian metadata node dari file bootstrap. Argumennya adalah yang diberikan dalam format key=value, misalnya: --node-metadata version=prod --node-metadata type=grpc

Opsi ini menambahkan hal berikut di bagian metadata node bootstrap file:

{
  "node": {
...
    "metadata": {
      "version": "prod",
      "type": "grpc",
...
    },
...
  },
...
}

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 backend-services delete grpc-gke-helloworld-service --global --quiet
cloud compute network-endpoint-groups delete example-grpc-server --zone ZONE --quiet
gcloud compute firewall-rules delete grpc-gke-allow-health-checks --quiet
gcloud compute health-checks delete grpc-gke-helloworld-hc --quiet
gcloud network-services endpoint-policies delete ep-mtls-psms \
    --location=global --quiet
gcloud network-security authorization-policies delete helloworld-gke-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

Pemecahan masalah

Gunakan petunjuk ini untuk membantu Anda menyelesaikan masalah terkait keamanan deployment.

Workload tidak bisa mendapatkan konfigurasi dari Cloud Service Mesh

Jika Anda melihat error yang mirip dengan ini:

PERMISSION_DENIED: Request had insufficient authentication scopes.

Pastikan hal berikut:

• Anda membuat cluster GKE dengan argumen --scopes=cloud-platform argumen.
• Anda menetapkan roles/trafficdirector.client ke layanan Kuberneters Anda menggunakan akun layanan.
• Anda menetapkan roles/trafficdirector.client ke layanan Google Cloud default (${GSA_EMAIL} di atas).
• Anda telah mengaktifkan layanan trafficdirector.googleapis.com (API).

Server gRPC Anda tidak menggunakan TLS atau mTLS meskipun dengan konfigurasi Cloud Service Mesh yang benar

Pastikan Anda menentukan GRPC_SERVER dalam konfigurasi kebijakan endpoint Anda. Jika yang Anda tentukan SIDECAR_PROXY gRPC mengabaikan konfigurasi.

Anda tidak dapat membuat cluster GKE dengan versi cluster yang diminta

Perintah pembuatan cluster GKE mungkin gagal disertai error sesuatu seperti ini:

Node version "1.20.5-gke.2000" is unsupported.

Pastikan Anda menggunakan argumen --release-channel rapid dalam perintah pembuatan cluster. Anda harus menggunakan saluran rilis cepat untuk mendapatkan versi yang benar untuk rilis ini.

Anda melihat error No usable endpoint

Jika klien tidak dapat berkomunikasi dengan server karena No usable endpoint error, health checker mungkin telah menandai backend server sebagai tidak responsif. Untuk memeriksa kondisi backend, jalankan perintah gcloud ini:

gcloud compute backend-services get-health grpc-gke-helloworld-service --global

Jika perintah menampilkan status backend tidak responsif, itu mungkin karena salah satu alasan berikut:

• Firewall tidak dibuat atau tidak berisi rentang IP sumber yang benar.
• Tag target di firewall Anda tidak cocok dengan tag di cluster yang dibuat.

Workload tidak dapat berkomunikasi di penyiapan keamanan

Jika workload tidak dapat berkomunikasi setelah Anda menyiapkan keamanan mesh layanan tanpa proxy, ikuti petunjuk berikut untuk menentukan penyebabnya.

1. Nonaktifkan keamanan tanpa proxy dan hilangkan masalah di layanan tanpa proxy kasus penggunaan load balancing mesh. Untuk menonaktifkan keamanan di {i>mesh<i}, lakukan salah satu berikut ini:
   1. Gunakan kredensial teks biasa pada sisi klien dan server ATAU
   2. jangan konfigurasikan keamanan untuk layanan backend dan kebijakan endpoint di untuk konfigurasi Cloud Service Mesh.

Ikuti langkah-langkah di Memecahkan masalah deployment Cloud Service Mesh tanpa proxy, karena tidak ada penyiapan keamanan dalam deployment Anda.

1. Mengubah workload Anda untuk menggunakan kredensial xDS dengan teks biasa atau tidak aman seperti kredensial penggantian. Menjaga Mesh Layanan Cloud dengan keamanan dinonaktifkan seperti yang telah dibahas sebelumnya. Dalam kasus ini, meskipun gRPC mengizinkan Cloud Service Mesh untuk mengonfigurasi keamanan, Cloud Service Mesh tidak mengirim informasi keamanan, sehingga gRPC harus kembali ke kredensial teks polos (atau tidak aman) yang seharusnya berfungsi mirip dengan kasus pertama yang telah dijelaskan sebelumnya. Jika kasus ini tidak berhasil, lakukan hal berikut:

   1. Tingkatkan tingkat {i>logging<i} di sisi klien dan server sehingga Anda dapat melihat pesan xDS yang dipertukarkan antara gRPC dan Cloud Service Mesh.
   2. Memastikan Cloud Service Mesh tidak mengaktifkan keamanan di CDS dan respons LDS yang dikirim ke workload.
   3. Memastikan beban kerja tidak menggunakan mode TLS atau mTLS di saluran TV Anda. Jika Anda melihat pesan log yang terkait dengan handshake TLS, periksa kode sumber aplikasi Anda dan pastikan bahwa Anda menggunakan sumber daya yang tidak aman atau teks biasa sebagai kredensial penggantian Anda. Jika kode sumber aplikasi benar, ini mungkin bug di library gRPC

2. Memastikan integrasi CA Service dengan GKE berfungsi untuk cluster GKE Anda dengan mengikuti langkah-langkah pemecahan masalah terkait Panduan Pengguna. Pastikan bahwa sertifikat dan kunci yang disediakan oleh fitur tersebut tersedia di direktori yang ditentukan, /var/run/secrets/workload-spiffe-credentials/.

3. Aktifkan TLS (bukan mTLS) di mesh Anda, seperti yang dijelaskan sebelumnya, lalu mulai ulang workload klien dan server Anda.

   1. Tingkatkan tingkat {i>logging<i} di sisi klien dan server agar dapat untuk melihat pesan xDS yang dipertukarkan antara gRPC dan Cloud Service Mesh.
   2. Pastikan Cloud Service Mesh telah mengaktifkan keamanan di CDS dan LDS yang dikirim ke workload.

Klien gagal dengan CertificateException dan pesan Peer certificate SAN check failed

Hal ini menunjukkan masalah dengan nilai subjectAltNames dalam metode SecuritySettings pesan. Perlu diperhatikan bahwa nilai ini didasarkan pada Kubernetes layanan yang dibuat untuk layanan backend Anda. Untuk setiap layanan Kubernetes tersebut yang dibuat, ada ID SPIFFE terkait, dalam format ini:

spiffe://${WORKLOAD_POOL}/ns/${K8S_NAMESPACE}/sa/${SERVICE_ACCOUNT}

Nilai tersebut adalah:

• WORKLOAD_POOL: Kumpulan workload untuk cluster, yaitu ${PROJECT_ID}.svc.id.goog
• K8S_NAMESPACE: Namespace Kubernetes yang Anda gunakan dalam deployment layanan
• SERVICE_ACCOUNT: Akun layanan Kubernetes yang Anda gunakan dalam deployment layanan

Untuk setiap layanan Kubernetes yang Anda pasang ke layanan backend sebagai jaringan grup endpoint, pastikan Anda menghitung ID SPIFFE dengan benar dan menambahkan ID SPIFFE tersebut ke kolom subjectAltNames di pesan SecuritySettings.

Aplikasi tidak dapat menggunakan sertifikat mTLS dengan library gRPC Anda

Jika aplikasi Anda tidak dapat menggunakan sertifikat mTLS dengan gRPC library, lakukan langkah berikut:

1. Memastikan spesifikasi Pod berisi security.cloud.google.com/use-workload-certificates anotasi yang dijelaskan dalam Membuat layanan gRPC tanpa proxy dengan NEG.

2. Pastikan file yang berisi rantai sertifikat bersama dengan daun sertifikat, kunci pribadi, dan sertifikat CA yang terpercaya dapat diakses di jalur berikut dari dalam Pod:

   1. Rantai sertifikat beserta sertifikat entitas akhir: &quot;/var/run/secrets/workload-spiffe-credentials/certificates.pem&quot;
   2. Kunci pribadi: "/var/run/secrets/workload-spiffe-credentials/private_key.pem"
   3. Paket CA: "/var/run/secrets/workload-spiffe-credentials/ca_certificates.pem"

3. Jika sertifikat pada langkah sebelumnya tidak tersedia, lakukan hal berikut:

     gcloud privateca subordinates describe SUBORDINATE_CA_POOL_NAME 
   
       --location=LOCATION
     

   1. Memastikan bidang kontrol GKE memiliki binding peran IAM yang benar, yang memberinya akses ke CA Service:

      # Get the IAM policy for the CA
      gcloud privateca roots get-iam-policy ROOT_CA_POOL_NAME
      
      # Verify that there is an IAM binding granting access in the following format
      - members:
      - serviceAccount:service-projnumber@container-engine-robot.
      role: roles/privateca.certificateManager
      
      # Where projnumber is the project number (e.g. 2915810291) for the GKE cluster.
      

   2. Pastikan masa berlaku sertifikat belum berakhir. Ini adalah rantai sertifikat dan leaf certificate di /var/run/secrets/workload-spiffe-credentials/certificates.pem. Untuk memeriksa, jalankan perintah ini:

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

   3. Pastikan bahwa jenis kunci didukung oleh aplikasi Anda dengan menjalankan perintah berikut:

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

   4. Pastikan aplikasi Java gRPC Anda memiliki keyAlgorithm berikut dalam file YAML WorkloadCertificateConfig:

     keyAlgorithm:
       rsa:
         modulusSize: 4096
   

4. Pastikan bahwa CA menggunakan kelompok kunci yang sama dengan kunci sertifikat.

Sertifikat aplikasi ditolak oleh klien, server, atau pembanding

1. Verifikasi bahwa aplikasi peer menggunakan paket kepercayaan yang sama untuk memverifikasi CA {i>root<i}.
2. Verifikasi bahwa sertifikat yang digunakan tidak kedaluwarsa (rantai sertifikat bersama dengan sertifikat leaf: "/var/run/secrets/workload-spiffe-credentials/certificates.pem").

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.

1. Memeriksa status Pod:

   kubectl get pod -n POD_NAMESPACE POD_NAME
   

   Ganti kode berikut:

   • POD_NAMESPACE: namespace Pod Anda.
   • POD_NAME: nama Pod.

2. Memeriksa peristiwa terbaru untuk Pod:

   kubectl describe pod -n POD_NAMESPACE POD_NAME
   

3. 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)
   

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

1. Mengambil status saat ini.

   Untuk WorkloadCertificateConfig:

   kubectl get WorkloadCertificateConfig default -o yaml
   

   Untuk TrustConfig:

   kubectl get TrustConfig default -o yaml
   

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

1. Buat daftar CSR yang relevan menggunakan kubectl:

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

2. Pilih CSR yang merupakan Approved dan bukan Issued, atau bukan Approved.

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

Pod tidak memiliki sertifikat

1. Dapatkan spesifikasi Pod untuk Pod Anda:

   kubectl get pod -n POD_NAMESPACE POD_NAME -o yaml
   

   Ganti kode berikut:

   • POD_NAMESPACE: namespace Pod Anda.
   • POD_NAME: nama Pod.

2. Memastikan spesifikasi Pod berisi security.cloud.google.com/use-workload-certificates yang dijelaskan dalam Mengonfigurasi Pod untuk menerima kredensial mTLS.

3. Memastikan pengontrol penerimaan sertifikat mesh GKE berhasil memasukkan volume driver CSI jenis workloadcertificates.security.cloud.google.com ke dalam spesifikasi Pod:

   volumes:
   ...
   -csi:
     driver: workloadcertificates.security.cloud.google.com
     name: gke-workload-certificates
   ...
   

4. Periksa keberadaan pemasangan volume di setiap container:

   containers:
   - name: ...
     ...
     volumeMounts:
     - mountPath: /var/run/secrets/workload-spiffe-credentials
       name: gke-workload-certificates
       readOnly: true
     ...
   

5. Pastikan bahwa paket sertifikat dan kunci pribadi berikut yang tersedia di lokasi berikut dalam Pod:

   • Paket rantai sertifikat: /var/run/secrets/workload-spiffe-credentials/certificates.pem
   • Kunci pribadi: /var/run/secrets/workload-spiffe-credentials/private_key.pem
   • Paket trust anchor CA: /var/run/secrets/workload-spiffe-credentials/ca_certificates.pem

6. Jika file tidak tersedia, lakukan langkah-langkah berikut:

   1. Mengambil CA Service (Pratinjau) untuk cluster tersebut:

      kubectl get workloadcertificateconfigs default -o jsonpath '{.spec.certificateAuthorityConfig.certificateAuthorityServiceConfig.endpointURI}'
      

   2. Mengambil 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.

   3. Dapatkan kebijakan IAM untuk root CA:

      gcloud privateca roots get-iam-policy ROOT_CA_NAME
      

      Ganti ROOT_CA_NAME dengan nama CA root Anda.

   4. Di kebijakan IAM, pastikan privateca.auditor ada pengikatan kebijakan:

      ...
      - members:
        - serviceAccount:service-PROJECT_NUMBER@container-engine-robot.
        role: roles/privateca.auditor
      ...
      

      Dalam contoh ini, PROJECT_NUMBER adalah nomor project cluster Anda.

   5. Dapatkan kebijakan IAM untuk CA subordinate:

      gcloud privateca subordinates get-iam-policy SUBORDINATE_CA_NAME
      

      Ganti SUBORDINATE_CA_NAME dengan nama CA subordinat.

   6. Dalam kebijakan IAM, pastikan binding kebijakan privateca.certificateManager ada:

      ...
      - members:
        - serviceAccount: service-PROJECT_NUMBER@container-engine-robot.
        role: roles/privateca.certificateManager
      ...
      

      Dalam contoh ini, PROJECT_NUMBER adalah nomor project cluster Anda.

Aplikasi tidak dapat menggunakan kredensial mTLS yang diterbitkan

1. Pastikan masa berlaku sertifikat belum berakhir:

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

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

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

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

2. Pastikan masa berlaku sertifikat belum berakhir:

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

3. Pastikan kode klien, jika tidak menggunakan Credentials Reloading API gRPC Go, akan memperbarui kredensial dari sistem file secara berkala.

4. Pastikan workload Anda berada di domain kepercayaan yang sama dengan CA Anda. Sertifikat mesh GKE mendukung komunikasi antar-beban kerja dalam satu domain kepercayaan.

Batasan

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

Cloud Service Mesh tidak mendukung skenario yang memiliki dua endpoint atau lebih resource kebijakan yang sama persis dengan endpoint, misalnya, dua kebijakan dengan label dan port yang sama, atau dua atau lebih kebijakan dengan label yang sama persis dengan label endpoint. Untuk informasi selengkapnya tentang cara kebijakan endpoint dicocokkan dengan label endpoint, lihat API untuk EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. Dalam situasi tersebut, Cloud Service Mesh tidak menghasilkan konfigurasi keamanan dari salah satu kebijakan yang berkonflik.