Menyiapkan keamanan layanan dengan Envoy

Gunakan petunjuk dalam panduan ini untuk mengonfigurasi autentikasi dan otorisasi untuk layanan yang di-deploy dengan proxy Traffic Director dan Envoy. Untuk informasi lengkap tentang keamanan layanan Traffic Director, lihat Keamanan layanan Traffic Director.

Persyaratan

Sebelum mengonfigurasi keamanan layanan untuk Traffic Director dengan Envoy, pastikan penyiapan Anda memenuhi prasyarat berikut:

  • Gunakan Envoy versi 1.16.4 atau yang lebih baru untuk xDS v3 API.

  • Anda dapat memenuhi semua persyaratan untuk men-deploy Traffic Director. Untuk mengetahui informasi lengkap tentang persyaratan ini, lihat Mempersiapkan Traffic Director dengan Envoy.

  • Anda memiliki izin yang memadai untuk membuat atau memperbarui resource mesh layanan Google Cloud dan Traffic Director untuk menggunakan keamanan layanan, seperti yang dijelaskan dalam Menyiapkan Traffic Director dengan Envoy.

Menyiapkan untuk penyiapan

Bagian berikut menjelaskan tugas-tugas yang perlu Anda selesaikan sebelum menyiapkan layanan keamanan Traffic Director. Tugas-tugas tersebut adalah:

  • Mengupdate Google Cloud CLI
  • Menyiapkan variabel
  • Mengaktifkan API yang diperlukan agar Traffic Director dapat bekerja dengan Certificate Authority Service

Mengupdate alat command line gcloud

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

gcloud components update

Menyiapkan variabel

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

  • PROJECT_ID: Ganti ID project Anda.
  • CLUSTER_NAME: Ganti nama cluster yang Anda inginkan ke kami, misalnya, secure-td-cluster.
  • ZONE: Ganti zona tempat cluster Anda berada. cluster Anda berada.
  • GKE_CLUSTER_URL: Ganti https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
  • WORKLOAD_POOL: Ganti PROJECT_ID.svc.id.goog
  • K8S_NAMESPACE: Mengganti default.
  • DEMO_CLIENT_KSA: Mengganti nama akun layanan Kubernetes klien Anda.
  • DEMO_SERVER_KSA: Mengganti nama akun layanan Kubernetes server Anda.

  • PROJNUM: Ganti nomor project project Anda, yang dapat ditentukan dari Konsol Google Cloud atau dengan perintah ini:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

  • SA_GKE: Ganti service-PROJNUM@container-engine-robot.iam.gserviceaccount.com

  • 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 versi cluster GKE 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.iam.gserviceaccount.com

Mengaktifkan API

Gunakan perintah gcloud services enable untuk mengaktifkan semua API yang Anda perlukan untuk menyiapkan keamanan Traffic Director 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 Traffic Director bergantung pada integrasi CA Service dengan GKE. Selain persyaratan penyiapan, cluster GKE harus memenuhi persyaratan berikut:

  • Gunakan versi cluster minimum 1.21.4-gke.1801. Jika memerlukan fitur yang ada di versi yang lebih baru, Anda bisa mendapatkan versi tersebut dari saluran rilis cepat.
  • Cluster GKE harus diaktifkan dan dikonfigurasi dengan sertifikat mesh, seperti yang dijelaskan dalam Membuat certificate authority untuk menerbitkan sertifikat.

  1. Buat cluster baru yang menggunakan Workload Identity. Jika Anda mengupdate 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 Traffic Director 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

    Pembuatan cluster mungkin memerlukan waktu beberapa menit.

  2. Jika Anda menggunakan cluster yang sudah ada, aktifkan Workload Identity dan sertifikat mesh GKE. Pastikan cluster dibuat dengan flag --enable-ip-alias, yang tidak dapat digunakan dengan perintah update.

    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

Men-deploy di lingkungan multi-cluster

