גישה למאגרי מידע פרטיים באמצעות אישורי CA פרטיים

בדף הזה מוסבר איך לאפשר לעומסי עבודה שפועלים ב-Google Kubernetes Engine ‏ (GKE) לגשת למאגרי תמונות פרטיים באמצעות המפתח הציבורי של רשות האישורים (CA) שהנפיקה את האישור למאגר.

הדף הזה מיועד למומחי אבטחה שמנהלים את הגישה לעומסי העבודה של הארגון שלהם. כדי לקבל מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Google Cloud תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.

לפני שקוראים את הדף הזה, חשוב להכיר את Secret Manager.

איך ניגשים למאגרי מידע פרטיים

אתם מאחסנים את המפתח הציבורי של רשות האישורים שמשמשת להנפקת אישורים עבור רישומים פרטיים ב-Secret Manager, ומגדירים אילו שמות דומיין שמוגדרים במלואם (FQDN) של רישומים משתמשים במפתח הציבורי הזה לאימות אישורים. מערכת GKE מאחזרת את המפתח באופן אוטומטי ומעדכנת את הגדרת הרישום של זמן הריצה של הקונטיינר במהלך האתחול של הצומת. כשפורסים עומס עבודה שמשתמש בקובץ אימג' של קונטיינר ממאגר פרטי, השלבים הבאים מתבצעים:

  1. ה-kubelet בצומת מנסה לשלוף את התמונה ממאגר פרטי.
  2. הרישום מציג אישור TLS בצד השרת.
  3. זמן הריצה של המאגר מאמת את אישור הרישום באופן קריפטוגרפי כדי לוודא ששם הדומיין שמוגדר במלואו (FQDN) תואם למה שציינתם.
  4. אם האימות עובר בהצלחה, GKE מושך את התמונה ומתזמן את עומס העבודה.

יתרונות

השיטה הזו לגישה למאגרי מידע פרטיים מספקת יתרונות כמו:

  1. שיפור המהימנות של הגדרת זמן הריצה של מאגר התגים: שימוש בשיטות כמו DaemonSets להגדרת containerd מוסיף סיכון להתרחשות של מצב מירוץ, שבו יכול להיות ש-DaemonSets אחרים יפעלו לפני ה-DaemonSet של ההגדרה שלכם.
  2. הפחתת הפגיעות להתקפות של העלאת הרשאות: לא צריך יותר להפעיל DaemonSets עם הרשאות שמשנות את ההגדרה של זמן הריצה של הקונטיינר.
  3. צמצום התקורות של הניהול: בעזרת Secret Manager אפשר לאחסן מפתחות ציבוריים של רשויות אישורים במיקום מרכזי, לנהל את הגישה למפתחות באמצעות IAM ולהטמיע ניהול גרסאות והערות. מידע נוסף זמין במאמר סקירה כללית של Secret Manager.
  4. שיפור יכולת הביקורת: Cloud Logging כבר אוסף יומנים, כולל מקרים שבהם אישורים מתווספים לאשכול ומקרים שבהם צמתי GKE שולפים תמונות.

תמחור

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אתם יכולים להשתמש במחשבון התמחור.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

  • מפעילים את Secret Manager API, אם הוא עדיין לא מופעל.

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

  • כדי לגשת למאגר, צריך כבר להיות לכם מאגר פרטי ואישורי רשות אישורים פרטית (CA). במדריך הזה לא מוסבר איך להגדיר מרשם פרטי או ליצור אישורים.

דרישות

כדי להשתמש במפתחות ציבוריים של רשות אישורים פרטית כדי לגשת למאגרי מידע פרטיים, אתם צריכים לעמוד בדרישות הבאות:

  • האשכולות צריכים להשתמש ב-GKE מגרסה 1.27.3-gke.1700 ואילך.
  • צריך להשתמש בתמונת צומת של מערכת הפעלה שמותאמת לקונטיינרים עם containerd, שהיא ברירת המחדל לכל אשכולות GKE, או בתמונות צמתים של Ubuntu עם containerd בגרסה 1.33.0 ואילך. תמונות של צומתי Windows Server לא נתמכות.
  • למאגרי הצמתים צריך להיות היקף הגישה cloud-platform כדי שהצמתים יוכלו להוריד את האישורים. מידע נוסף זמין במאמר היקפי גישה שמוגדרים כברירת מחדל ב-GKE. במאמר הזה מוסבר איך מגדירים את היקף הגישה כשיוצרים אשכול או מאגר צמתים.

