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

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

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

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

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

  • בקצה העורפי של GKE webhook שמשתמש באישור TLS שנחתם באמצעות אלגוריתם SHA-1, תהיה הפסקה בפעולה בגלל כשל באימות. קריאות ל-Webhook ייכשלו במישור הבקרה של Kubernetes שמתקשר עם ה-Webhook שלכם באמצעות אישורים לא תואמים. בהתאם להגדרה שלכם, במיוחד אם אתם משתמשים ב-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. גרסאות 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"

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

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

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

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

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

אחרי שמזהים את העורף המושפע, פועלים לפי ההוראות לבדיקת האישור של שירות או לבדיקת האישור של עורף מסוג כתובת 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://docs.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://docs.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://docs.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>

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

גם שרתי webhook וגם שרתי extension API יכולים להיות מגובים על ידי שירותים.

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

  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.

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

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

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

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

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

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

    kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &

    מחליפים את SERVICE_TARGET_PORT בערך TargetPort מהשירות. אם לא מציינים את TargetPort, משתמשים בערך Port.

  4. משתמשים בפקודה 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 באשכול שלכם, אתם יכולים לפעול לפי ההוראות כדי ליצור בקשה לחתימה על אישור.

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

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

  1. מריצים את הפקודה הבאה כדי להציג את התהליכים הפעילים:

    jobs

    בודקים את הפלט כדי לקבל את המזהה של התהליך שרוצים להפסיק:

    [1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &

    פלט לדוגמה שמציין שמזהה התהליך הוא 1.

  2. מפסיקים את התהליך ומחליפים את 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 בקובץ.

משאבים

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