Jika Anda melakukan deployment dalam lingkungan multi-cluster, ikuti prosedur umum yang dijelaskan di bagian ini. Petunjuk ini mengasumsikan bahwa Pod klien berjalan di satu cluster dan Pod server berjalan di cluster lainnya.

  1. Buat atau update cluster menggunakan petunjuk di bagian sebelumnya.

  2. Ambil rentang alamat IP Pod untuk setiap cluster menggunakan perintah 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, perintah tersebut akan menampilkan hasil sebagai 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

  3. Buat aturan firewall VPC yang memungkinkan cluster berkomunikasi satu sama lain. Misalnya, perintah berikut membuat aturan firewall yang memungkinkan alamat IP pod cluster-a berkomunikasi dengan 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 memungkinkan alamat IP pod cluster-b 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

Daftarkan cluster yang Anda buat atau update saat Membuat cluster GKE dengan fleet. Mendaftarkan cluster akan memudahkan Anda 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 file tempat perintah ini menghasilkan manifes untuk pendaftaran.

    Saat proses pendaftaran berhasil, Anda akan melihat pesan berikut:

    Finished registering the cluster CLUSTER_NAME with the fleet.

  2. Terapkan file manifes yang dihasilkan ke cluster Anda:

    kubectl apply -f MANIFEST-FILE_NAME

    Saat proses permohonan berhasil, Anda akan melihat pesan berikut:

    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

    Output-nya harus menyertakan kumpulan Workoad Identity yang ditetapkan oleh fleet, dengan PROJECT_ID sebagai project ID Anda:

    workload_identity_pool: PROJECT_ID.svc.id.goog

    Ini berarti cluster berhasil didaftarkan.

Membuat certificate authority untuk menerbitkan sertifikat

Untuk menerbitkan sertifikat ke Pod Anda, buat kumpulan Layanan CA dan certificate authority (CA) berikut:

  • Root CA. Ini adalah root kepercayaan untuk semua sertifikat mesh yang diterbitkan. Anda dapat menggunakan root CA yang sudah ada jika memilikinya. Buat CA root di tingkat enterprise, yang dimaksudkan untuk penerbitan sertifikat bervolume rendah dalam jangka panjang.
  • Subordinate CA. CA ini menerbitkan sertifikat untuk beban kerja. Buat CA subordinat di region tempat cluster Anda di-deploy. Buat CA subordinat di tingkat devops, yang dimaksudkan untuk penerbitan sertifikat bervolume tinggi berjangka pendek.

Pembuatan CA subordinat bersifat opsional, tetapi sebaiknya buat CA alih-alih menggunakan root CA untuk menerbitkan sertifikat mesh GKE. Jika Anda memutuskan untuk menggunakan CA root untuk menerbitkan sertifikat mesh, pastikan mode penerbitan berbasis konfigurasi default tetap diizinkan.

CA subordinat dapat berada di region yang berbeda dengan cluster Anda, tetapi sebaiknya buat di region yang sama dengan cluster Anda untuk mengoptimalkan performa. Namun, Anda dapat membuat CA root dan bawah di berbagai region tanpa memengaruhi performa atau ketersediaan.