מגבלות

חשוב לזכור את המגבלות הבאות:

  • אם ל-GKE אין גישה לאישור CA במהלך תהליך האתחול של הצומת, הצומת יאותחל בלי אישור רשות האישורים הפרטית. עומסי עבודה בצומת הזה לא יכולים לגשת למאגר הפרטי. כדי לפתור את הבעיה, אפשר לעיין במאמר בנושא פתרון בעיות בזמן הריצה של מאגר התגים.
  • אי אפשר להשתמש באישורים של רשויות אישורים פרטיות בתמונות של צמתי Ubuntu עם גרסה מוקדמת יותר מ-1.33.0.
  • אי אפשר להשתמש באישורי CA פרטיים בצמתי Windows Server.
  • כל אשכול תומך בעד חמישה אישורי CA פרטיים עבור רישומים פרטיים.
  • כל אישור יכול לכלול עד 25 שמות דומיין שמוגדרים במלואם (FQDN).
  • אפשר להשתמש בכל דומיין רק בקובץ אישור אחד. עם זאת, יש תמיכה בחבילות אישורים.
  • האישורים צריכים להיות בקידוד PEM.
  • השרת לא מבצע רוטציה אוטומטית של האישורים. מידע נוסף זמין במאמר החלפת אישורי CA פרטיים.
  • יש כמה מגבלות ל-FQDN:
    • האורך המקסימלי של FQDN הוא 255 תווים, כולל תווים מיוחדים.
    • ב-FQDN אפשר להשתמש רק באותיות, במספרים ובמקפים (-).
    • אין תמיכה ב-Punycode.
    • אין תמיכה בתווים כלליים לחיפוש.

העברה מ-DaemonSets של הגדרות

באשכולות GKE Standard, אפשר לפרוס DaemonSets עם הרשאות כדי לשנות את הגדרות זמן הריצה של הקונטיינר. השיטה הזו משנה ישירות את ההגדרה של containerd בכל צומת.

אם אתם משתמשים ב-DaemonSets עם הרשאות מיוחדות כדי להגדיר גישה למאגרי רישום פרטיים, כדאי לקרוא את ההערות הבאות לפני שאתם משתמשים במסמך הזה:

  • שמירת מפתחות ציבוריים של רשות אישורים פרטית ב-Secret Manager מגדירה רק גישה למאגרי מידע פרטיים. אין תמיכה בהגדרות אחרות שקשורות לרישום.

  • הפעלת התכונה הזו גורמת לאשכול להשתמש במודל ההגדרה של CRI hostpath של containerd, שלא תואם למודל ההגדרה הקודם. אם יש לכם DaemonSets שמשנים את הגדרת המארח של containerd, למשל עבור רישומים פרטיים לא מאובטחים, מראות או שרתי proxy, צריך לעדכן את ה-DaemonSets כדי להשתמש במודל hostpath של CRI.

    למידע על השדות שזמינים במודל hostpath של CRI, אפשר לעיין במאמר Registry configuration (הגדרת מאגר) במאגר containerd ב-GitHub.

כשמפעילים את התכונה הזו, GKE מחיל את מודל ההגדרה של CRI hostpath על צמתים חדשים באשכול. צמתים קיימים ממשיכים להשתמש במודל ההגדרות הקודם עד שהם נוצרים מחדש במהלך אירועים כמו שדרוגים.

עדכון של DaemonSets כדי לתמוך בשני מודלים של הגדרות

כדי להקטין את הסיכון ש-DaemonSets של התצורה לא יפעלו בצמתים שתומכים במודל תצורה ספציפי, צריך לוודא ש-DaemonSets משתמשים באופן מותנה במודל תצורה ספציפי בהתאם לקובצי התצורה של containerd בצומת. דוגמה ל-DaemonSet שמיישם את הלוגיקה המותנית הזו מופיעה במאגר GoogleCloudPlatform/k8s-node-tools GitHub בקובץ insecure-registry-config.yaml manifest.

אחסון המפתחות הציבוריים של רשות האישורים ב-Secret Manager

