Memastikan kompatibilitas sertifikat TLS sebelum mengupgrade ke GKE 1.29

Autopilot Standard

Cluster GKE yang menjalankan versi 1.29 atau yang lebih baru tidak mendukung sertifikat Transportation Layer Security (TLS) yang ditandatangani dengan algoritma SHA-1. Untuk mencegah dampak pada cluster, Anda perlu mengganti sertifikat backend webhook dan server API ekstensi yang tidak kompatibel dengan sertifikat menggunakan algoritma penandatanganan yang kompatibel sebelum mengupgrade cluster ke versi 1.29.

Dampak terhadap cluster penghapusan ini

GKE menjeda upgrade otomatis saat mendeteksi bahwa ada cluster yang menggunakan sertifikat yang tidak kompatibel dengan versi 1.29. Setelah Anda mengganti sertifikat dengan sertifikat menggunakan algoritma penandatanganan yang kompatibel, atau versi 1.28 mencapai akhir masa pakai, GKE akan melanjutkan upgrade otomatis.

Jika tidak mengganti sertifikat yang tidak kompatibel sebelum mengupgrade ke 1.29, Anda dapat mengalami masalah berikut pada cluster:

Backend webhook GKE yang menggunakan sertifikat TLS yang ditandatangani dengan algoritma SHA-1 akan berhenti berfungsi karena kegagalan autentikasi. Panggilan webhook akan gagal untuk bidang kontrol Kubernetes yang berkomunikasi dengan webhook Anda dengan sertifikat yang tidak kompatibel. Bergantung pada konfigurasi Anda, terutama jika Anda menggunakan webhook penerimaan, kegagalan menghubungi webhook dapat memblokir pembuatan resource di cluster Anda, seperti pembuatan Pod, yang bisa sangat mengganggu.
Panggilan ke API yang disalurkan oleh server API ekstensi akan gagal.

Alasan Kubernetes menghapus kemampuan ini

GKE mengoperasikan Kubernetes open source, yang menggunakan komponen kube-apiserver untuk menghubungi backend server API ekstensi dan webhook Anda menggunakan TLS. Komponen kube-apiserver ditulis dalam bahasa pemrograman Go.

Dari Go versi 1.18, Go mulai menolak sertifikat TLS yang ditandatangani dengan algoritma SHA-1, tetapi meninggalkan tombol debug x509sha1=1 untuk mengaktifkan perilaku lama guna memudahkan proses migrasi. GKE versi 1.24 adalah versi pertama yang dibuat menggunakan Go versi 1.18. Build GKE Kubernetes telah mengaktifkan pengalihan debug ini hingga versi 1.29. Tombol ini akan dihapus di Go 1.24. GKE 1.29 membangun Kubernetes dengan tombol yang dinonaktifkan untuk mempersiapkan penghapusan Go di masa mendatang dari tombol debug. Setelah GKE mengupgrade cluster Anda ke versi 1.29, panggilan dari bidang kontrol cluster Anda ke webhook atau server API ekstensi di cluster yang menyediakan sertifikat TLS yang ditandatangani dengan algoritma SHA-1 akan gagal.

Identifikasi cluster yang terdampak

GKE memantau cluster Anda dan menggunakan layanan Pemberi Rekomendasi untuk memberikan panduan melalui insight dan rekomendasi yang mengidentifikasi cluster yang memiliki backend server API ekstensi atau webhook menggunakan sertifikat TLS yang ditandatangani dengan algoritma SHA-1. Atau, Anda dapat menggunakan log untuk mengidentifikasi panggilan ke backend yang terpengaruh dari cluster Anda.

Cara mendapatkan insight dan rekomendasi

Untuk cluster yang menjalankan versi 1.24 atau yang lebih baru, ikuti petunjuk untuk melihat insight dan rekomendasi. Anda dapat memperoleh insight menggunakan gcloud CLI, atau Recommender API, yang memfilter dengan subjenis DEPRECATION_K8S_SHA_1_CERTIFICATE.

Cara mendapatkan log

Untuk cluster yang menjalankan versi 1.24 atau yang lebih baru dengan Cloud Logging diaktifkan, GKE menyediakan log Cloud Audit Logs untuk mengidentifikasi panggilan ke backend yang terpengaruh dari cluster Anda. Anda dapat menggunakan filter berikut untuk mencari log:

logName =~ "projects/.*/logs/cloudaudit.googleapis.com%2Factivity"
resource.type = "k8s_cluster"
operation.producer = "k8s.io"
"insecure-sha1.invalid-cert.kubernetes.io"

Log audit menyertakan nama host backend yang terpengaruh. Untuk mempelajari lebih lanjut cara menafsirkan hasil, lihat bagian berikutnya.