Wilayah berikut didukung untuk Layanan CA:

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

  1. Berikan IAM roles/privateca.caManager kepada individu yang membuat kumpulan CA dan CA. Perhatikan bahwa untuk MEMBER, format yang benar adalah user:userid@example.com. Jika orang tersebut adalah pengguna saat ini, Anda dapat memperoleh ID pengguna saat ini dengan perintah shell $(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 Layanan CA kepada individu yang perlu mengubah kebijakan IAM, dengan MEMBER adalah individu yang memerlukan akses ini, khususnya, individu yang melakukan langkah-langkah di bawah ini yang memberikan peran privateca.auditor dan privateca.certificateManager:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=MEMBER \
  --role=roles/privateca.admin

  3. Buat kumpulan root CA Service.

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

  4. Buat 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_Organizational="TestCorpLLC"

  5. Membuat kumpulan subordinat dan CA subordinat. Pastikan mode penerbitan berbasis konfigurasi default 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_Organizational="TestCorpLLC"
    • ROOT_CA_POOL_NAME=td_sec_pool
    • ROOT_CA_POOL_LOCATION=us-east1

  6. Berikan peran privateca.auditor IAM untuk kumpulan CA root guna 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.iam.gserviceaccount.com"

  7. Berikan peran privateca.certificateManager IAM untuk kumpulan CA subordinate guna mengizinkan akses dari akun layanan GKE:

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_NAME \
  --location SUBORDINATE_CA_POOL_LOCATION \
  --role roles/privateca.certificateManager \
  --member="serviceAccount:service-PROJNUM@container-engine-robot.iam.gserviceaccount.com"

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

    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:

    • ID project tempat cluster Anda berjalan: 
      PROJECT_ID
    • URI CA yang sepenuhnya memenuhi syarat yang menerbitkan sertifikat mesh Anda (ISSUING_CA_POOL_URI). Ini dapat berupa CA subordinate (direkomendasikan) atau CA root 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 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:

    • 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 pada cluster Anda:

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

Mengonfigurasi Identity and Access Management

Guna membuat resource yang diperlukan untuk penyiapan, Anda harus memiliki peran compute.NetworkAdmin. Peran ini berisi semua izin yang diperlukan untuk membuat, memperbarui, menghapus, mencantumkan, dan menggunakan (yaitu, mereferensikan ini di resource lain) 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 mereferensikan resource ini di layanan backend.

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

Jika Anda menggunakan peran khusus dan pemeriksaan ini diterapkan di masa mendatang, Anda harus memastikan untuk menyertakan izin .use masing-masing. Jika tidak, di masa mendatang, Anda mungkin akan mendapati bahwa peran khusus Anda tidak memiliki izin yang diperlukan untuk merujuk ke clientTlsPolicy atau serverTlsPolicy dari layanan backend atau kebijakan endpoint.

Dengan petunjuk berikut, akun layanan default dapat mengakses Traffic Director Security API dan membuat akun layanan Kubernetes.

  1. Konfigurasikan IAM untuk mengizinkan akun layanan default mengakses Traffic Director security API.

    GSA_EMAIL=PROJNUM-compute@developer.gserviceaccount.com

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:${GSA_EMAIL} \
  --role roles/trafficdirector.client

  2. Menyiapkan akun layanan Kubernetes. Deployment klien dan server di bagian berikut menggunakan Kname dari server Kubernetes dan akun layanan klien.

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

  3. Izinkan akun layanan Kubernetes meniru identitas akun layanan Compute Engine default dengan membuat binding kebijakan IAM antara keduanya. Dengan binding ini, akun layanan Kubernetes dapat bertindak sebagai akun layanan Compute Engine default.

    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}

  4. Anotasikan akun layanan Kubernetes untuk mengaitkannya dengan akun layanan Compute Engine default.

    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 Traffic Director

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

Instal injektor file bantuan Envoy di cluster

Gunakan petunjuk di kedua bagian berikut dalam penyiapan Traffic Director untuk Pod GKE dengan injeksi Envoy otomatis guna men-deploy dan mengaktifkan injeksi file bantuan Envoy di cluster Anda:

  • Menginstal injektor file bantuan Envoy. Pastikan Anda mengonfigurasi nama mesh sebagai sidecar-mesh dan jaringan sebagai "", string kosong.

  • Mengaktifkan injeksi file bantuan:

    kubectl label namespace K8S_NAMESPACE istio-injection=enabled

Pastikan Anda menyelesaikan kedua set petunjuk sebelum menyiapkan layanan pengujian.

Menyiapkan layanan pengujian

Setelah 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 --namespace K8S_NAMESPACE

File service_sample.yaml berisi podspec untuk aplikasi server demo Anda. Ada beberapa anotasi yang khusus untuk keamanan Traffic Director.

Metadata proxy Traffic Director

Podspec menentukan anotasi proxyMetadata:

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

Saat Pod diinisialisasi, proxy file bantuan mengambil anotasi ini dan mengirimkannya ke Traffic Director. Traffic Director kemudian dapat menggunakan informasi ini untuk mengirim kembali konfigurasi yang difilter:

  • Di bagian selanjutnya dalam panduan ini, perhatikan bahwa kebijakan endpoint menentukan matcher endpoint.
  • Pencocok endpoint menentukan bahwa hanya klien yang memberikan label dengan nama app dan nilai payments yang 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, kunci dan sertifikat yang ditandatangani CA Service akan otomatis dipasang di 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 tempat aplikasi server Anda mendengarkan koneksi. Saat Pod diinisialisasi, proxy file bantuan mengambil anotasi ini dan mengirimkannya ke Traffic Director. Traffic Director kemudian dapat menggunakan informasi ini untuk mengirim kembali konfigurasi yang difilter, yang mencegat semua traffic masuk ke port ini dan dapat menerapkan kebijakan keamanan di dalamnya.

