Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

איך מוודאים תאימות של אישורי TLS לפני שמשדרגים ל-GKE 1.29

טייס אוטומטי רגילה

אשכולות GKE שמופעלת בהם גרסה 1.29 ואילך לא תומכים באישורים של Transport Layer Security ‏ (TLS) שנחתמו באמצעות אלגוריתם SHA-1. כדי למנוע השפעה על האשכולות, צריך להחליף את האישורים הלא תואמים של webhook ושל שרת ה-API של התוסף בשרתי קצה עורפיים (backend) באישורים שמשתמשים באלגוריתמים תואמים לחתימה לפני שמשדרגים את האשכולות לגרסה 1.29.

ההשפעה על אשכולות של ההסרה הזו

‫GKE משהה שדרוגים אוטומטיים כשהוא מזהה שאשכול משתמש באישורים שלא תואמים לגרסה 1.29. אחרי שתחליפו את האישורים באישורים שמשתמשים באלגוריתמי חתימה תואמים, או אחרי שגרסה 1.28 תגיע לסוף התמיכה, GKE ימשיך בשדרוגים אוטומטיים.

אם לא תחליפו את האישורים הלא תואמים לפני השדרוג לגרסה 1.29, יכול להיות שתיתקלו בבעיות הבאות באשכולות:

בקצה העורפי של ה-webhook ב-GKE נעשה שימוש באישור TLS שנחתם באמצעות אלגוריתם SHA-1, ולכן הוא יפסיק לפעול בגלל כשל באימות. קריאות ל-Webhook ייכשלו במישור הבקרה של Kubernetes שמתקשר עם ה-Webhooks שלכם באמצעות אישורים לא תואמים. בהתאם להגדרה שלכם, במיוחד אם אתם משתמשים ב-webhooks של הרשאות, יכול להיות שאם לא תצליחו ליצור קשר עם webhook, תיחסם יצירת משאבים באשכול שלכם, כמו יצירת Pod, וזה עלול לשבש את הפעילות.
קריאות ל-API שמוגשות על ידי שרתי ה-API של התוסף ייכשלו.

למה ב-Kubernetes מסירים את היכולת הזו

‫GKE מפעיל Kubernetes בקוד פתוח, שמשתמש ברכיב kube-apiserver כדי ליצור קשר עם קצה העורפי של שרת ה-API של ה-webhook והתוסף באמצעות TLS. הרכיב kube-apiserver כתוב בשפת התכנות Go.

החל מגרסה 1.18 של Go, המערכת התחילה לדחות אישורי TLS שנחתמו באמצעות אלגוריתם SHA-1, אבל השאירה מתג לניפוי באגים x509sha1=1 כדי לאפשר את ההתנהגות הישנה ולהקל על תהליך ההעברה. גרסה 1.24 של GKE הייתה הגרסה הראשונה שנבנתה באמצעות גרסה 1.18 של Go. בגרסאות של Kubernetes ב-GKE, האפשרות הזו לניפוי באגים הייתה מופעלת עד גרסה 1.29. ההחלפה תבוטל בגרסה Go 1.24. גרסאות build של GKE 1.29 מבוססות על Kubernetes עם השבתת המתג, כהכנה להסרה עתידית של המתג debug ב-Go. אחרי ש-GKE ישדרג את האשכולות לגרסה 1.29, קריאות ממישור הבקרה של האשכול לשרתי webhook או לשרתי extension API באשכול שמספקים אישור TLS שנחתם באמצעות אלגוריתם SHA-1 ייכשלו.

זיהוי אשכולות מושפעים

‫GKE מנטר את האשכולות ומשתמש בשירות ההמלצות כדי לספק הנחיות באמצעות תובנות והמלצות שמזהות אשכולות עם קצה עורפי של שרת webhook או API של תוסף שמשתמשים באישור TLS שנחתם באמצעות אלגוריתם SHA-1. אפשר גם להשתמש ביומנים כדי לזהות קריאות לשרתי קצה מושפעים מהאשכול.

