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 Transportation Layer Security (TLS) yang ditandatangani dengan algoritma SHA-1. Untuk mencegah dampak pada cluster, Anda harus 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 pada 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 Anda 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 menggunakan sertifikat yang tidak kompatibel. Bergantung pada konfigurasi Anda, terutama jika Anda menggunakan webhook penerimaan, kegagalan untuk menghubungi webhook dapat memblokir pembuatan resource di cluster Anda, 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.

Mulai 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 dibangun menggunakan Go versi 1.18. Build Kubernetes GKE telah mengaktifkan tombol debug ini hingga versi 1.29. Tombol ini akan dihapus di Go 1.24. GKE 1.29 membangun Kubernetes dengan tombol yang dinonaktifkan untuk bersiap menghadapi penghapusan tombol debug Go pada masa mendatang. 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.

Mengidentifikasi cluster yang terpengaruh

GKE memantau cluster Anda dan menggunakan layanan Pemberi rekomendasi 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 mencakup 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 backend tersebut adalah server API ekstensi atau webhook. Nama host yang merujuk ke Layanan di cluster mengikuti format <service-name>.<namespace>.svc.

Jika sertifikat backend yang terpengaruh berasal dari server webhook, nama host dapat berupa Service 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 apiserver ekstensi.

Setelah 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 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 Layanan

Webhook dan server API ekstensi dapat didukung oleh Layanan.

Setelah 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, nilainya 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 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 memperbarui sertifikat untuk menggunakan algoritma penandatanganan yang kompatibel. Misalnya, jika Anda 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 mencantumkan proses yang sedang berjalan:
```
jobs
```
Lihat output untuk mendapatkan ID proses yang akan dihentikan:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Output contoh ini menunjukkan bahwa ID prosesnya adalah 1.
Hentikan proses, ganti PROCESS_ID:
```
kill %PROCESS_ID
```
Lihat output berikut:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
Output contoh 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 memperbarui sertifikat untuk menggunakan algoritma penandatanganan yang kompatibel. Misalnya, jika Anda 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 memperbarui Layanan tersebut agar menggunakan sertifikat dengan algoritma penandatanganan yang kompatibel sebelum mengupgrade cluster ke versi 1.29.

Cluster yang terpengaruh akan otomatis dideteksi 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 dukungan. Setelah 1.28 mencapai akhir dukungan, cluster akan diupgrade secara otomatis 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 oleh 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
Penghapusan x509sha1 debug switch Go 1.24
Algoritma yang didukung x509