Port health check harus berbeda dari port aplikasi. Jika tidak, kebijakan keamanan yang sama akan berlaku untuk koneksi masuk ke port health check yang dapat menyebabkan koneksi ditolak sehingga menyebabkan server 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 layanan backend Traffic Director. 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.

Simpan nama NEG

Simpan nama NEG dalam 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, yang perlu Anda tunjukkan 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 --namespace K8S_NAMESPACE

Podspec klien hanya menyertakan anotasi enableManagedCerts. Hal ini diperlukan untuk memasang volume yang diperlukan untuk kunci dan sertifikat mesh yang dikelola GKE yang ditandatangani oleh instance CA Service.

Mengonfigurasi health check, aturan firewall, dan resource layanan backend

Di bagian ini, Anda akan membuat health check, aturan firewall, dan resource layanan backend untuk Traffic Director.

  1. Membuat health check.

    gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

  2. Buat aturan firewall untuk mengizinkan rentang alamat IP health checker.

    gcloud compute firewall-rules create fw-allow-health-checks \
   --action ALLOW \
   --direction INGRESS \
   --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --rules tcp

  3. Membuat layanan backend dan mengaitkan health check dengan layanan backend.

    gcloud compute backend-services create td-gke-service \
  --global \
  --health-checks td-gke-health-check \
  --load-balancing-scheme INTERNAL_SELF_MANAGED

  4. Tambahkan NEG yang dibuat sebelumnya sebagai backend ke layanan backend. 

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

Mengonfigurasi resource Mesh dan HTTPRoute

Di bagian ini, Anda akan membuat resource Mesh dan HTTPRoute.

  1. Buat spesifikasi resource Mesh dan simpan dalam file bernama mesh.yaml.

    name: sidecar-mesh
interceptionPort: 15001

    Port intersepsi ditetapkan secara default ke 15001 jika Anda tidak menentukannya dalam file mesh.yaml.

  2. Buat resource Mesh menggunakan spesifikasi mesh.yaml.

    gcloud network-services meshes import sidecar-mesh \
  --source=mesh.yaml \
  --location=global

  3. Buat spesifikasi HTTPRoute dan simpan ke file bernama http_route.yaml.

    Anda dapat menggunakan PROJECT_ID atau PROJECT_NUMBER.

    name: helloworld-http-route
hostnames:
- service-test
meshes:
- projects/PROJNUM/locations/global/meshes/sidecar-mesh
rules:
- action:
   destinations:
   - serviceName: "projects/PROJNUM/locations/global/backendServices/td-gke-service"

  4. Buat resource HTTPRoute menggunakan spesifikasi dalam file http_route.yaml.

    gcloud network-services http-routes import helloworld-http-route \
  --source=http_route.yaml \
  --location=global

Konfigurasi Traffic Director selesai dan Anda kini dapat mengonfigurasi kebijakan autentikasi dan otorisasi.

Menyiapkan keamanan antarlayanan

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

Mengaktifkan mTLS di mesh

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

Format untuk referensi kebijakan

Perhatikan format yang diperlukan berikut untuk merujuk ke kebijakan TLS server, TLS klien, dan 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 hal berikut:

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

Selanjutnya, Anda akan melampirkan kebijakan TLS klien ke layanan backend. Tindakan ini akan melakukan hal berikut:

  • Menerapkan kebijakan autentikasi dari kebijakan TLS klien ke koneksi keluar ke endpoint layanan backend.
  • SAN (Nama Alternatif Subjek) meminta klien untuk menyatakan identitas yang tepat dari server yang dituju.

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

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

  2. Impor kebijakan TLS klien:

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

  3. Lampirkan kebijakan TLS klien ke layanan backend. Tindakan ini akan menerapkan autentikasi mTLS pada semua permintaan keluar dari klien ke layanan backend ini.

    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"

  4. Impor nilai:

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

  5. Secara opsional, 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 -n K8S_NAMESPACE -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 -n K8S_NAMESPACE $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 traffic masuk, pertama-tama Anda harus membuat kebijakan TLS server yang melakukan hal berikut:

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

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

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

  2. Buat kebijakan TLS server:

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

  3. Buat file bernama ep_mtls.yaml yang berisi matcher endpoint dan lampirkan 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

  4. Impor matcher 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 akan melihat x-forwarded-client-cert di output. {i>Header<i} hanya dicetak ketika koneksi adalah koneksi mTLS.