איך מקבלים תובנות והמלצות

לגבי אשכולות עם גרסה 1.24 ואילך, פועלים לפי ההוראות להצגת תובנות והמלצות. אפשר לקבל תובנות באמצעות ה-CLI של gcloud או Recommender API, ולסנן לפי סוג המשנה DEPRECATION_K8S_SHA_1_CERTIFICATE.

איך מקבלים יומנים

באשכולות שמופעלת בהם גרסה 1.24 ואילך עם Cloud Logging מופעל,‏ GKE מספק יומן של יומני ביקורת של Cloud כדי לזהות קריאות לשרתי קצה מושפעים מהאשכול. כדי לחפש את היומנים, אפשר להשתמש במסנן הבא:

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

יומני הביקורת כוללים את שם המארח של העורף המושפע. בקטע הבא מוסבר איך לפרש את התוצאות.

הסבר על ההדרכה שמופיעה בתובנות ובהמלצות

ההמלצה כוללת את שם המארח של הבק-אנד המושפע, וגם אם מדובר בשרת webhook או בשרת extension API. שמות המארחים שמפנים לשירותים באשכול הם בפורמט <service-name>.<namespace>.svc.

אם האישור של הקצה העורפי שמושפע הוא משרת webhook, שם המארח יכול להיות שירות באשכול או כתובת URL. מידע נוסף זמין במאמר בנושא יצירת קשר עם webhook.

אם האישור המושפע הוא משרת API של תוסף, שם המארח הוא Service באשכול. מידע נוסף זמין במאמר בנושא יצירת קשר עם שרת ה-API של התוסף.

אחרי שמזהים את ה-backend המושפע, פועלים לפי ההוראות לבדיקת האישור של שירות או לבדיקת האישור של backend של כתובת URL, בהתאם לסוג.

אם באשכולות שלכם לא בוצעו קריאות לשרתים עם אישורים מושפעים ב-30 הימים האחרונים, לא יוצגו המלצות.

דוגמאות להמלצות

הנה רשימה לדוגמה של המלצות:

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

כדי לקבל פרטים על האשכול והשירות, מתארים את ההמלצה. הפלט של שירות בשם example-webhook במרחב השמות default דומה לזה:

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>

בדיקת האישור של שירות

אפשר לגבות את השרתים של ה-API של התוסף ושל ה-webhook באמצעות שירותים.

אחרי שמזהים את השירותים הרלוונטיים לקצה העורפי שצריך לבדוק, משתמשים בהוראות הבאות כדי לבדוק את האישור של כל שירות ולראות אילו אישורים משתמשים באלגוריתם SHA-1 וצריך לעדכן אותם.

מוצאים את הסלקטור ואת יעד ההעברה של השירות:
```
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
```
מחליפים את NAMESPACE ואת SERVICE_NAME בערכים מ-targetValue.

הפלט אמור להיראות כך:
```
Name: example-service
Namespace: default
Labels: run=nginx
Selector: run=nginx
Type: ClusterIP
IP: 172.21.xxx.xxx
Port: 443
TargetPort: 444
```
הפלט הזה מציין של-example-service יש את בורר היציאות run=nginx ואת יציאת היעד 444.

הערה: אם לא מציינים את TargetPort, הערך שלו זהה לערך של השדה Port.

חיפוש של Pod שתואם לסלקטור:

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

הפלט אמור להיראות כך:

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

הפלט הזה מציין שה-Pod התואם הוא example-pod.

מגדירים העברה ליציאה אחרת מ-kubectl localhost אל ה-Pod:

