Menyiapkan keamanan layanan dengan Envoy
Gunakan petunjuk dalam panduan ini untuk mengonfigurasi autentikasi dan otorisasi untuk layanan yang di-deploy dengan Cloud Service Mesh dan proxy Envoy. Untuk mengetahui informasi lengkap tentang keamanan layanan Cloud Service Mesh, lihat Keamanan layanan Cloud Service Mesh.
Persyaratan
Sebelum mengonfigurasi keamanan layanan untuk Cloud Service Mesh dengan Envoy, pastikan penyiapan Anda memenuhi prasyarat berikut:
Anda dapat memenuhi semua persyaratan untuk men-deploy Cloud Service Mesh. Untuk mengetahui informasi lengkap tentang persyaratan ini, lihat Bersiap untuk melakukan penyiapan di API perutean layanan dengan Envoy dan beban kerja tanpa proxy.
Anda memiliki izin yang memadai untuk membuat atau mengupdate Cloud Service Mesh dan resource mesh layananGoogle Cloud untuk menggunakan keamanan layanan, seperti yang dijelaskan dalam Bersiap untuk menyiapkan API perutean layanan dengan Envoy dan beban kerja tanpa proxy.
Bersiap untuk penyiapan
Bagian berikut menjelaskan tugas yang perlu Anda selesaikan sebelum menyiapkan layanan keamanan Cloud Service Mesh. Tugas tersebut adalah:
- Mengupdate Google Cloud CLI
- Menyiapkan variabel
- Mengaktifkan API yang diperlukan agar Cloud Service Mesh dapat berfungsi 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 agar Anda dapat menyalin dan menempelkan kode dengan nilai yang konsisten saat mempelajari contoh dalam dokumen ini. Gunakan nilai berikut.
- PROJECT_ID: Ganti dengan ID project Anda.
- CLUSTER_NAME: Ganti nama cluster yang ingin Anda
gunakan, misalnya,
secure-td-cluster
. - ZONE: Ganti zona tempat cluster Anda berada. cluster Anda berada.
- GKE_CLUSTER_URL: Mengganti
https://container.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/clusters/CLUSTER_NAME
- WORKLOAD_POOL: Mengganti
PROJECT_ID.svc.id.goog
- K8S_NAMESPACE: Ganti
default
. - DEMO_CLIENT_KSA: Ganti nama akun layanan Kubernetes klien Anda.
- DEMO_SERVER_KSA: Ganti nama akun layanan Kubernetes server Anda.
PROJNUM: Ganti nomor project Anda, yang dapat Anda tentukan dari konsol Google Cloud atau dengan perintah ini:
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
SA_GKE: Mengganti
service-PROJNUM@container-engine-robot.
CLUSTER_VERSION: Mengganti versi terbaru yang tersedia. Anda dapat menemukannya di catatan rilis saluran Cepat. Versi minimum yang diperlukan adalah 1.21.4-gke.1801. Ini adalah 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.
Mengaktifkan API
Gunakan perintah gcloud services enable
untuk mengaktifkan semua API yang Anda perlukan untuk menyiapkan keamanan Cloud Service Mesh dengan Layanan Otoritas Sertifikat.
gcloud services enable \ container.googleapis.com \ cloudresourcemanager.googleapis.com \ compute.googleapis.com \ trafficdirector.googleapis.com \ networkservices.googleapis.com \ networksecurity.googleapis.com \ privateca.googleapis.com \ gkehub.googleapis.com
Membuat atau mengupdate cluster GKE
Keamanan layanan Cloud Service Mesh bergantung pada integrasi CA Service dengan GKE. Cluster GKE harus memenuhi persyaratan berikut selain persyaratan untuk penyiapan:
- Gunakan versi cluster minimum 1.21.4-gke.1801. Jika Anda memerlukan fitur yang ada di versi yang lebih baru, Anda dapat memperoleh 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.
Buat cluster baru yang menggunakan Workload Identity Federation for GKE. Jika Anda mengupdate cluster yang ada, lanjutkan ke langkah berikutnya. Nilai yang Anda berikan untuk
--tags
harus cocok dengan nama yang diteruskan ke tanda--target-tags
untuk perintahfirewall-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
Pembuatan cluster mungkin memerlukan waktu beberapa menit.
Jika Anda menggunakan cluster yang ada, aktifkan Workload Identity Federation untuk GKE dan sertifikat mesh GKE. Pastikan cluster dibuat dengan flag
--enable-ip-alias
, yang tidak dapat digunakan dengan perintahupdate
.gcloud container clusters update CLUSTER_NAME \ --enable-mesh-certificates
Jalankan perintah berikut untuk beralih ke cluster baru sebagai cluster default untuk perintah
kubectl
Anda:gcloud container clusters get-credentials CLUSTER_NAME \ --zone ZONE
Men-deploy di lingkungan multi-cluster
Jika Anda men-deploy di lingkungan multi-cluster, ikuti prosedur umum yang dijelaskan di bagian ini. Petunjuk ini mengasumsikan bahwa Pod klien berjalan di satu cluster dan Pod server berjalan di cluster lainnya.
Buat atau perbarui cluster menggunakan petunjuk di bagian sebelumnya.
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
dancluster-b
, perintah akan menampilkan hasil seperti berikut:cluster-a, pod CIDR: 10.4.0.0/14, node network tag: gke-cluster-a-9cd18751-node cluster-b, pod CIDR: 10.8.0.0/14, node network tag: gke-cluster-b-acd14479-node
Buat aturan firewall VPC yang memungkinkan cluster berkomunikasi satu sama lain. Misalnya, perintah berikut membuat aturan firewall yang mengizinkan alamat IP pod
cluster-a
berkomunikasi dengan nodecluster-b
: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 nodecluster-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 ke fleet
Daftarkan cluster yang Anda buat atau update di Membuat cluster GKE dengan fleet. Mendaftarkan cluster akan mempermudah Anda mengonfigurasi cluster di beberapa project.
Perhatikan bahwa setiap langkah ini dapat memerlukan waktu hingga sepuluh menit untuk diselesaikan.
Daftarkan cluster Anda ke fleet:
gcloud container fleet memberships register CLUSTER_NAME \ --gke-cluster=ZONE/CLUSTER_NAME \ --enable-workload-identity --install-connect-agent \ --manifest-output-file=MANIFEST-FILE_NAME
Ganti variabel sebagai berikut:
- CLUSTER_NAME: Nama cluster Anda.
- ZONE: Zona cluster Anda.
- MANIFEST-FILE_NAME: Jalur tempat perintah ini membuat manifes untuk pendaftaran.
Jika proses pendaftaran berhasil, Anda akan melihat pesan seperti berikut:
Finished registering the cluster CLUSTER_NAME with the fleet.
Terapkan file manifes yang dihasilkan ke cluster Anda:
kubectl apply -f MANIFEST-FILE_NAME
Jika proses permohonan berhasil, Anda akan melihat pesan seperti 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
Dapatkan resource keanggotaan dari cluster:
kubectl get memberships membership -o yaml
Output harus menyertakan Workload Identity Pool yang ditetapkan oleh armada, dengan PROJECT_ID adalah 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 CA Service dan certificate authority (CA) berikut:
- Root CA. Ini adalah root kepercayaan untuk semua sertifikat mesh yang diterbitkan. Anda
dapat menggunakan CA root yang ada jika Anda memilikinya. Buat CA root di tingkat
enterprise
, yang ditujukan untuk penerbitan sertifikat berumur panjang dan bervolume rendah. - CA subordinat. CA ini menerbitkan sertifikat untuk workload. Buat CA
bawahan di region tempat cluster Anda di-deploy. Buat CA subordinat di tingkat
devops
, yang ditujukan untuk penerbitan sertifikat bervolume tinggi dan berumur pendek.
Membuat CA subordinat bersifat opsional, tetapi sebaiknya Anda membuat CA subordinat daripada menggunakan CA root 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 kami sangat merekomendasikan untuk membuatnya di region yang sama dengan cluster Anda guna mengoptimalkan performa. Namun, Anda dapat membuat CA root dan CA subordinat di region yang berbeda tanpa memengaruhi performa atau ketersediaan.
Region ini 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 |
Carolina Selatan |
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
Berikan IAM
roles/privateca.caManager
kepada individu yang membuat kumpulan CA dan CA. Perhatikan bahwa untuk MEMBER, format yang benar adalahuser: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
Berikan peran
role/privateca.admin
untuk Layanan CA kepada individu yang perlu mengubah kebijakan IAM, denganMEMBER
adalah individu yang memerlukan akses ini, khususnya, individu yang melakukan langkah-langkah berikut yang memberikan peranprivateca.auditor
danprivateca.certificateManager
:gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/privateca.admin
Buat kumpulan Layanan CA root.
gcloud privateca pools create ROOT_CA_POOL_NAME \ --location ROOT_CA_POOL_LOCATION \ --tier enterprise
Buat CA root.
gcloud privateca roots create ROOT_CA_NAME --pool ROOT_CA_POOL_NAME \ --subject "CN=ROOT_CA_NAME, O=ROOT_CA_ORGANIZATION" \ --key-algorithm="ec-p256-sha256" \ --max-chain-length=1 \ --location ROOT_CA_POOL_LOCATION
Untuk penyiapan demonstrasi ini, gunakan nilai berikut untuk variabel:
- ROOT_CA_POOL_NAME=td_sec_pool
- ROOT_CA_NAME=pkcs2-ca
- ROOT_CA_POOL_LOCATION=us-east1
- ROOT_CA_ORGANIZATION="TestCorpLLC"
Buat 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_ORGANIZATION="TestCorpLLC"
- ROOT_CA_POOL_NAME=td_sec_pool
- ROOT_CA_POOL_LOCATION=us-east1
Berikan peran IAM
privateca.auditor
untuk kumpulan CA root agar memungkinkan 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."
Berikan peran IAM
privateca.certificateManager
untuk kumpulan CA subordinat 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."
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:
- Project ID project tempat cluster Anda berjalan:
PROJECT_ID
- URI yang sepenuhnya memenuhi syarat dari CA yang menerbitkan sertifikat mesh Anda (ISSUING_CA_POOL_URI).
Ini bisa berupa CA bawahan (direkomendasikan) atau CA root Anda. Formatnya adalah:
//privateca.googleapis.com/projects/PROJECT_ID/locations/SUBORDINATE_CA_POOL_LOCATION/caPools/SUBORDINATE_CA_POOL_NAME
- Project ID project tempat cluster Anda berjalan:
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:
- Project ID project tempat cluster Anda berjalan:
PROJECT_ID
- URI yang sepenuhnya memenuhi syarat dari kumpulan CA root (ROOT_CA_POOL_URI).
Formatnya adalah:
//privateca.googleapis.com/projects/PROJECT_ID/locations/ROOT_CA_POOL_LOCATION/caPools/ROOT_CA_POOL_NAME
- Project ID project tempat cluster Anda berjalan:
Terapkan konfigurasi ke cluster Anda:
kubectl apply -f WorkloadCertificateConfig.yaml kubectl apply -f TrustConfig.yaml
Mengonfigurasi Identity and Access Management
Untuk membuat resource yang diperlukan untuk penyiapan, Anda harus memiliki peran
compute.NetworkAdmin
. Peran ini berisi semua izin yang diperlukan untuk
membuat, memperbarui, menghapus, mencantumkan, dan menggunakan (yaitu, mereferensikan ini di resource lain) resource yang diperlukan. Jika Anda adalah editor-pemilik project,
Anda 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 pada 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 pada masa mendatang, Anda harus
memastikan untuk menyertakan izin .use
yang sesuai. Jika tidak, pada masa mendatang,
Anda mungkin mendapati bahwa peran kustom Anda tidak memiliki izin yang diperlukan
untuk merujuk ke clientTlsPolicy
atau serverTlsPolicy
dari layanan backend atau
kebijakan endpoint.
Petunjuk berikut memungkinkan akun layanan default mengakses Cloud Service Mesh Security API dan membuat akun layanan Kubernetes.
Konfigurasi IAM untuk mengizinkan akun layanan default mengakses Cloud Service Mesh Security API.
GSA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \ --filter='displayName:Compute Engine default service account') gcloud projects add-iam-policy-binding PROJECT_ID \ --member serviceAccount:${GSA_EMAIL} \ --role roles/trafficdirector.client
Siapkan akun layanan Kubernetes. Deployment klien dan server di bagian berikut menggunakan Knames akun layanan klien dan server Kubernetes.
kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_SERVER_KSA kubectl create serviceaccount --namespace K8S_NAMESPACE DEMO_CLIENT_KSA
Izinkan akun layanan Kubernetes meniru identitas akun layanan Compute Engine default dengan membuat binding kebijakan IAM di 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}
Beri anotasi pada 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 Cloud Service Mesh
Gunakan petunjuk berikut untuk menginstal injector sidecar, menyiapkan layanan pengujian, dan menyelesaikan tugas deployment lainnya.
Menginstal injector file bantuan Envoy di cluster
Gunakan petunjuk di kedua bagian berikut dalam Penyiapan Cloud Service Mesh untuk Pod GKE dengan injeksi Envoy otomatis untuk men-deploy dan mengaktifkan injeksi sidecar Envoy di cluster Anda:
- Menginstal injector file bantuan Envoy.
Pastikan Anda mengonfigurasi nama mesh sebagai
sidecar_mesh
dan jaringan sebagai "", string kosong. - Mengaktifkan injeksi sidecar
Pastikan Anda menyelesaikan kedua set petunjuk sebelum menyiapkan layanan pengujian.
Menyiapkan layanan pengujian
Setelah menginstal injector sidecar Envoy, gunakan petunjuk ini untuk menyiapkan layanan pengujian untuk deployment Anda.
wget -q -O - https://storage.googleapis.com/traffic-director/security/ga/service_sample.yaml | sed -e s/DEMO_SERVER_KSA_PLACEHOLDER/DEMO_SERVER_KSA/g > service_sample.yaml kubectl apply -f service_sample.yaml
File service_sample.yaml
berisi podspec untuk aplikasi server demo Anda. Ada beberapa anotasi yang khusus untuk keamanan Cloud Service Mesh.
Metadata proxy Cloud Service Mesh
Podspec menentukan anotasi proxyMetadata
:
spec: ... annotations: cloud.google.com/proxyMetadata: '{"app": "payments"}' ...
Saat Pod diinisialisasi, proxy sidecar akan mengambil anotasi ini dan mentransmisikannya ke Cloud Service Mesh. Cloud Service Mesh kemudian dapat menggunakan informasi ini untuk mengirim kembali konfigurasi yang difilter:
- Di bagian selanjutnya dalam panduan ini, perhatikan bahwa kebijakan endpoint menentukan pencocokan endpoint.
- Pencocokan endpoint menentukan bahwa hanya klien yang menampilkan label dengan
nama
app
dan nilaipayments
yang menerima konfigurasi yang difilter.
Menggunakan sertifikat dan kunci mesh yang ditandatangani oleh CA Service
Podspec menentukan anotasi enableManagedCerts
:
spec: ... annotations: ... cloud.google.com/enableManagedCerts: "true" ...
Saat Pod diinisialisasi, sertifikat dan kunci yang ditandatangani CA Service akan otomatis di-mount di sistem file proxy sidecar lokal.
Mengonfigurasi port intersepsi traffic masuk
Podspec menentukan anotasi includeInboundPorts
:
spec: ... annotations: ... cloud.google.com/includeInboundPorts: "8000" ...
Ini adalah port tempat aplikasi server Anda memproses koneksi. Saat Pod diinisialisasi, proxy sidecar akan mengambil anotasi ini dan mengirimkannya ke Cloud Service Mesh. Cloud Service Mesh 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 dengan port aplikasi. Jika tidak, kebijakan keamanan yang sama akan berlaku untuk koneksi masuk ke port pemeriksaan kesehatan yang dapat menyebabkan koneksi ditolak sehingga server salah ditandai sebagai tidak sehat.
Mengonfigurasi layanan GKE dengan NEG
Layanan GKE harus diekspos melalui grup endpoint jaringan (NEG) agar Anda dapat mengonfigurasinya sebagai backend layanan backend Cloud Service Mesh. 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 sidecar, yang Anda perlukan untuk mendemonstrasikan fitur keamanan.
wget -q -O - https://storage.googleapis.com/traffic-director/security/ga/client_sample.yaml | sed -e s/DEMO_CLIENT_KSA_PLACEHOLDER/DEMO_CLIENT_KSA/g > client_sample.yaml kubectl apply -f client_sample.yaml
Podspec klien hanya menyertakan anotasi enableManagedCerts
. Peran ini diperlukan untuk memasang volume yang diperlukan untuk sertifikat dan kunci mesh terkelola GKE yang ditandatangani oleh instance Layanan CA.
Mengonfigurasi resource health check, aturan firewall, dan layanan backend
Di bagian ini, Anda akan membuat resource health check, aturan firewall, dan layanan backend untuk Cloud Service Mesh.
Buat health check.
gcloud compute health-checks create http td-gke-health-check \ --use-serving-port
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
Buat layanan backend dan kaitkan 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
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
.
Buat spesifikasi resource
Mesh
dan simpan dalam file bernamamesh.yaml
.name: sidecar-mesh interceptionPort: 15001
Port pencegatan secara default adalah
15001
jika Anda tidak menentukannya dalam filemesh.yaml
.Buat resource
Mesh
menggunakan spesifikasi mesh.yaml.gcloud network-services meshes import sidecar-mesh \ --source=mesh.yaml \ --location=global
Buat spesifikasi
HTTPRoute
dan simpan ke file bernamahttp_route.yaml
.Anda dapat menggunakan
PROJECT_ID
atauPROJECT_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"
Buat resource
HTTPRoute
menggunakan spesifikasi dalam filehttp_route.yaml
.gcloud network-services http-routes import helloworld-http-route \ --source=http_route.yaml \ --location=global
Konfigurasi Cloud Service Mesh telah selesai dan Anda kini dapat mengonfigurasi kebijakan autentikasi dan otorisasi.
Menyiapkan keamanan layanan-ke-layanan
Gunakan petunjuk di bagian berikut untuk menyiapkan keamanan layanan-ke-layanan.
Mengaktifkan mTLS di mesh
Untuk menyiapkan mTLS di mesh Anda, Anda harus mengamankan traffic keluar ke layanan backend dan mengamankan traffic masuk ke endpoint.
Format untuk referensi kebijakan
Perhatikan format wajib berikut untuk merujuk ke TLS server, TLS klien, dan kebijakan otorisasi:
projects/PROJECT_ID/locations/global/[serverTlsPolicies|clientTlsPolicies|authorizationPolicies]/[server-tls-policy|client-mtls-policy|authz-policy]
Contoh:
projects/PROJECT_ID/locations/global/serverTlsPolicies/server-tls-policy
projects/PROJECT_ID/locations/global/clientTlsPolicies/client-mtls-policy
projects/PROJECT_ID/locations/global/authorizationPolicies/authz-policy
Mengamankan traffic keluar ke layanan backend
Untuk mengamankan traffic keluar, Anda harus membuat kebijakan TLS klien terlebih dahulu yang melakukan hal berikut:
- Menggunakan
google_cloud_private_spiffe
sebagai plugin untukclientCertificate
, yang memprogram Envoy untuk menggunakan sertifikat mesh terkelola GKE sebagai identitas klien. - Menggunakan
google_cloud_private_spiffe
sebagai plugin untukserverValidationCa
yang memprogram Envoy untuk menggunakan sertifikat mesh terkelola GKE untuk validasi server.
Selanjutnya, Anda 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 (Subject Alternative Names) menginstruksikan klien untuk menegaskan identitas persis server yang terhubung dengannya.
Buat kebijakan TLS klien dalam file
client-mtls-policy.yaml
:name: "client-mtls-policy" clientCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe serverValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Impor kebijakan TLS klien:
gcloud network-security client-tls-policies import client-mtls-policy \ --source=client-mtls-policy.yaml --location=global
Lampirkan kebijakan TLS klien ke layanan backend. Hal ini 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"
Impor nilai:
gcloud compute backend-services import td-gke-service \ --global --source=demo-backend-service.yaml
Anda juga dapat menjalankan perintah berikut untuk memeriksa apakah permintaan gagal. Kegagalan ini sudah diperkirakan, karena klien mengharapkan sertifikat dari endpoint, tetapi endpoint tidak diprogram dengan kebijakan keamanan.
# Get the name of the Podrunning Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Anda akan melihat output seperti ini:
wget: server returned error: HTTP/1.1 503 Service Unavailable
Mengamankan traffic masuk ke endpoint
Untuk mengamankan traffic masuk, Anda harus membuat kebijakan TLS server terlebih dahulu yang melakukan hal berikut:
- Menggunakan
google_cloud_private_spiffe
sebagai plugin untukserverCertificate
, yang memprogram Envoy untuk menggunakan sertifikat mesh terkelola GKE sebagai identitas server. - Menggunakan
google_cloud_private_spiffe
sebagai plugin untukclientValidationCa
, yang memprogram Envoy untuk menggunakan sertifikat mesh yang dikelola GKE untuk validasi klien.
Simpan nilai kebijakan TLS server dalam file bernama
server-mtls-policy.yaml
.name: "server-mtls-policy" serverCertificate: certificateProviderInstance: pluginInstance: google_cloud_private_spiffe mtlsPolicy: clientValidationCa: - certificateProviderInstance: pluginInstance: google_cloud_private_spiffe
Buat kebijakan TLS server:
gcloud network-security server-tls-policies import server-mtls-policy \ --source=server-mtls-policy.yaml --location=global
Buat file bernama
ep_mtls.yaml
yang berisi pencocokan 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
Impor pencocokan 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. Header dicetak hanya jika koneksi adalah koneksi mTLS.
# Get the name of the Podrunning Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Anda akan melihat output seperti berikut:
GET /get HTTP/1.1 Host: service-test content-length: 0 x-envoy-internal: true accept: */* x-forwarded-for: 10.48.0.6 x-envoy-expected-rq-timeout-ms: 15000 user-agent: curl/7.35.0 x-forwarded-proto: http x-request-id: redacted x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
Perhatikan bahwa header x-forwarded-client-cert
disisipkan oleh Envoy sisi server dan berisi identitasnya sendiri (server) dan identitas klien sumber. 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 mengizinkan permintaan yang dikirim oleh akun DEMO_CLIENT_KSA
yang nama hostnya adalah service-test
, portnya adalah 8000
, dan metode HTTP-nya adalah GET
. Sebelum Anda
membuat kebijakan otorisasi, baca peringatan di
Membatasi akses menggunakan otorisasi.
Buat kebijakan otorisasi dengan membuat file bernama
authz-policy.yaml
.action: ALLOW name: authz-policy rules: - sources: - principals: - spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA destinations: - hosts: - service-test ports: - 8000 methods: - GET
Impor kebijakan:
gcloud network-security authorization-policies import authz-policy \ --source=authz-policy.yaml \ --location=global
Perbarui kebijakan endpoint untuk mereferensikan kebijakan otorisasi baru dengan menambahkan berikut ini 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 sidecar Envoy-nya menampilkan label
app:payments
.Impor kebijakan:
gcloud network-services endpoint-policies import ep \ --source=ep_mtls.yaml --location=global
Memvalidasi penyiapan
Jalankan perintah berikut untuk memvalidasi penyiapan.
# Get the name of the Podrunning Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test. # This is a valid request and will be allowed. TEST_CMD="wget -q -O - service-test; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Output yang diharapkan mirip dengan ini:
GET /get HTTP/1.1 Host: service-test content-length: 0 x-envoy-internal: true accept: */* x-forwarded-for: redacted x-envoy-expected-rq-timeout-ms: 15000 user-agent: curl/7.35.0 x-forwarded-proto: http x-request-id: redacted x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA
Jalankan perintah berikut untuk menguji apakah kebijakan otorisasi menolak permintaan yang tidak valid dengan benar:
# Failure case # Command to execute that tests connectivity to the service service-test. # This is an invalid request and server will reject because the server # authorization policy only allows GET requests. TEST_CMD="wget -q -O - service-test --post-data='' ; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
Output yang diharapkan mirip dengan ini:
<RBAC: access denied HTTP/1.1 403 Forbidden>
Menyiapkan kebijakan otorisasi pada sidecar di GKE
Bagian ini menunjukkan cara menyiapkan berbagai jenis kebijakan otorisasi pada sidecar Cloud Service Mesh di GKE.
Sebelum dapat membuat kebijakan otorisasi, Anda harus menginstal GCPAuthzPolicy CustomResourceDefinition (CRD):
curl https://github.com/GoogleCloudPlatform/gke-networking-recipes/blob/main/gateway-api/config/mesh/crd/experimental/gcpauthzpolicy.yaml \
| kubectl apply -f -
Kebijakan otorisasi untuk menolak permintaan
Jika Anda memiliki beban kerja yang seharusnya hanya melakukan panggilan keluar, seperti
cron job, Anda dapat mengonfigurasi kebijakan otorisasi untuk menolak semua permintaan
HTTP yang masuk ke beban kerja. Contoh berikut menolak permintaan HTTP masuk ke
workload example-app
.
Lakukan langkah-langkah berikut untuk membuat dan menerapkan kebijakan otorisasi penolakan:
Buat kebijakan kustom dengan membuat file bernama
deny-all-authz-policy.yaml
:cat >deny-all-authz-policy.yaml <<EOF apiVersion: networking.gke.io/v1 kind: GCPAuthzPolicy metadata: name: my-workload-authz namespace: ns1 spec: targetRefs: - kind: Deployment name: example-app httpRules: - to: operations: - paths: - type: Prefix value: "/" action: DENY EOF
Terapkan kebijakan:
kubectl apply -f deny-all-authz-policy.yaml
Kebijakan otorisasi untuk mengizinkan permintaan
Anda juga dapat mengonfigurasi kebijakan izin yang hanya mengizinkan permintaan yang cocok dengan
kriteria tertentu, sementara menolak permintaan lainnya. Contoh berikut mengonfigurasi
kebijakan otorisasi pada Deployment example-app
untuk hanya mengizinkan permintaan mTLS
dari Pod dengan identitas spiffee://cluster.local/ns1/pod1
.
Lakukan langkah-langkah berikut untuk membuat dan menerapkan kebijakan otorisasi izin:
Buat kebijakan kustom dengan membuat file bernama
allow-authz-policy.yaml
:cat >allow-authz-policy.yaml <<EOF apiVersion: networking.gke.io/v1 kind: GCPAuthzPolicy metadata: name: my-workload-authz namespace: ns1 spec: targetRefs: - kind: Deployment name: example-app httpRules: - from: sources: - principals: - type: Exact value: "spiffee://cluster.local/ns1/pod1" action: ALLOW EOF
Terapkan kebijakan:
kubectl apply -f allow-authz-policy.yaml
Menyiapkan keamanan gateway traffic masuk
Bagian ini mengasumsikan bahwa Anda telah menyelesaikan bagian keamanan layanan ke layanan, termasuk menyiapkan cluster GKE dengan injektor otomatis sidecar, membuat otoritas sertifikat, dan membuat kebijakan endpoint.
Di bagian ini, Anda akan men-deploy proxy Envoy sebagai gateway ingress yang menghentikan koneksi TLS dan mengizinkan permintaan dari klien internal cluster.
Untuk menyiapkan gateway ingress guna menghentikan TLS, lakukan hal berikut:
- Deploy layanan Kubernetes yang dapat dijangkau menggunakan alamat IP internal cluster.
- Deployment ini terdiri dari proxy Envoy mandiri yang diekspos sebagai layanan Kubernetes dan terhubung ke Cloud Service Mesh.
- Buat kebijakan TLS server untuk menghentikan TLS.
- Buat kebijakan otorisasi untuk mengizinkan permintaan masuk.
Men-deploy layanan gateway ingress ke GKE
Jalankan perintah berikut untuk men-deploy layanan gateway ingress 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
File gateway_sample.yaml
adalah spesifikasi untuk gateway ingress. Bagian berikut
menjelaskan beberapa penambahan pada spesifikasi.
Menonaktifkan injeksi sidecar Cloud Service Mesh
Spesifikasi gateway_sample.yaml
men-deploy proxy Envoy sebagai satu-satunya container. Pada
langkah sebelumnya, Envoy disuntikkan sebagai sidecar ke container aplikasi. Untuk
menghindari beberapa Envoy menangani permintaan, Anda dapat menonaktifkan injeksi sidecar
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 injector file bantuan saat melihat anotasi
cloud.google.com/enableManagedCerts: "true"
. Volume gke-workload-certificates
berisi sertifikat dan kunci SPIFFE yang dikelola GKE yang ditandatangani oleh
instance Layanan CA yang Anda siapkan.
Menetapkan alamat IP internal cluster
Konfigurasi gateway ingress dengan layanan berjenis ClusterInternal
. Tindakan ini akan membuat nama host DNS yang dapat di-resolve secara internal untuk mesh-gateway
. Saat
klien mengirim permintaan ke mesh-gateway:443
, Kubernetes
segera merutekan permintaan ke port deployment Envoy gateway masuk
8080
.
Mengaktifkan TLS di gateway traffic masuk
Gunakan petunjuk ini untuk mengaktifkan TLS di gateway ingress.
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
Impor kebijakan TLS server:
gcloud network-security server-tls-policies import server-tls-policy \ --source=server-tls-policy.yaml --location=global
Buat target baru
Gateway
dan simpan di filetd-gke-gateway.yaml
. Tindakan ini melampirkan kebijakan TLS server dan mengonfigurasi gateway 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
Impor gateway:
gcloud network-services gateways import td-gke-gateway \ --source=td-gke-gateway.yaml \ --location=global
Buat dan simpan
HTTPRoute
baru bernamatd-gke-route
yang mereferensikan gateway dan merutekan semua permintaan ketd-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"
Impor
HTTPRoute
:gcloud network-services http-routes import td-gke-route \ --source=td-gke-route.yaml \ --location=global
Secara opsional, perbarui kebijakan otorisasi di backend untuk mengizinkan permintaan jika semua kondisi berikut terpenuhi:
- Permintaan dikirim oleh
DEMO_CLIENT_KSA
. (Deployment gateway ingress menggunakan akun layananDEMO_CLIENT_KSA
.) - Permintaan dengan host
mesh-gateway
atauservice-test
- Port:
8000
Anda tidak perlu menjalankan perintah ini kecuali jika Anda mengonfigurasi kebijakan otorisasi untuk backend. Jika tidak ada kebijakan otorisasi di endpoint atau tidak berisi 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
- Permintaan dikirim oleh
Impor kebijakan:
gcloud network-security authorization-policies import authz-policy \ --source=authz-policy.yaml \ --location=global
Memvalidasi deployment gateway ingress
Anda menggunakan container baru bernama debug
untuk mengirim permintaan ke gateway ingress
guna memvalidasi deployment.
Dalam spesifikasi berikut, anotasi "sidecar.istio.io/inject":"false"
mencegah
penyuntik sidecar Cloud Service Mesh otomatis menyuntikkan proxy
sidecar. Tidak ada sidecar untuk membantu penampung debug
dalam perutean permintaan.
Container harus terhubung ke gateway ingress untuk perutean.
Spesifikasi mencakup tanda --no-check-certificate
, yang mengabaikan validasi sertifikat server. Kontainer debug
tidak memiliki sertifikat validasi certificate authority yang diperlukan untuk memvalidasi sertifikat yang ditandatangani oleh CA Service yang digunakan oleh gateway ingress untuk menghentikan TLS.
Di lingkungan produksi, sebaiknya download sertifikat validasi Layanan CA dan pasang atau instal di klien Anda. Setelah Anda menginstal sertifikat validasi, hapus opsi
--no-check-certificate
dari perintah wget
.
Jalankan perintah berikut:
kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway; echo"
Anda akan melihat output yang mirip dengan ini:
GET / HTTP/1.1 Host: 10.68.7.132 x-forwarded-client-cert: By=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_SERVER_KSA;Hash=Redacted;Subject="Redacted;URI=spiffe://PROJECT_ID.svc.id.goog/ns/K8S_NAMESPACE/sa/DEMO_CLIENT_KSA x-envoy-expected-rq-timeout-ms: 15000 x-envoy-internal: true x-request-id: 5ae429e7-0e18-4bd9-bb79-4e4149cf8fef x-forwarded-for: 10.64.0.53 x-forwarded-proto: https content-length: 0 user-agent: Wget
Jalankan perintah pengujian negatif berikut:
# Negative test # Expect this to fail because gateway expects TLS. kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - http://mesh-gateway:443/headers; echo"
Anda akan melihat output yang mirip dengan berikut ini:
wget: error getting response: Connection reset by peer
Jalankan perintah pengujian negatif berikut:
# Negative test. # AuthorizationPolicy applied on the endpoints expect a GET request. Otherwise # the request is denied authorization. kubectl run -i --tty --rm debug --image=busybox --restart=Never --overrides='{ "metadata": {"annotations": { "sidecar.istio.io/inject":"false" } } }' -- /bin/sh -c "wget --no-check-certificate -qS -O - https://mesh-gateway --post-data=''; echo"
Anda akan melihat output yang mirip dengan berikut ini:
HTTP/1.1 403 Forbidden wget: server returned error: HTTP/1.1 403 Forbidden
Menghapus deployment
Secara opsional, Anda dapat menjalankan perintah ini untuk menghapus deployment yang Anda buat 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 Cloud Service Mesh 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 errorupstream 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, kemungkinan token akun layanan dipasang dengan tidak benar, atau menggunakan audience
yang berbeda, atau keduanya.
Untuk mengetahui informasi selengkapnya, lihat Pesan error di log Envoy menunjukkan adanya masalah konfigurasi.
Pod tidak dibuat
Untuk memecahkan masalah ini, lihat Memecahkan masalah deployment otomatis untuk Pod GKE.
Envoy tidak melakukan autentikasi dengan Cloud Service Mesh
Saat Envoy (envoy-proxy
) terhubung ke Cloud Service Mesh untuk mengambil konfigurasi xDS, Envoy menggunakan Workload Identity Federation untuk GKE 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 Anda melihat error ini, pastikan Anda menjalankan Google Cloud CLI versi terbaru:
gcloud components update
Pod tetap dalam status tertunda
Jika Pod tetap dalam status tertunda selama proses penyiapan, tingkatkan resource CPU dan memori untuk Pod dalam spesifikasi deployment Anda.
Tidak dapat membuat cluster dengan flag --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 dimulai
Pod yang menggunakan sertifikat mesh GKE mungkin gagal dimulai jika penyediaan sertifikat gagal. Hal ini dapat terjadi dalam situasi seperti berikut:
WorkloadCertificateConfig
atauTrustConfig
salah dikonfigurasi atau tidak ada.- CSR tidak disetujui.
Anda dapat memeriksa apakah penyediaan sertifikat gagal dengan memeriksa peristiwa Pod.
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.
Periksa peristiwa terbaru untuk Pod Anda:
kubectl describe pod -n POD_NAMESPACE POD_NAME
Jika penyediaan sertifikat gagal, Anda akan melihat peristiwa dengan kolom
Type=Warning
,Reason=FailedMount
,From=kubelet
, danMessage
yang dimulai denganMountVolume.SetUp failed for volume "gke-workload-certificates"
. KolomMessage
berisi informasi pemecahan masalah.Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedMount 13s (x7 over 46s) kubelet MountVolume.SetUp failed for volume "gke-workload-certificates" : rpc error: code = Internal desc = unable to mount volume: store.CreateVolume, err: unable to create volume "csi-4d540ed59ef937fbb41a9bf5380a5a534edb3eedf037fe64be36bab0abf45c9c": caPEM is nil (check active WorkloadCertificateConfig)
Lihat langkah-langkah pemecahan masalah berikut jika alasan Pod Anda tidak dimulai adalah karena objek yang salah dikonfigurasi, atau karena CSR ditolak.
WorkloadCertificateConfig
atau TrustConfig
salah dikonfigurasi
Pastikan Anda membuat objek WorkloadCertificateConfig
dan TrustConfig
dengan benar. Anda dapat mendiagnosis kesalahan konfigurasi pada salah satu objek ini menggunakan kubectl
.
Mengambil status saat ini.
Untuk
WorkloadCertificateConfig
:kubectl get WorkloadCertificateConfig default -o yaml
Untuk
TrustConfig
:kubectl get TrustConfig default -o yaml
Periksa output status. Objek yang valid akan memiliki kondisi dengan
type: Ready
danstatus: "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. Kolomreason
danmessage
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.
Mencantumkan CSR yang relevan menggunakan
kubectl
:kubectl get csr \ --field-selector='spec.signerName=spiffe.gke.io/spiffe-leaf-signer'
Pilih CSR yang
Approved
dan bukanIssued
, atau bukanApproved
.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 kolom message
dan reason
.
Aplikasi tidak dapat menggunakan kredensial mTLS yang dikeluarkan
Pastikan masa berlaku sertifikat belum habis:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Periksa apakah jenis kunci yang Anda gunakan didukung oleh aplikasi Anda.
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Public Key Algorithm" -A 3
Pastikan CA penerbit menggunakan keluarga kunci yang sama dengan kunci sertifikat.
Dapatkan status instance 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 berupasubordinates
atauroots
.ISSUING_CA_NAME
: nama CA penerbit.ISSUING_CA_LOCATION
: region CA penerbit.
Pastikan
keySpec.algorithm
dalam output adalah algoritma kunci yang sama dengan yang Anda tetapkan dalam manifes YAMLWorkloadCertificateConfig
. Outputnya akan terlihat seperti ini:config: ... subjectConfig: commonName: td-sub-ca subject: organization: TestOrgLLC subjectAltName: {} createTime: '2021-05-04T05:37:58.329293525Z' issuingOptions: includeCaCertUrl: true keySpec: algorithm: RSA_PKCS1_2048_SHA256 ...
Sertifikat ditolak
- Pastikan aplikasi peer menggunakan paket kepercayaan yang sama untuk memverifikasi sertifikat.
Pastikan masa berlaku sertifikat belum habis:
cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -text -noout | grep "Not After"
Verifikasi bahwa kode klien, jika tidak menggunakan Credentials Reloading API gRPC Go, secara berkala memperbarui kredensial dari sistem file.
Pastikan bahwa beban kerja Anda berada di domain tepercaya yang sama dengan CA Anda. Sertifikat mesh GKE mendukung komunikasi antar-workload dalam satu domain tepercaya.