Anthos Service Mesh 1.9 telah mencapai akhir siklus proses dan tidak lagi didukung. Lihat Mengupgrade dari versi sebelumnya.

Lihat dokumentasi terbaru atau pilih versi lain yang tersedia:

Versi yang tersedia

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

219}

Menyelesaikan masalah keamanan di Anthos Service Mesh

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

Di Anthos Service Mesh, Mesh CA atau Istiod menerbitkan sertifikat untuk workload di semua cluster dalam mesh. Autentikasi (misalnya, mTLS) dan kebijakan Otorisasi (misalnya, izinkan/tolak) dikirim ke setiap cluster. Kebijakan ini menentukan beban kerja mana yang dapat berkomunikasi dan bagaimana.

Masalah TLS

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

Contoh di bagian ini menggunakan variabel ${CTX}, yang merupakan nama konteks 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

Pastikan 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

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

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

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 menunjukkan 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 pada 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 tersebut. Jika Anda menggunakan Mesh CA, pastikan CN root certificate berisi istio_v1_cloud_workload_root-signer-.... Jika Anda menggunakan Istiod sebagai certificate authority, pastikan root certificate ditetapkan dengan O = <var>YOUR_TRUST_DOMAIN</var>.

Error `bad certificate` TLS di log Istiod

Jika Anda melihat error bad certificate handshake TLS di log, hal tersebut dapat mengindikasikan bahwa Istiod gagal membuat koneksi TLS ke layanan.

Anda dapat menggunakan string ekspresi reguler TLS handshake error.*bad certificate untuk menemukan error ini di log.

Error ini biasanya bersifat informatif dan bersifat sementara. Namun, jika terus berlanjut, error mungkin menunjukkan masalah di sistem Anda.

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

Webhook injektor file bantuan (yang digunakan untuk injeksi file bantuan otomatis) memerlukan paket CA untuk membuat koneksi yang aman dengan server API dan Istiod. Paket CA ini di-patch ke dalam konfigurasi oleh istiod, tetapi terkadang dapat ditimpa (misalnya, jika Anda menerapkan kembali konfigurasi webhook).
Verifikasi keberadaan paket CA:
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.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

Kebijakan otorisasi menolak permintaan jika tidak diizinkan oleh kebijakan. Untuk protokol HTTP (termasuk gRPC), permintaan akan ditolak dengan kode status 403. Untuk protokol non-HTTP, koneksi akan dihentikan secara langsung. Untuk mengetahui informasi selengkapnya tentang kebijakan otorisasi, lihat Otorisasi Istio.

Log akses Kemampuan observasi Google Cloud menyertakan informasi yang diperlukan saat permintaan ditolak oleh kebijakan otorisasi, yang dapat berguna untuk beberapa situasi. Misalnya, log menunjukkan jumlah permintaan yang ditolak oleh kebijakan otorisasi, yang dapat membantu Anda menentukan aturan kebijakan mana yang menyebabkan penolakan versus penolakan dari aplikasi backend.

Log akses Kemampuan observasi Google Cloud menyertakan label berikut untuk penolakan otorisasi.

response_details: akan disetel ke AuthzDenied jika penolakan disebabkan oleh kebijakan otorisasi.
policy_name: akan menyertakan namespace dan nama kebijakan DENY otorisasi yang menyebabkan penolakan. Nilai ini dalam format <Namespace>.<Name>, misalnya, foo.deny-method-get berarti kebijakan otorisasi deny-method-get dalam namespace foo.
policy_rule: akan menyertakan indeks aturan di dalam kebijakan otorisasi yang menyebabkan penolakan, misalnya, 0 berarti aturan pertama dalam kebijakan.

Untuk informasi selengkapnya tentang cara mendapatkan log akses, lihat Mengakses log di Cloud Logging.

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

Dalam output, pesan access denied menunjukkan bahwa kebijakan otorisasi diterapkan 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

Error 'customresourcedefinitions.apiextensions.k8s.io dilarang' di log Istiod

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 error ini di log.

Error ini dapat terjadi jika deployment Istiod tidak memiliki binding IAM yang tepat atau tidak memiliki izin RBAC yang memadai untuk membaca resource kustom.

Periksa apakah Anda tidak memiliki binding IAM di akun. Pertama, pastikan Anda telah menetapkan kredensial dan izin dengan benar. Kemudian, periksa apakah binding IAM ada menggunakan perintah berikut. Dalam contoh ini, PROJECT_ID adalah output 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"
```
Periksa apakah aturan RBAC Anda telah diinstal dengan benar.
Jika aturan RBAC tidak ada, jalankan kembali istioctl install (atau metode penginstalan yang Anda gunakan untuk menginstal Anthos Service Mesh) untuk membuatnya kembali.
Jika aturan RBAC ada dan error terus berlanjut, pastikan bahwa ClusterRoleBindings dan RoleBindings melampirkan aturan RBAC ke Akun Layanan kubernetes yang benar. Selain itu, pastikan deployment situs Anda menggunakan akun layanan yang ditentukan.

`serverca` error proses di log Istio