מאחסנים את המפתחות הציבוריים של רשויות אישורים פרטיות שמנפיקות את האישורים של הרשומות הפרטיות שלכם כסודות ב-Secret Manager. הוראות מפורטות זמינות במאמר יצירת סוד במסמכי התיעוד של Secret Manager.

הגדרת גישה ל-Secret Manager מ-GKE

כדי לוודא שלחשבון השירות של IAM באשכול יש את ההרשאות הנדרשות לשליפת סודות מ-Secret Manager, צריך לבקש מהאדמין להקצות לחשבון השירות של IAM באשכול את תפקידי ה-IAM הבאים בסוד:

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

התפקידים המוגדרים מראש האלה מכילים את ההרשאות שנדרשות לשליפת סודות מ-Secret Manager. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

ההרשאות הנדרשות

כדי לשלוף סודות מ-Secret Manager, נדרשות ההרשאות הבאות:

  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • secretmanager.secrets.get
  • secretmanager.secrets.list
  • secretmanager.versions.get
  • secretmanager.versions.list
  • secretmanager.versions.access

יכול להיות שהאדמין יוכל גם להעניק לחשבון השירות של IAM באשכול את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

אם לא שייכתם חשבון שירות מותאם אישית של IAM לאשכול או למאגר הצמתים, שזו הגישה המומלצת שלנו, האשכול משתמש בחשבון השירות שמוגדר כברירת מחדל של Compute Engine.

אם אפשר, מומלץ להגדיר את האשכולות ואת מאגרי הצמתים באמצעות חשבון שירות IAM עם הרשאות מינימליות. הוראות מפורטות זמינות במאמר בנושא שימוש בחשבונות שירות עם הרשאות מינימליות.

יצירת קובץ תצורת זמן ריצה

כדי להשתמש באישור CA פרטי עבור רשומות פרטיות ב-GKE, צריך ליצור קובץ YAML כדי לשנות את ההגדרות של containerd.

  1. מציאת מספר הפרויקט ב- Google Cloud :

    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    הפלט הוא מספר הפרויקט.

  2. שומרים את ההגדרה הבאה בתור containerd-configuration.yaml. אפשר להשתמש בשדה registryHosts (מומלץ) או בשדה privateRegistryAccessConfig

registryHosts

registryHosts:
- server: "REGISTRY_SERVER_FQDN"
  hosts:
  - host: "MIRROR_FQDN"
    capabilities:
    - "HOST_CAPABILITY_PULL"
    - "HOST_CAPABILITY_RESOLVE"
    ca:
    - gcpSecretManagerSecretUri: "projects/PROJECT_ID_OR_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGISTRY_SERVER_FQDN: שם המארח של שרת הרישום. הערכים צריכים להיות שמות דומיין שמוגדרים במלואם או כתובות IPv4.
  • ‫MIRROR_FQDN: שם המארח של הרפליקה של המאגר. הערכים צריכים להיות שמות דומיין שמוגדרים במלואם או כתובות IPv4.
  • ‫PROJECT_ID_OR_NUMBER: מזהה הפרויקט או מספר הפרויקט שקיבלתם בשלב הקודם.
  • ‫SECRET_NAME: שם הסוד ב-Secret Manager.
  • ‫SECRET_VERSION: מספר הגרסה של הסוד ב-Secret Manager. אפשר גם להשתמש בכינוי לגרסה, אבל אנחנו ממליצים להשתמש במספר הגרסה כדי למנוע סיבוכים בניהול.

תיאור של השדות האלה מופיע בקטע registryHosts באפשרויות ההגדרה הזמינות של containerd.

privateRegistryAccessConfig

privateRegistryAccessConfig:
  certificateAuthorityDomainConfig:
  - gcpSecretManagerCertificateConfig:
      secretURI: "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION"
    fqdns:
      - "FQDN1"
      - "FQDN2"
  enabled: true

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_NUMBER: מספר הפרויקט שקיבלתם בשלב הקודם.
  • ‫SECRET_VERSION: מספר הגרסה של הסוד ב-Secret Manager. אפשר גם להשתמש בכינוי לגרסה, אבל אנחנו ממליצים להשתמש במספר הגרסה כדי למנוע סיבוכים בניהול.

  • ‫FQDN1, FQDN2: שמות הדומיין המלאים של הרשומות הפרטיות שלכם. אפשר גם להשתמש בכתובת IPv4 אם הונפק אישור לכתובת הזו, אבל אנחנו לא ממליצים על כך.

    תיאור של השדות האלה מופיע במאמר privateRegistryAccessConfig באפשרויות ההגדרה הזמינות של containerd.