# Get the name of the Podrunning Busybox.
BUSYBOX_POD=$(kubectl get po -n K8S_NAMESPACE -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 -n K8S_NAMESPACE $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 Envoy sisi server dan berisi identitas (server) dan identitas klien sumbernya sendiri. Karena kita melihat identitas klien dan server, ini adalah sinyal koneksi mTLS.

Mengonfigurasi akses tingkat layanan dengan kebijakan otorisasi

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

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

  2. Impor kebijakan:

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

  3. Perbarui 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 kini menentukan bahwa mTLS dan kebijakan otorisasi harus diterapkan pada permintaan masuk ke Pod yang proxy file bantuan Envoy menampilkan label app:payments.

  4. 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 -n K8S_NAMESPACE $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 -n K8S_NAMESPACE $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 antarlayanan, termasuk menyiapkan cluster GKE dengan injektor otomatis file bantuan, membuat certificate authority, 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.

Mengakhiri TLS di gateway masuk (klik untuk memperbesar)
Menghentikan TLS di gateway masuk (klik untuk memperbesar)

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

  1. Men-deploy layanan Kubernetes yang dapat dijangkau menggunakan alamat IP internal cluster.
    1. Deployment tersebut terdiri dari proxy Envoy mandiri yang diekspos sebagai layanan Kubernetes dan terhubung ke Traffic Director.
  2. Buat kebijakan TLS server untuk menghentikan TLS.
  3. Buat kebijakan otorisasi untuk mengizinkan permintaan masuk.

Men-deploy layanan ingress gateway ke GKE

Jalankan perintah berikut untuk men-deploy layanan ingress gateway di 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 --namespace K8S_NAMESPACE

File gateway_sample.yaml adalah spesifikasi untuk gateway masuk. Bagian berikut menjelaskan beberapa penambahan pada spesifikasi.

Menonaktifkan injeksi file bantuan Traffic Director

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

sidecar.istio.io/inject: "false"

Pasang volume yang benar

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

Menetapkan alamat IP internal cluster

Konfigurasikan gateway masuk dengan layanan jenis ClusterInternal. Tindakan ini akan membuat nama host DNS yang dapat diselesaikan secara internal untuk mesh-gateway. Saat klien mengirim permintaan ke mesh-gateway:443, Kubernetes akan segera mengarahkan permintaan tersebut ke port 8080 deployment Envoy gateway masuk.

Mengaktifkan TLS di gateway masuk

Gunakan petunjuk ini untuk mengaktifkan TLS pada gateway masuk.

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

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

  2. Impor kebijakan TLS server:

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

  3. Buat target baru Gateway dan simpan di file td-gke-gateway.yaml. Tindakan ini akan melampirkan kebijakan TLS server dan mengonfigurasi ingress ingress proxy Envoy untuk menghentikan traffic TLS yang masuk.

    name: td-gke-gateway
scope: gateway-proxy
ports:
- 8080
type: OPEN_MESH
serverTLSPolicy: projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy

  4. Impor gateway:

    gcloud network-services gateways import td-gke-gateway \
  --source=td-gke-gateway.yaml \
  --location=global

  5. Buat dan simpan HTTPRoute baru bernama td-gke-route yang mereferensikan gateway dan merutekan semua permintaan ke td-gke-service.

    name: td-gke-route
hostnames:
- mesh-gateway
gateways:
- projects/PROJECT_NUMBER/locations/global/gateways/td-gke-gateway
rules:
- action:
    destinations:
    - serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-gke-service"

  6. Impor HTTPRoute:

    gcloud network-services httproutes import td-gke-route \
  --source=td-gke-route.yaml \
  --location=global

  7. Atau, perbarui kebijakan otorisasi di backend untuk mengizinkan permintaan saat 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 telah mengonfigurasi kebijakan otorisasi untuk backend Anda. Jika tidak ada kebijakan otorisasi pada endpoint atau tidak terdapat kecocokan host atau akun utama sumber dalam kebijakan otorisasi, permintaan akan diizinkan tanpa langkah ini. Tambahkan 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

  8. Impor kebijakan:

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

Memvalidasi deployment gateway masuk

Anda menggunakan container baru yang disebut debug untuk mengirim permintaan ke gateway masuk guna memvalidasi deployment.

Dalam spesifikasi berikut, anotasi "sidecar.istio.io/inject":"false" mencegah injektor sidecar Traffic Director memasukkan proxy file bantuan secara otomatis. Tidak ada file bantuan untuk membantu penampung debug dalam pemilihan rute permintaan. Container harus terhubung ke gateway masuk untuk perutean.

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

Dalam lingkungan produksi, sebaiknya Anda mendownload sertifikat validasi CA Service dan memasang atau menginstalnya pada klien. 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

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 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 Traffic Director hanya didukung dengan GKE. Anda tidak dapat men-deploy keamanan layanan dengan Compute Engine.

Pemecahan masalah

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

Kegagalan koneksi

Jika koneksi gagal dengan error upstream connect atau error disconnect/reset before headers, periksa log Envoy, tempat 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, ada kemungkinan token akun layanan tidak dipasang dengan benar, atau menggunakan audience yang berbeda, atau keduanya.

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

Pod tidak dibuat

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

Envoy tidak mengautentikasi dengan Traffic Director

Saat terhubung ke Traffic Director untuk mengambil konfigurasi xDS, Envoy (envoy-proxy) akan menggunakan Workload Identity (WI) dan akun layanan default VM Compute Engine (kecuali jika bootstrap diubah). Jika autentikasi gagal, Envoy tidak akan masuk ke status siap.

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

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

gcloud components update

###

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

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

Pastikan Anda menjalankan gcloud CLI versi terbaru:

gcloud components update

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

Pod tidak 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 peristiwa Pod.

  1. Periksa status Pod Anda:

    kubectl get pod -n POD_NAMESPACE POD_NAME

    Ganti kode berikut:

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

  2. Periksa peristiwa terbaru untuk Pod Anda:

    kubectl describe pod -n POD_NAMESPACE POD_NAME

  3. Jika penyediaan sertifikat gagal, Anda akan melihat peristiwa dengan Type=Warning, Reason=FailedMount, From=kubelet, dan kolom Message yang dimulai 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-langkah pemecahan masalah berikut jika alasan Pod Anda tidak dimulai adalah karena objek yang salah dikonfigurasi, atau karena CSR ditolak.

WorkloadCertificateConfig atau TrustConfig tidak dikonfigurasi dengan benar

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

  1. Ambil 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 sebagai gantinya. Kolom reason dan message berisi detail pemecahan masalah tambahan.

CSR tidak disetujui

Jika terjadi masalah selama proses persetujuan CSR, Anda dapat memeriksa detail error dalam kondisi type: Approved dan type: Issued CSR.

  1. Tampilkan daftar CSR yang relevan menggunakan kubectl:

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

  2. Pilih CSR yang salah satu dari Approved dan bukan Issued, atau yang 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 akan muncul di kolom message dan reason.

Aplikasi tidak dapat menggunakan kredensial mTLS yang diterbitkan

  1. Verifikasi bahwa 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. Periksa apakah CA penerbit menggunakan kelompok kunci yang sama dengan kunci sertifikat.

    1. Dapatkan status instance Layanan CA (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 berupa subordinates atau roots.
      • ISSUING_CA_NAME: nama CA penerbit.
      • ISSUING_CA_LOCATION: region CA penerbit.

    2. Pastikan keySpec.algorithm dalam output adalah algoritma kunci yang sama dengan 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 aplikasi pembanding menggunakan paket kepercayaan yang sama untuk memverifikasi sertifikat.

  2. Verifikasi bahwa 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, memperbarui kredensial dari sistem file secara berkala.

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