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

אפשר להגדיר את אשכול Google Distributed Cloud כך שצמתי העובדים שלו יוכלו להשתמש במאגרי רישום פרטיים, כולל Artifact Registry. מאגרי רישום פרטיים ברמת הצומת מיועדים לשימוש עם עומסי העבודה שלכם, כדי לתת לכם יותר שליטה בהורדות של תמונות ובאבטחה שקשורה אליהן. כשמגדירים אשכול עם רישומים פרטיים כמו שמתואר במסמך הזה, Google Distributed Cloud מעדכן את ההגדרה של containerd בהתאם. אחרי שמגדירים את האשכול, כל ה-Pods בצמתים שעומדים בדרישות יכולים להשתמש במאגרי הרישום בלי לציין את imagePullSecrets במפרט ה-Pod.

אפשר להפעיל או להשבית את התכונה הזו בכל שלב במחזור החיים של האשכול.

הרשימה הבאה מציגה את שלב ההשקה של התכונה הזו בכל גרסה:

דרישות מוקדמות

‫1.30 ואילך

כדי להשתמש בתכונה הזו של GA, האשכול שלכם צריך לעמוד בדרישות הבאות:

  • גרסת האשכול צריכה להיות 1.30 ואילך.
  • גרסת מאגר הצמתים צריכה להיות 1.29 ומעלה (באשכול בגרסה 1.30 יכולים להיות מאגרי צמתים בגרסה 1.28, אבל התכונה פועלת רק במאגרי צמתים בגרסה 1.29 ומעלה).
  • התכונה הזו מיועדת לאשכולות משתמשים ולאשכולות בניהול עצמי (היברידיים ועצמאיים) עם מאגרי צמתי עובדים, כמו שמוצג בטבלה הבאה:

    מודל הפריסה סוגי אשכולות נתמכים
    פריסת אשכולות של אדמינים ומשתמשים

    קלאסטר אדמין

    קבוצת משתמשים 1

    קבוצת משתמשים 2

    פריסת אשכול היברידי

    אשכול היברידי

    קבוצת משתמשים 1

    קבוצת משתמשים 2

    פריסת אשכול עצמאי

    Standalone cluster

1.29

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

  • גרסת האשכול חייבת להיות 1.29.
  • גרסת מאגר הצמתים צריכה להיות 1.29 (לא כל מאגרי הצמתים צריכים להיות בגרסה 1.29, אבל התכונה פועלת רק במאגרי צמתים בגרסה 1.29).
  • לצביר חייבת להיות הערת התכונה preview.baremetal.cluster.gke.io/private-registry: "enable" preview.
  • התכונה הזו מיועדת לאשכולות משתמשים ולאשכולות בניהול עצמי (היברידיים ועצמאיים) עם מאגרי צמתי עובדים, כמו שמוצג בטבלה הבאה:

    מודל הפריסה סוגי אשכולות נתמכים
    פריסת אשכולות של אדמינים ומשתמשים

    קלאסטר אדמין

    קבוצת משתמשים 1

    קבוצת משתמשים 2

    פריסת אשכול היברידי

    אשכול היברידי

    קבוצת משתמשים 1

    קבוצת משתמשים 2

    פריסת אשכול עצמאי

    Standalone cluster

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

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

  1. עורכים את קובץ התצורה של האשכול כדי להוסיף את הבלוק privateRegistries בקטע credentials:

    ---
    gcrKeyPath: baremetal/gcr.json
    sshPrivateKeyPath: .ssh/id_rsa
    ...
    privateRegistries:
      - host: REGISTRY_HOST
        caCertPath: CA_CERT_PATH
        pullCredentialConfigPath: CREDENTIALS_FILE_PATH
    ...
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-hybrid-basic
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: hybrid-basic
      namespace: cluster-hybrid-basic
      annotations:
        preview.baremetal.cluster.gke.io/private-registry: "enable" # Version 1.29 clusters only
        ...
    spec:
      type: hybrid
      ...
    

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

    • ‫REGISTRY_HOST: שם הדומיין או כתובת ה-IP של הרישום הפרטי והיציאה. לדוגמה: 10.200.0.2:5007.

    • ‫CA_CERT_PATH: הנתיב של קובץ אישור ה-CA (ה-CA הבסיסי של השרת). לדוגמה: /root/cert.pem. אם הרישום הפרטי שלכם לא דורש אישור TLS פרטי, אתם יכולים להשמיט את השדה הזה.

    • ‫CREDENTIALS_FILE_PATH: הנתיב של קובץ התצורה, config.json (לדוגמה, $HOME/.docker/config.json). כדי לאמת את containerd לצורך גישה למאגר הפרטי, config.json צריך להכיל גרסה בקידוד base64 של פרטי הכניסה בקטע auths של הקובץ.

      ב-Artifact Registry, מבצעים אימות באמצעות מפתח JSON של חשבון שירות עם הערכים הבאים:

      • username: _json_key
      • ‫password: כל התוכן של קובץ מפתח ה-JSON של חשבון השירות. כדי למנוע שגיאות בניתוח, צריך להוסיף מרכאות בודדות (') לתוכן של מפתח ה-JSON שהדבקתם.

      מידע נוסף על יצירת הקובץ הזה מופיע במאמר הגדרת אימות ל-Artifact Registry עבור Docker במסמכי התיעוד של Artifact Registry.

      במאגרי רישום פרטיים אחרים, מחרוזת auth בקידוד Base64 נוצרת בדרך כלל מ-USERNAME:PASSWORD, באמצעות פרטי הכניסה הספציפיים שלכם למאגר הרישום. אם שרת הרישום הפרטי שלכם לא דורש פרטי כניסה לאימות, אפשר להשמיט את השדה pullCredentialConfigPath.

      כדי להגן על מידע רגיש, אפשר להשתמש ב-chown וב-chmod כדי להגביל את הגישה לקובץ ההגדרות.

  2. מחילים את השינויים על האשכול:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG
    

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

    • ‫CLUSTER_NAME: השם של האשכול שרוצים לעדכן.

    • ‫CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של האשכול בניהול עצמי (היברידי או עצמאי).

הגדרת אשכול משתמשים למאגרי מידע פרטיים

כשמשתמשים באשכולות משתמשים, הגדרת הרישום הפרטי מצוינת במפרט של משאב אשכול המשתמש, שנמצא באשכול האדמין. בנוסף, צריך לאחסן את פרטי הכניסה של המאגר הפרטי ב-Secret, שנמצא גם הוא באשכול הניהול:

  1. יוצרים סוד Kubernetes מסוג kubernetes.io/dockerconfigjson עבור פרטי הכניסה של המאגר:

    אם רוצים להגדיר את הסוד למרחב שמות ספציפי, מוסיפים את הדגל --namespace לפקודה הבאה כדי לציין את שם מרחב השמות. אם הסוד לא נמצא באותו מרחב שמות כמו האשכול, מוסיפים את ההערה baremetal.cluster.gke.io/mark-source: "true", כמו שמוצג בדוגמה בסוף השלב הזה.

    kubectl create secret docker-registry CREDS_SECRET_NAME \
        --from-file=.dockerconfigjson=CREDENTIALS_FILE_PATH \
        --kubeconfig=ADMIN_KUBECONFIG
    

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

    • ‫CREDS_SECRET_NAME: השם של הסוד.

    • ‫CREDENTIALS_FILE_PATH: הנתיב של קובץ התצורה, config.json (לדוגמה, $HOME/.docker/config.json). כדי לאמת את containerd לצורך גישה למאגר הפרטי, config.json צריך להכיל גרסה בקידוד base64 של פרטי הכניסה בקטע auths של הקובץ.

      ב-Artifact Registry, מבצעים אימות באמצעות מפתח JSON של חשבון שירות עם הערכים הבאים:

      • username: _json_key
      • ‫password: כל התוכן של קובץ מפתח ה-JSON של חשבון השירות. כדי למנוע שגיאות בניתוח, צריך להוסיף מרכאות בודדות (') לתוכן של מפתח ה-JSON שהדבקתם.

      מידע נוסף על יצירת הקובץ הזה מופיע במאמר הגדרת אימות ל-Artifact Registry עבור Docker במסמכי התיעוד של Artifact Registry.

      במאגרי רישום פרטיים אחרים, מחרוזת auth בקידוד Base64 נוצרת בדרך כלל מ-USERNAME:PASSWORD, באמצעות פרטי הכניסה הספציפיים שלכם למאגר הרישום. אם שרת הרישום הפרטי שלכם לא דורש פרטי כניסה לאימות, אפשר להשמיט את השדה pullCredentialSecretRef.

      כדי להגן על מידע רגיש, אפשר להשתמש ב-chown וב-chmod כדי להגביל את הגישה לקובץ ההגדרות.

    הסוד שלכם אמור להיראות בערך כמו בדוגמה הבאה:

    apiVersion: v1
    data:
      .dockerconfigjson: ewoJImF1dGhzIjogewoJ...clpYSXdNak14IgoJCX0KCX0KfQ==
    kind: Secret
    metadata:
      creationTimestamp: "2024-04-28T22:06:06Z"
      name: private-registry-secret
      namespace: default
      resourceVersion: "5055821"
      ...
      annotations:
        ...
        baremetal.cluster.gke.io/mark-source: "true"
    type: kubernetes.io/dockerconfigjson
    
  2. אם רלוונטי, מאחסנים את אישור ה-CA עבור הרישום ב-Secret.

    הסוד אמור להיראות כך:

    apiVersion: v1
    kind: Secret
    metadata:
      annotations:
        baremetal.cluster.gke.io/mark-source: "true"
      name: ca-9dd74fd308bac6df562c7a7b220590b5
      namespace: some-namespace
    type: Opaque
    data:
      ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2RENDQXFTZ0F3SUJBZ0lVQi
      3UGxjUzVFVk8vS0xuYjZiMHRhRFVleXJvd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2ZqRUxNQWtHQ
      ...
      QnpPTkxTRFZJVk5LMm9YV1JvNEpJY0ZoNFZ4MWRMRHpqMldEaHhrUEljWEhLdGR3dk5iS2tocU
      LUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
      ```
    
  3. עורכים את קובץ התצורה של אשכול המשתמשים כדי להפעיל ולהגדיר את המאגר הפרטי:

    1. רק באשכולות מגרסה 1.29, מוסיפים את הערת התכונה Preview ‏preview.baremetal.cluster.gke.io/private-registry: "enable" כדי להפעיל את התכונה. בגרסה 1.30 ואילך של אשכולות, התכונה של רישום פרטי מופעלת כברירת מחדל.

      apiVersion: baremetal.cluster.gke.io/v1
      kind: Cluster
      metadata:
        name: user-basic
        namespace: cluster-user-basic
        resourceVersion: "766027"
        annotations:
          ...
          preview.baremetal.cluster.gke.io/private-registry: "enable"
      ...
      
    2. בקטע nodeConfig של קובץ ההגדרה של אשכול המשתמשים, מוסיפים את הבלוק privateRegistries:

      apiVersion: baremetal.cluster.gke.io/v1
      kind: Cluster
      metadata:
        name: user-basic
      ...
      spec:
        bypassPreflightCheck: false
      ...
        nodeConfig:
          containerRuntime: containerd
          podDensity:
            maxPodsPerNode: 250
          privateRegistries:
          - caCertSecretRef:
              name: CA_CERT_SECRET_NAME
              namespace: CA_CERT_SECRET_NAMESPACE
            host: REGISTRY_HOST
            pullCredentialSecretRef:
              name: CREDS_SECRET_NAME
              namespace: CREDS_SECRET_NAMESPACE
      

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

    • ‫CA_CERT_SECRET_NAME: השם של הסוד שיצרתם כדי לאחסן את אישור ה-CA. אם לא יצרתם את הסוד הזה, צריך להסיר את החסימה caCertSecretRef. אם כמה רישומים פרטיים מפנים לסודות של אישורי CA עם אותו שם במרחבי שמות שונים (חוץ ממרחב השמות anthos-creds או cluster), המערכת מוסיפה קידומת לשם הסוד של היעד כדי לוודא שהשמות של הסודות של אישורי ה-CA הם ייחודיים במרחבי השמות. המערכת לא תוסיף קידומת לסודות במרחב השמות של האשכול או במרחב השמות של המקור ב-anthos-creds.

    • ‫CA_CERT_SECRET_NAMESPACE: השם של מרחב השמות של הסוד של אישור CA, אם יצרתם אותו.

    • ‫REGISTRY_HOST: שם הדומיין או כתובת ה-IP של הרשומות הפרטיות והיציאה. לדוגמה: 10.200.0.2:5007.

    • ‫CREDS_SECRET_NAME: השם של סוג הסוד kubernetes.io/dockerconfigjsonSecret עבור פרטי הכניסה של המרשם.

    • ‫CREDS_SECRET_NAMESPACE: שם מרחב השמות של הסוד לפרטי הכניסה של המאגר.

  4. מחילים את השינויים על האשכול:

    bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
    

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

    • ‫USER_CLUSTER_NAME: שם האשכול שרוצים לעדכן.

    • ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.