החלת הגדרות containerd על אשכולות חדשים

בקטע הזה מוסבר איך להחיל קובץ הגדרה של containerd כשיוצרים אשכול GKE חדש.

מריצים את הפקודה הבאה כדי ליצור אשכולות של Autopilot:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --scopes="cloud-platform" \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_NAME: השם של האשכול החדש.
  • ‫LOCATION: המיקום של Compute Engine באשכול החדש.
  • ‫PATH_TO_CONFIG_FILE: הנתיב לקובץ התצורה שיצרתם, כמו ~/containerd-configuration.yaml.

כדי להפעיל את ההגדרה של containerd באשכולות רגילים חדשים, מריצים את הפקודה gcloud container clusters create עם אותן אפשרויות. אלא אם מציינים הגדרה אחרת של containerd, מאגרי צמתים חדשים שנוצרים באשכול מקבלים בירושה את הגדרת ברירת המחדל של containerd ברמת האשכול.

החלת הגדרות containerd על מאגרי צמתים חדשים

אפשר להחיל את ההגדרה של containerd על מאגר צמתים חדש של GKE באמצעות הפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --scopes="cloud-platform" \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש.
  • ‫CLUSTER_NAME: השם של האשכול הקיים.
  • ‫LOCATION: המיקום ב-Compute Engine של מאגר הצמתים החדש.
  • ‫PATH_TO_CONFIG_FILE: הנתיב לקובץ התצורה שיצרתם, כמו ~/containerd-configuration.yaml.

החלת ההגדרה של containerd על אשכולות קיימים

בקטע הזה מוסבר איך להחיל הגדרה של containerd על אשכולות וצמתים קיימים.

עדכון ההגדרה של containerd ברמת האשכול חל רק על מאגרי צמתים שלא מוגדרות להם הגדרות משלהם ברמת מאגר הצמתים (כמו registryHosts או writableCgroups). מערכת GKE יוצרת מחדש את הצמתים במאגרי הצמתים האלה כדי להחיל את ההגדרה החדשה. מאגרי צמתים עם הגדרות ברמת מאגר הצמתים ממשיכים להשתמש בהגדרה שלהם, והצמתים שלהם לא נוצרים מחדש. כשמעדכנים אשכול או מאגר צמתים עם הגדרת containerd, הצמתים נוצרים מחדש כדי להחיל את ההגדרה. יכול להיות שיהיו שיבושים זמניים בהרצת עומסי העבודה. ‫GKE יוצר מחדש צמתים רק אם מופעלים שדרוגים אוטומטיים. היצירה מחדש הזו מתבצעת בהתאם לחלונות הזמן לתחזוקה שהגדרתם. באשכולות רגילים שבהם לא מופעלים שדרוגים אוטומטיים, צריך ליצור מחדש את הצמתים באופן ידני כדי להחיל את ההגדרה.

בדיקת היקפי הגישה

אם קובץ התצורה שלכם משתמש בסודות מ-Secret Manager, צריך להגדיר את היקף הגישה cloud-platform באשכול או במאגר הצמתים. בקטע הזה מוסבר איך לבדוק את היקפי הגישה ואיך לעדכן קלאסטר קיים באמצעות קובץ חדש או מעודכן של הגדרות זמן ריצה.

פרטים על היקפי הגישה שמוגדרים כברירת מחדל באשכולות חדשים זמינים במאמר היקפי גישה ב-GKE.

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

מריצים את הפקודה הבאה:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=nodeConfig \
    --format='csv[delimiter="\\n",no-heading](oauthScopes)'

אם אתם משתמשים בסודות מ-Secret Manager ולצבירת המחשבים שלכם אין את היקף הגישה https://www.googleapis.com/auth/cloud-platform, אתם צריכים ליצור צבירת מחשבים חדשה עם היקף הגישה הזה.

בדיקה של היקפי גישה רגילים

כדי לבדוק את היקפי הגישה של אשכול רגיל, בודקים את מאגר הצמתים:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value[delimiter="\\n"](config.oauthScopes)'

מחליפים את NODE_POOL_NAME בשם של מאגר הצמתים.

אם אתם משתמשים בסודות מ-Secret Manager ולצביר שלכם אין את היקף הגישה https://www.googleapis.com/auth/cloud-platform, אתם צריכים ליצור מאגר צמתים חדש עם היקף הגישה cloud-platform ולמחוק את מאגר הצמתים הקיים.

עדכון האשכול לשימוש בקובץ התצורה

מריצים את הפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

עדכון מאגר צמתים לשימוש בקובץ תצורה

כדי לעדכן את התצורה של containerd עבור מאגר צמתים, מריצים את הפקודה הבאה:

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים לעדכן.
  • ‫CLUSTER_NAME: השם של האשכול הקיים.
  • ‫LOCATION: המיקום של האשכול ב-Compute Engine.
  • ‫PATH_TO_CONFIG_FILE: הנתיב לקובץ התצורה שיצרתם, כמו ~/containerd-configuration.yaml.

יצירה מחדש של צמתים באשכולות רגילים

אם באשכול Standard שלכם לא מופעלים שדרוגים אוטומטיים, אתם צריכים ליצור מחדש באופן ידני את מאגרי הצמתים כדי להחיל את ההגדרה החדשה. כדי להפעיל יצירה מחדש של צומת באופן ידני, משדרגים את האשכול לאותה גרסת GKE שבה הוא כבר משתמש.

gcloud container clusters upgrade CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION

מחליפים את VERSION באותה גרסת תיקון של GKE שבה האשכול כבר משתמש.

מוודאים שלקלאסטר יש גישה למאגר הפרטי

מריצים את הפקודה הבאה:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten="nodePoolDefaults.nodeConfigDefaults.containerdConfig"

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

registryHosts

containerdConfig:
  registryHosts:
  - server: example.io
    hosts:
    - host: example.mirror.io
      capabilities:
      - "HOST_CAPABILITY_PULL"
      - "HOST_CAPABILITY_RESOLVE"
      ca:
      - gcpSecretManagerSecretUri: projects/123456789012/secrets/example-secret-name/versions/1

privateRegistryAccessConfig

containerdConfig:
  privateRegistryAccessConfig:
    certificateAuthorityDomainConfig:
    - fqdns:
      - 203.0.113.105
      gcpSecretManagerCertificateConfig:
        secretUri: projects/123456789012/secrets/example-secret-name/versions/1
    enabled: true

פריסת עומס עבודה עם גישה לתמונה פרטית

בקטע הזה פורסים Pod סטטי שמפנה לתמונה מהמאגר הפרטי.

  1. שומרים את קובץ המניפסט הבא בשם private-registry-pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: private-registry-pod
spec:
  containers:
  - name: private-image
    image: IMAGE_NAME

    מחליפים את IMAGE_NAME בשם של קובץ האימג' הפרטי.

  2. פורסים את ה-Pod:

    kubectl create -f private-registry-pod.yaml

רוטציה של אישורי CA פרטיים

אי אפשר להגדיר ב-Secret Manager וב-GKE רוטציה אוטומטית של אישורי CA פרטיים ב-Secret Manager. כדי לבצע רוטציה של אישורים, פועלים לפי השלבים הבאים. כדי לבצע את השלבים האלה, צריך ליצור מחדש את הצמתים הקיימים פעמיים. מומלץ לבצע החלפות של אישורים במהלך השבתה מתוזמנת כדי למזער את ההשפעה של שיבושים בעומס העבודה.

  1. יוצרים חבילת אישורים בקידוד PEM שמכילה את האישורים הישנים והחדשים.
  2. הוספת החבילה כגרסה חדשה של סוד ב-Secret Manager
  3. מעדכנים את השדה secretURI בקובץ התצורה של זמן הריצה עם מספר הגרסה החדש של הסוד.
  4. מעדכנים את האשכול כדי להשתמש בגרסה החדשה של הסוד.

  5. קבלת חותמת הזמן של פעולת העדכון:

    gcloud container operations list \
    --filter="operationType ~ UPDATE_CLUSTER AND targetLink ~ CLUSTER_NAME" \
    --sort-by=startTime \
    --limit=1 \
    --format='value(endTime)'

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

    2024-01-31T09:27:30.864308964Z

  6. מחפשים צמתים שנוצרו לפני שפעולת העדכון הסתיימה:

    kubectl get nodes -o json | jq ".items[] |