הערה: בפקודות הבאות נעשה שימוש ביציאה 8888, אבל אפשר לבחור יציאה אחרת כי היציאה הזו נבחרה באופן שרירותי.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
מחליפים את SERVICE_TARGET_PORT בערך TargetPort מהשירות. אם לא מציינים את הערך TargetPort, המערכת תשתמש בערך Port.
כדי להציג את האישור שבו השירות משתמש, מריצים את הפקודה openssl:
```
openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
```
בדוגמה הזו מוצג פלט של אישור תקין שנחתם באמצעות אלגוריתם SHA-256:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
```
בדוגמה הזו של פלט מוצג אישור לא תקין שנחתם באמצעות האלגוריתם SHA-1:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
אם הפלט מהאישור דומה, צריך לעדכן את האישור כדי להשתמש באלגוריתם חתימה תואם. לדוגמה, אם אתם משתמשים ב-certificate.k8s.io API כדי לנהל אישורי TLS באשכול שלכם, אתם יכולים לפעול לפי ההוראות כדי ליצור בקשה לחתימה על אישור.

ניקוי העברה ליציאה אחרת

כדי לנקות את העברת היציאות שפועלת ברקע, צריך למצוא את התהליך ולסיים אותו.

מריצים את הפקודה הבאה כדי להציג את התהליכים הפעילים:
```
jobs
```
בודקים את הפלט כדי לקבל את המזהה של התהליך שרוצים להפסיק:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
פלט לדוגמה שמציין שמזהה התהליך הוא 1.
מפסיקים את התהליך ומחליפים את PROCESS_ID:
```
kill %PROCESS_ID
```
הפלט הבא אמור להתקבל:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
בדוגמה הזו של הפלט אפשר לראות שהתהליך הסתיים.

בדיקת האישור של כתובת URL של קצה עורפי

אם ה-webhook משתמש בקצה העורפי url, מתחברים ישירות לשם המארח שצוין בכתובת ה-URL. לדוגמה, אם כתובת ה-URL היא https://example.com:123/foo/bar, משתמשים בפקודה openssl הבאה כדי להציג את האישור שבו ה-Backend משתמש:

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

בדוגמה הזו מוצג פלט של אישור תקין שנחתם באמצעות אלגוריתם SHA-256:

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

בדוגמה הזו של פלט מוצג אישור לא תקין שנחתם באמצעות האלגוריתם SHA-1:

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

אם הפלט מהאישור דומה, צריך לעדכן את האישור כדי להשתמש באלגוריתם חתימה תואם. לדוגמה, אם אתם משתמשים ב-certificate.k8s.io API כדי לנהל אישורי TLS באשכול שלכם, אתם יכולים לפעול לפי ההוראות כדי ליצור בקשה לחתימה על אישור.

צמצום הסיכון בשדרוג לגרסה 1.29

אחרי שמזהים את האשכולות המושפעים ואת שירותי הקצה העורפי שלהם באמצעות אישורים שנחתמו באלגוריתם SHA-1, צריך לעדכן את השירותים כך שישתמשו באישורים עם אלגוריתמים תואמים לחתימה לפני שמשדרגים את האשכולות לגרסה 1.29.

מערכת GKE מזהה אוטומטית את האשכולות המושפעים, ולא תשדרג אותם אוטומטית לגרסה 1.29 עד שהשימוש באישורים לא תואמים יופסק או עד שגרסה 1.28 תגיע לסוף תקופת התמיכה. אחרי שהתמיכה בגרסה 1.28 תסתיים, האשכולות ישודרגו אוטומטית לגרסה 1.29.

אלגוריתמים תואמים לחתימה

גרסה 1.29 של GKE תואמת לאלגוריתמים נתמכים בחבילת Go x509. האלגוריתמים האלה כוללים את:

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

כדי למצוא את האלגוריתמים הזמינים, אפשר לעיין בקובץ המקור x509.go ולחפש את UnknownSignatureAlgorithm SignatureAlgorithm = iota. האלגוריתמים שחבילת Go x509 תומכת בהם מפורטים בבלוק const עם השורה הזו. כדי למצוא אלגוריתמים לא מאובטחים ולא נתמכים לחתימה, מחפשים את השימוש ב-InsecureAlgorithmError בקובץ.

משאבים

למידע נוסף על השינוי הזה, כדאי לעיין במקורות המידע הבאים: