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

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

הדף הזה מיועד למומחי אבטחה שמנהלים את הגישה לעומסי העבודה של הארגון שלהם. כדי לקבל מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Cloud de Confiance by S3NS תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשים ב-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 שולפים תמונות.

תמחור

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

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

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

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

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

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

• מפעילים את Secret Manager API.

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

  כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של שימוש בשירות' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

  להפעלת ה-API

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

דרישות

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

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

מגבלות

כדאי להביא בחשבון את המגבלות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• גישה לתוכן של סוד: Secret Manager Secret Accessor (roles/secretmanager.secretAccessor)
• גישה למטא-נתונים של סודות: צפייה ב-Secret Manager (roles/secretmanager.viewer)

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

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

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

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

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

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

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

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

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

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

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

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"

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

החלת ההגדרות של 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 יוצר מחדש צמתים רק אם מופעלים שדרוגים אוטומטיים. היצירה מחדש מתבצעת בהתאם לחלונות הזמן לתחזוקה שהגדרתם. ב-Standard clusters שבהם לא מופעלים שדרוגים אוטומטיים, צריך ליצור מחדש את הצמתים באופן ידני כדי להחיל את ההגדרה.

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

אם קובץ ההגדרות שלכם משתמש בסודות מ-Secret Manager, ל-cluster או למאגר הצמתים שלכם צריכה להיות הרשאת הגישה 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, אתם צריכים ליצור צומת חדש עם היקף הגישה הזה.

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

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

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"

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

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

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 במסוף Cloud de Confiance :

   כניסה לדף Logs Explorer

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

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

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 על אשכולות קיימים.

פתרון בעיות

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