select(.metadata.creationTimestamp | fromdateiso8601 < $(date -d
CLUSTER_UPDATE_TIMESTAMP +%s)) | .metadata.name"

    מחליפים את CLUSTER_UPDATE_TIMESTAMP בחותמת הזמן מהשלב הקודם.

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

  7. יוצרים גרסה חדשה של הסוד ב-Secret Manager עם האישור החדש בלבד.

  8. חוזרים על השלבים הקודמים כדי לעדכן את האשכול, לקבל את חותמת הזמן של הפעולה ולוודא שהצמתים משתמשים בגרסה החדשה של הסוד.

  9. מוחקים את הגרסה הישנה של הסוד מ-Secret Manager.

צפייה ביומני ביקורת ב-Logging

בקטע הזה נסביר איך להשתמש ב-Logging כדי לבדוק אם GKE התקין את גרסת הסוד בצמתים.

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

  1. נכנסים לדף Logs Explorer במסוף Google Cloud :

    כניסה לדף Logs Explorer

  2. חיפוש ביומני הנתונים באמצעות שאילתות ספציפיות:

registryHosts

מריצים שאילתה ביומנים עם המסנן הבא.

resource.type="gce_instance"
(textPayload:"Successfully fetched secret" OR textPayload:"error pulling certificate")

אם התקנת האישור הצליחה, תוכלו למצוא את רשומת היומן הבאה:

Successfully fetched secret "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION"
Successfully wrote secret payload for "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION"

אם התקנת האישור נכשלה, יכול להיות שתמצאו את רשומת היומן הבאה:

User error pulling certificate "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION" from GSM: ...
Or
Internal error pulling certificate "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION" from GSM: ....

privateRegistryAccessConfig

מריצים שאילתה ביומנים עם המסנן הבא.

resource.type="gce_instance"
textPayload:"Installed certificate \\\"projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION\\\""

אם התקנתם את האישור בהצלחה, הפלט ייראה כך:

"Installed certificate "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION""

אם התקנת האישור נכשלה, הפלט דומה לזה:

"Failed to install certificate "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION""

שיטות מומלצות

מומלץ לפעול לפי השיטות המומלצות הבאות כשמשתמשים בתכונה הזו:

  • אל תשתמשו בשמות בדויים לגרסאות של סודות ב-Secret Manager. משתמשים במספר הגרסה שנוצר אוטומטית לכל גרסת סוד. כינוי יכול להצביע על גרסה אחרת של אישור לאורך זמן, מה שיכול לגרום למורכבות במעקב אחר הגרסאות הספציפיות שבהן נעשה שימוש בעומסי העבודה.
  • כדי לשלוט במועד שבו GKE יכול ליצור מחדש את הצמתים כדי להחיל עדכונים של הגדרות containerd, אפשר להשתמש בחלונות תחזוקה ובאי הכללות.
  • צריך לספק גישה לסודות ברמת הסוד, ולא ברמת הפרויקט.

השבתת אפשרויות ההגדרה של containerd

השבת את privateRegistryAccessConfig

  1. מעדכנים את קובץ ההגדרות כדי לציין enabled: false ב-privateRegistryAccessConfig ומסירים את כל השדות האחרים בפריט, כמו בדוגמה הבאה:

    privateRegistryAccessConfig:
  enabled: false
  2. מחילים את קובץ התצורה המעודכן על האשכול. הוראות מפורטות זמינות במאמר בנושא החלת הגדרת containerd על אשכולות קיימים.

השבת את registryHosts

  1. מעדכנים את קובץ התצורה כדי לציין מערך ריק בפריט registryHosts, כמו בדוגמה הבאה:

    registryHosts: []
  2. מחילים את קובץ התצורה המעודכן על האשכול. הוראות מפורטות זמינות במאמר בנושא החלת הגדרת containerd על אשכולות קיימים.

פתרון בעיות

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