Halaman ini diterjemahkan oleh Cloud Translation API.

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 Transport Layer Security (TLS) yang ditandatangani dengan algoritma SHA-1. Untuk mencegah dampak pada cluster, Anda perlu mengganti sertifikat yang tidak kompatibel dari backend webhook dan server API ekstensi dengan sertifikat yang menggunakan algoritma penandatanganan yang kompatibel sebelum mengupgrade cluster ke versi 1.29.

Dampak penghapusan ini terhadap cluster

GKE menjeda upgrade otomatis saat mendeteksi bahwa cluster menggunakan sertifikat yang tidak kompatibel dengan versi 1.29. Setelah Anda mengganti sertifikat dengan sertifikat yang menggunakan algoritma penandatanganan yang kompatibel, atau versi 1.28 mencapai akhir dukungan, 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 panel kontrol Kubernetes yang berkomunikasi dengan webhook Anda dengan sertifikat yang tidak kompatibel. Bergantung pada konfigurasi Anda, terutama jika Anda menggunakan webhook akses, kegagalan untuk menghubungi webhook dapat memblokir pembuatan resource di cluster, seperti pembuatan Pod, yang dapat sangat mengganggu.
Panggilan ke API yang ditayangkan oleh server API ekstensi akan gagal.

Alasan Kubernetes menghapus kemampuan ini

GKE mengoperasikan Kubernetes open source, yang menggunakan komponen kube-apiserver untuk menghubungi webhook dan backend server API ekstensi 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 membiarkan 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 tombol debug ini hingga versi 1.29. Tombol ini akan dihapus di Go 1.24. GKE 1.29 mem-build Kubernetes dengan tombol dinonaktifkan untuk mempersiapkan penghapusan tombol debug Go pada masa mendatang. Setelah GKE mengupgrade cluster Anda ke versi 1.29, panggilan dari panel kontrol cluster ke webhook atau server API ekstensi dalam cluster yang memberikan sertifikat TLS yang ditandatangani dengan algoritma SHA-1 akan gagal.

Mengidentifikasi cluster yang terpengaruh

GKE memantau cluster Anda dan menggunakan layanan Recommender untuk memberikan panduan melalui insight dan rekomendasi yang mengidentifikasi cluster yang memiliki backend server API webhook atau ekstensi 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 bisa mendapatkan insight menggunakan gcloud CLI, atau Recommender API, dengan memfilter subjenis DEPRECATION_K8S_SHA_1_CERTIFICATE.

Cara mendapatkan log

Untuk cluster yang menjalankan 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 menelusuri 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 hasilnya, lihat bagian berikutnya.

Menafsirkan panduan dari insight dan rekomendasi

Rekomendasi mencakup nama host backend yang terpengaruh, dan apakah webhook atau server API ekstensi. Nama host yang merujuk ke Layanan dalam cluster 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 di cluster. Untuk mempelajari lebih lanjut, lihat Menghubungi API server ekstensi.

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

Jika cluster Anda 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 rekomendasi. Output untuk Layanan bernama example-webhook di namespace default mirip dengan hal berikut:

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 Layanan

Server webhook dan 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 target port 444.

Catatan: Jika tidak disertakan, TargetPort memiliki nilai yang 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 yang berbeda, karena port ini dipilih secara arbitrer.
```
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 yang tidak valid dan ditandatangani dengan algoritma SHA-1:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
Jika output dari sertifikat serupa, Anda harus mengupdate sertifikat untuk 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, temukan prosesnya dan hentikan.

Jalankan perintah berikut untuk membuat daftar 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 prosesnya adalah 1.
Akhiri proses, ganti 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 dalam 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 yang tidak valid dan ditandatangani dengan algoritma SHA-1:

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

Jika output dari sertifikat serupa, Anda harus mengupdate sertifikat untuk 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.

Memitigasi risiko upgrade ke 1.29

Setelah mengidentifikasi cluster yang terpengaruh dan Layanan backend-nya yang menggunakan sertifikat yang ditandatangani dengan algoritma SHA-1, Anda harus mengupdate Layanan untuk 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 secara otomatis ke versi 1.29 hingga sertifikat yang tidak kompatibel tidak lagi digunakan atau versi 1.28 mencapai akhir dukungan. Setelah 1.28 mencapai akhir dukungan, cluster akan otomatis diupgrade ke 1.29.

Algoritma penandatanganan yang kompatibel

GKE versi 1.29 kompatibel dengan algoritma yang didukung dalam paket x509 Go. 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 x509 Go 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