Menyelesaikan masalah keamanan di Cloud Service Mesh

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

Di Cloud Service Mesh, Istiod atau otoritas sertifikat Cloud Service Mesh menerbitkan sertifikat ke workload di semua cluster dalam mesh. Kebijakan Autentikasi (misalnya mTLS) dan Otorisasi (misalnya izinkan/tolak) akan dikirim ke setiap cluster. Kebijakan ini menentukan workload mana yang dapat berkomunikasi dan caranya.

Masalah TLS

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

Contoh dalam 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

Verifikasi bahwa permintaan teks biasa tidak diizinkan untuk layanan, jika layanan memerlukan koneksi TLS:

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

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

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

Periksa sertifikat mTLS

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

  1. Deploy layanan sampel httpbin, yang dapat menampilkan header yang diterimanya.

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

  3. Atau, gunakan openssl di sidecar untuk melihat seluruh rantai sertifikat:

    kubectl debug --image istio/base --target istio-proxy -it --context=${CTX} SOURCE_POD \
-n SOURCE_NAMESPACE -- openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000

    Output akan menampilkan rantai sertifikat. Jika Anda menggunakan CA Mesh, verifikasi bahwa CN sertifikat root berisi istio_v1_cloud_workload_root-signer-.... Jika Anda menggunakan Istiod sebagai otoritas sertifikat, verifikasi bahwa sertifikat root ditetapkan dengan O = <var>YOUR_TRUST_DOMAIN</var>.

Error TLS bad certificate di log Istiod

Jika Anda melihat error handshake TLS bad certificate di 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 error ini dalam log.

Error ini biasanya bersifat informatif dan sementara. Namun, jika masalah berlanjut, hal ini dapat mengindikasikan adanya masalah dalam sistem Anda.

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

    Webhook injector sidecar (yang digunakan untuk injeksi sidecar 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).

  2. Verifikasi keberadaan paket CA:

    kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'

    Jika output tidak kosong, paket CA dikonfigurasi. Jika paket CA tidak ada, mulai ulang istiod agar memindai ulang webhook dan menginstal ulang paket CA.

Penyiapan SNI eksplisit

Saat Anda menggunakan SNI untuk merutekan traffic di layanan eksternal, jika Anda ingin membuat koneksi TLS menggunakan TLS origination, Anda harus menentukan SNI secara eksplisit di ClientTLSSettings.sni di DestinationRule. Misalnya,

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-external-service-dr
spec:
  host: external.example.com # The host for which this DestinationRule applies
  trafficPolicy:
    tls:
      mode: SIMPLE # Or MUTUAL, if mTLS is required
      sni: specific-sni.example.com # The SNI value to set for outbound TLS connections

Logging penolakan kebijakan otorisasi

Untuk mengetahui 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

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 is forbidden' di log Istiod

Anda mungkin melihat error yang serupa dengan berikut:

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 dalam log.

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

  1. Periksa apakah Anda kehilangan binding IAM di akun Anda. 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 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." --role "roles/meshdataplane.serviceAgent"

  2. Pastikan aturan RBAC Anda diinstal dengan benar.

  3. Jika aturan RBAC tidak ada, jalankan ulang asmcli install untuk membuatnya ulang.

  4. Jika aturan RBAC ada dan error tetap terjadi, periksa apakah ClusterRoleBindings dan RoleBindings melampirkan aturan RBAC ke Akun Layanan Kubernetes yang benar. Selain itu, pastikan deployment istiod Anda menggunakan akun layanan yang ditentukan.

Error proses serverca di log Istiod

Anda mungkin melihat error yang serupa dengan berikut:

Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error

Anda dapat menggunakan string ekspresi reguler /serverca.*Authentication failed:.*JWT/ untuk menemukan error ini dalam log.

Error ini dapat terjadi saat penerbit JWT salah dikonfigurasi, klien menggunakan token yang sudah tidak berlaku, atau masalah keamanan lainnya mencegah koneksi diautentikasi ke istiod dengan benar.

Pembaruan sertifikat dan kunci pribadi yang lambat untuk TLS Ingress Gateway

Jika cluster Anda menggunakan TRAFFIC_DIRECTOR penerapan bidang kontrol dan gateway ingress Anda menggunakan deployment tanpa kredensial yang terpasang, pembaruan kredensial dapat memerlukan waktu hingga 60 menit.

Agar sertifikat baru segera berlaku, Anda dapat memulai ulang Pod gateway ingress atau mengikuti petunjuk tentang mengoptimalkan deployment.