Menafsirkan panduan dari insight dan rekomendasi

Rekomendasi mencakup nama host backend yang terpengaruh, dan apakah itu webhook atau server API ekstensi. Nama host yang merujuk ke Layanan di cluster akan mengikuti format <service-name>.<namespace>.svc.

Jika sertifikat backend yang terpengaruh berasal dari server webhook, nama host dapat berupa Layanan di cluster, atau URL. Untuk mempelajari lebih lanjut, lihat Menghubungi webhook.

Jika sertifikat yang terpengaruh berasal dari server API ekstensi, nama host adalah Layanan dalam cluster. Untuk mempelajari lebih lanjut, lihat Menghubungi server API ekstensi.

Setelah Anda mengidentifikasi backend yang terpengaruh, ikuti petunjuk untuk memeriksa sertifikat Layanan atau Memeriksa sertifikat backend URL, bergantung pada jenisnya.

Jika cluster belum memanggil server dengan sertifikat yang terpengaruh dalam 30 hari terakhir, Anda tidak akan melihat rekomendasi apa pun.

Contoh rekomendasi

Lihat contoh daftar rekomendasi berikut:

RECOMMENDATION_ID                     PRIMARY_IMPACT_CATEGORY  RECOMMENDATION_STATE  LAST_REFRESH_TIME               PRIORITY  RECOMMENDER_SUBTYPE                DESCRIPTION
26bfcb32-6f2a-407c-874f-8cf55b3af912  RELIABILITY              ACTIVE                2024-02-15T01:09:04.454456273Z  P2        DEPRECATION_K8S_SHA_1_CERTIFICATE  Update the webhook and/or extension API servers that use certificates signed with SHA-1 algorithm to use certificates with compatible signing algorithms prior to upgrading the cluster to version 1.29. [Learn more](https://cloud.google.com/kubernetes-engine/docs/deprecations/sha1-1-29#mitigate_the_risk_of_upgrading_to_129).

Untuk mendapatkan detail cluster dan Layanan, jelaskan rekomendasinya. Output untuk Layanan bernama example-webhook di namespace default mirip dengan yang berikut ini:

associatedInsights:
- insight: projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/insightTypes/google.container.DiagnosisInsight/insights/d76887a8-9eed-41a0-9459-d49dee43455e
content:
  overview:
    featureDeprecationRecommendation:
    - featureName: x.509_certificate_signature_algorithm
      featureReplacementValue: algorithm [compatible with GKE v1.29](https://cloud.google.com/kubernetes-engine/docs/deprecations/sha1-1-29#compatible-signing-algorithms)
      featureValue: SHA1
      stopServingVersion: '1.29'
      targetType: hostname
      targetValue: example-webhook.default.svc
    targetClusters:
    - clusterId: 3be916a554724c79a2314c8baee3fd57cf1c39df1ad34c3daf291db701b6d541
      clusterUri: //container.googleapis.com/projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/clusters/<CLUSTER_NAME>
description: Update the webhook and/or extension API servers that use certificates
  signed with SHA-1 algorithm to use certificates with compatible signing algorithms
  prior to upgrading the cluster to version 1.29. [Learn more](https://cloud.google.com/kubernetes-engine/docs/deprecations/sha1-1-29#mitigate_the_risk_of_upgrading_to_129).
etag: '"ad50aac8278951d5"'
lastRefreshTime: '2024-02-15T01:09:04.454456273Z'
name: projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/recommenders/google.container.DiagnosisRecommender/recommendations/26bfcb32-6f2a-407c-874f-8cf55b3af912
primaryImpact:
  category: RELIABILITY
  reliabilityProjection:
    risks:
    - SERVICE_DISRUPTION
priority: P2
recommenderSubtype: DEPRECATION_K8S_SHA_1_CERTIFICATE
stateInfo:
  state: ACTIVE
targetResources:
- //container.googleapis.com/projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/clusters/<CLUSTER_NAME>

Memeriksa sertifikat Service

Baik webhook maupun server API ekstensi dapat didukung oleh Layanan.

Setelah Anda mengidentifikasi Layanan backend yang relevan untuk diperiksa, gunakan petunjuk berikut untuk memeriksa sertifikat setiap Layanan guna memeriksa sertifikat mana yang menggunakan algoritma SHA-1 dan perlu diperbarui.

Temukan pemilih dan port target Layanan:
```
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
```
Ganti NAMESPACE dan SERVICE_NAME dengan nilai dari targetValue.

Outputnya mirip dengan hal berikut ini:
```
Name: example-service
Namespace: default
Labels: run=nginx
Selector: run=nginx
Type: ClusterIP
IP: 172.21.xxx.xxx
Port: 443
TargetPort: 444
```
Output ini menunjukkan bahwa example-service memiliki pemilih run=nginx dan port target 444.

Catatan: Jika TargetPort tidak disertakan, nilai tersebut akan sama dengan kolom Port.

Temukan Pod yang cocok dengan pemilih:

kubectl get pods --namespace=NAMESPACE --selector=run=nginx

Outputnya mirip dengan hal berikut ini:

NAME          READY   STATUS    RESTARTS   AGE
example-pod   1/1     Running   0          21m

Output ini menunjukkan bahwa Pod yang cocok adalah example-pod.

Siapkan penerusan port dari localhost kubectl ke Pod:

Catatan: Perintah berikutnya ini menggunakan port 8888, tetapi Anda dapat memilih port lain, karena port ini dipilih secara acak.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Ganti SERVICE_TARGET_PORT dengan nilai TargetPort dari Layanan. Jika TargetPort tidak disertakan, gunakan nilai Port.
Gunakan openssl untuk menampilkan sertifikat yang digunakan Layanan:
```
openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
```
Contoh output ini menunjukkan sertifikat valid yang ditandatangani dengan algoritma SHA-256:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
```
Contoh output ini menunjukkan sertifikat tidak valid yang ditandatangani dengan algoritma SHA-1:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
Jika output dari sertifikat serupa, Anda harus mengupdate sertifikat agar menggunakan algoritma penandatanganan yang kompatibel. Misalnya, jika menggunakan certificate.k8s.io API untuk mengelola sertifikat TLS di cluster, Anda dapat mengikuti petunjuk untuk membuat permintaan penandatanganan sertifikat.

Membersihkan penerusan port

Untuk membersihkan penerusan port yang berjalan di latar belakang, cari proses dan hentikan.

Jalankan perintah berikut untuk menampilkan proses yang sedang berjalan:
```
jobs
```
Lihat output untuk mendapatkan ID proses yang akan dihentikan:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Contoh output ini menunjukkan bahwa ID proses adalah 1.
Hentikan proses, dengan mengganti PROCESS_ID:
```
kill %PROCESS_ID
```
Lihat output berikut:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
Contoh output ini menunjukkan bahwa proses telah dihentikan.

Memeriksa sertifikat backend URL

Jika webhook menggunakan backend url, hubungkan langsung ke nama host yang ditentukan di URL. Misalnya, jika URL-nya adalah https://example.com:123/foo/bar, gunakan perintah openssl berikut untuk menampilkan sertifikat yang digunakan backend:

openssl s_client -connect example.com:123 </dev/null | openssl x509 -noout -text

Contoh output ini menunjukkan sertifikat valid yang ditandatangani dengan algoritma SHA-256:

Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption

Contoh output ini menunjukkan sertifikat tidak valid yang ditandatangani dengan algoritma SHA-1:

Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption

Jika output dari sertifikat serupa, Anda harus mengupdate sertifikat agar menggunakan algoritma penandatanganan yang kompatibel. Misalnya, jika menggunakan certificate.k8s.io API untuk mengelola sertifikat TLS di cluster, Anda dapat mengikuti petunjuk untuk membuat permintaan penandatanganan sertifikat.

Mengurangi risiko upgrade ke versi 1.29

Setelah mengidentifikasi cluster yang terpengaruh dan Layanan backend-nya menggunakan sertifikat yang ditandatangani dengan algoritma SHA-1, Anda harus mengupdate Layanan agar dapat menggunakan sertifikat dengan algoritma penandatanganan yang kompatibel sebelum mengupgrade cluster ke versi 1.29.

Cluster yang terpengaruh akan otomatis terdeteksi oleh GKE dan tidak akan diupgrade otomatis ke versi 1.29 hingga sertifikat yang tidak kompatibel tidak lagi digunakan atau versi 1.28 mencapai akhir masa pakai. Setelah 1,28 mencapai akhir masa pakai, cluster akan diupgrade secara otomatis menjadi 1,29.

Algoritma penandatanganan yang kompatibel

GKE versi 1.29 kompatibel dengan algoritma yang didukung dalam paket Go x509. Hal ini mencakup algoritma berikut:

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

Untuk menemukan algoritma yang tersedia, lihat file sumber x509.go dan telusuri UnknownSignatureAlgorithm SignatureAlgorithm = iota. Algoritma yang didukung paket Go x509 tercantum dalam blok const dengan baris ini. Untuk menemukan algoritma penandatanganan tidak aman yang tidak didukung, telusuri penggunaan InsecureAlgorithmError dalam file.

Resource

Silakan melihat referensi berikut untuk mengetahui informasi tambahan tentang perubahan ini:

Catatan rilis Go 1.18
Go 1.24 Penghapusan tombol debug x509sha1
Algoritma yang didukung Go x509