Anda sedang melihat dokumentasi Service Mesh v1.20 lama.

Versi yang tersedia

Cloud Service Mesh
Arsip 1.20
arsip 1.19
Arsip 1.18

Halaman ini diterjemahkan oleh Cloud Translation API.

Menyelesaikan masalah keamanan di Cloud Service Mesh

Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara mengatasinya. Jika Anda memerlukan bantuan tambahan, lihat Mendapatkan dukungan.

Di Cloud Service Mesh, Mesh CA atau Istiod menerbitkan sertifikat untuk workload di semua cluster di jala tersebut. Autentikasi (misalnya mTLS) dan Kebijakan otorisasi (misalnya izinkan/tolak) dikirim ke setiap cluster. Kebijakan tersebut menentukan workload mana yang dapat berkomunikasi dan bagaimana caranya.

Masalah TLS

Bagian berikut menjelaskan cara menyelesaikan masalah terkait TLS di Cloud Service Mesh.

Contoh di bagian ini menggunakan variabel ${CTX}, yang merupakan konteks nama dalam file konfigurasi Kubernetes default yang Anda gunakan untuk mengakses cluster. Tetapkan variabel ${CTX} seperti contoh berikut:

export CTX=gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

Memverifikasi penerapan TLS

Memverifikasi bahwa permintaan teks biasa tidak diizinkan untuk suatu layanan, saat layanan tersebut memerlukan koneksi TLS:

kubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \
    SOURCE_CONTAINER -- curl -v DESTINATION_URL

Dengan asumsi bahwa layanan memerlukan koneksi TLS, permintaan teks biasa di atas akan gagal, sehingga menghasilkan output yang mirip dengan berikut ini:

curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56

Memeriksa sertifikat mTLS

Jika mTLS diaktifkan, periksa sertifikat mTLS beban kerja dengan melihat header X-Forwarded-Client-Cert. Untuk melakukannya, ikuti langkah-langkah berikut:

Deploy layanan contoh httpbin, yang dapat menampilkan header yang terima.

Gunakan curl untuk melihat header X-Forwarded-Client-Cert:

kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c \
SOURCE_CONTAINER -- curl http://httpbin.sample:8000/headers -s | \
grep X-Forwarded-Client-Cert

Header X-Forwarded-Client-Cert menampilkan informasi sertifikat mTLS, seperti contoh berikut:

X-Forwarded-Client-Cert": "By=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/httpbin;Hash=0781d68adfdab85b08b6758ed502f352464e81166f065cc6acde9433337b4494;Subject=\"OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US\";URI=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/sleep

Atau, gunakan openssl di file bantuan untuk melihat seluruh rantai sertifikat:
```
kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c istio-proxy \
openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000
```
Output akan menampilkan rantai sertifikat. Jika Anda menggunakan Mesh CA, pastikan CN root certificate berisi istio_v1_cloud_workload_root-signer-.... Jika Anda menggunakan Istiod sebagai certificate authority, verifikasi bahwa root sertifikat disetel dengan O = <var>YOUR_TRUST_DOMAIN</var>.

Error TLS `bad certificate` dalam log Istiod

Jika Anda melihat error bad certificate TLS handshake dalam log, hal ini mungkin menunjukkan bahwa Istiod gagal membuat koneksi TLS ke layanan.

Anda dapat menggunakan string ekspresi reguler TLS handshake error.*bad certificate untuk menemukan {i>error<i} ini di dalam log.

Kesalahan ini biasanya bersifat informatif dan sementara. Namun, jika mereka tetap ada, mereka mungkin menunjukkan adanya masalah di sistem Anda.

Pastikan istio-sidecar-injector MutatingWebhookConfiguration Anda memiliki paket CA.

Webhook injektor file bantuan (yang digunakan untuk injeksi file bantuan otomatis) membutuhkan paket CA untuk membuat koneksi aman dengan server API dan Disertai. Paket CA ini di-patch ke dalam konfigurasi berdasarkan istiod, tetapi dapat terkadang akan ditimpa (misalnya, jika Anda menerapkan kembali webhook ).
Memverifikasi keberadaan paket CA:

Catatan: Jika Anda telah menginstal lebih dari satu bidang kontrol, tentukan revisi yang spesifik.
```
kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'
```
Jika output tidak kosong, paket CA akan dikonfigurasi. Jika paket CA tidak ada, mulai ulang istiod agar dapat memindai ulang webhook dan menginstal ulang paket CA.

Logging penolakan kebijakan otorisasi

Untuk informasi tentang logging penolakan kebijakan otorisasi, lihat Logging penolakan.

Kebijakan otorisasi tidak diterapkan

Jika Anda melihat gejala kebijakan otorisasi tidak diterapkan, gunakan perintah berikut untuk memverifikasinya:

kubectl exec --context=${CTX} -it SOURCE_POD -n SOURCE_NAMESPACE \
    -c SOURCE_CONTAINER -- curl DESTINATION_URL

Di outputnya, pesan access denied menunjukkan bahwa kebijakan otorisasi ditegakkan dengan benar, seperti berikut:

RBAC: access denied

Jika Anda mengonfirmasi bahwa kebijakan otorisasi tidak diterapkan, tolak akses ke namespace. Contoh berikut menolak akses ke namespace bernama authz-ns:

kubectl apply --context=${CTX} -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-authz-ns
  namespace: authz-ns
spec:
  {}
EOF

'customresourceDefinitions.apiextensions.k8s.io dilarang' error dalam log Istio

Anda mungkin melihat error yang mirip dengan yang berikut ini:

error failed to list CRDs: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "system:serviceaccount:istio-system:istiod-service-account" cannot list resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope

Anda dapat menggunakan string ekspresi reguler /error.*cannot list resource/ untuk menemukan {i>error<i} ini di log.

Error ini dapat terjadi saat deployment Istiod Anda tidak memiliki binding IAM yang benar atau tidak memiliki izin RBAC yang memadai untuk membaca sumber daya khusus.

Periksa apakah binding IAM di akun Anda tidak ada. Pertama, pastikan Anda miliki dengan benar menetapkan kredensial dan izin. Kemudian, periksa apakah binding IAM ada menggunakan perintah berikut. Di beberapa contoh ini, PROJECT_ID adalah output dari gcloud config get-value project dan PROJECT_NUMBER adalah output dari gcloud projects list --filter="project_id=${PROJECT_ID}" --format="value(project_number)":
```
gcloud projects add-iam-policy-binding ${PROJECT_ID} --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-meshdataplane.iam.gserviceaccount.com" --role "roles/meshdataplane.serviceAgent"
```
Pastikan aturan RBAC Anda diinstal dengan benar.
Jika aturan RBAC tidak ada, jalankan kembali asmcli install untuk membuatnya kembali.
Jika ada aturan RBAC dan error tetap ada, periksa apakah ClusterRoleBindings dan RoleBindings menambahkan aturan RBAC ke Akun Layanan kubernetes yang benar. Selain itu, pastikan deployment istiod Anda menggunakan akun layanan yang ditentukan.

`serverca` error proses dalam log Istiod