בקרת גישה באמצעות IAM

משתמשים בניהול זהויות והרשאות גישה (IAM) כדי להקצות תפקידים ולקבוע למי תהיה גישה לנתונים ב-Artifact Registry ולמי תהיה אפשרות לנהל אותם. ‫Artifact Registry מכיל תפקידים מוגדרים מראש שיכולים לעזור לייעל את ההגדרה של צינורות CI/CD. אם אתם צריכים בקרת גישה נוספת או שאתם משלבים את Artifact Registry עם כלי של צד שלישי, אתם יכולים גם להגדיר תפקידים בהתאמה אישית.

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

1. מפעילים את Artifact Registry, כולל הפעלת ה-API והתקנת Google Cloud CLI.
2. אם רוצים להחיל הרשאות ספציפיות למאגר, צריך ליצור מאגר Artifact Registry לחבילות.

סקירה כללית

ההרשאות והתפקידים ב-IAM קובעים את היכולת שלכם ליצור, להציג, לערוך או למחוק נתונים במאגר של Artifact Registry.

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

Google Cloud הרשאות ברירת מחדל

כברירת מחדל, ההרשאות הבאות חלות על Google Cloud שירותי CI/CD באותו פרויקט כמו Artifact Registry:

• הרשאות ב-Cloud Build כוללות הרשאות להעלאה ולהורדה של ארטיפקטים.

• ‫Compute Engine,‏ גרסאות נתמכות של Google Kubernetes Engine ו-Cloud Run משתמשים בחשבון השירות שמוגדר כברירת מחדל של Compute Engine, שיש לו גישת קריאה בלבד לאחסון.

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

צריך להגדיר הרשאות ל-Artifact Registry בשירותים האלה אם:

• אתם רוצים להשתמש בשירותים האלה כדי לגשת ל-Artifact Registry בפרויקט אחר. בפרויקט עם Artifact Registry, מקצים לכל שירות את התפקיד הנדרש למאגר הזהויות של עומס העבודה או לחשבון השירות. אם מתחברים ל-Cloud Run, צריך להעניק לסוכן השירות של Cloud Run את התפקיד הנדרש.

• אתם משתמשים בגרסת GKE שאין בה תמיכה מובנית בשליפת תמונות מ-Artifact Registry. הוראות להגדרה מופיעות בקטע GKE.
• אתם רוצים שלחשבון השירות שמוגדר כברירת מחדל תהיה גישת קריאה וכתיבה למאגרי מידע. פרטים נוספים זמינים במאמרים הבאים:
  • Compute Engine
  • GKE
• אתם משתמשים בחשבון שירות שסופק על ידי המשתמש עבור סביבות זמן הריצה במקום בחשבון השירות שמוגדר כברירת מחדל. בפרויקט עם Artifact Registry, מקצים לחשבון השירות את התפקיד הנדרש.

שילוב עם צד שלישי

במקרה של לקוחות צד שלישי, צריך להגדיר גם הרשאות וגם אימות.

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

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

שימוש באיחוד שירותי אימות הזהות של עומסי עבודה:

1. יוצרים מאגר של איחוד זהויות של עומסי עבודה.
2. יוצרים ספק של איחוד זהויות של עומסי עבודה.
3. מעניקים את התפקיד המתאים ב-Artifact Registry למאגר הזהויות של עומסי העבודה כדי לאפשר גישה למאגר. מידע נוסף זמין במאמר בנושא מתן גישה לעומס עבודה חיצוני למשאבי Google Cloud .
4. אם אתם צריכים לגשת ל-Artifact Registry לתקופות ארוכות יותר, אתם יכולים להגדיר את זמן התפוגה של אסימון OIDC לתקופה ארוכה יותר בהגדרת פרטי הכניסה.

5. מגדירים את הלקוח של הצד השלישי כך שיבצע אימות ב-Artifact Registry.

   • קובצי אימג' של קונטיינרים: Docker, Helm
   • חבילות שפה: ‫Java, ‫Node.js, ‫Python, ‫Go
   • חבילות של מערכת ההפעלה: Debian,‏ RPM
   • אחר: תבניות של Kubeflow Pipeline

שימוש בחשבון שירות:

1. יוצרים חשבון שירות שיפעל בשם האפליקציה, או בוחרים חשבון שירות קיים שבו רוצים להשתמש לאוטומציה של CI/CD.
2. מקצים לחשבון השירות את התפקיד המתאים ב-Artifact Registry כדי לתת גישה למאגר.

3. מגדירים את הלקוח של הצד השלישי כך שיבצע אימות ב-Artifact Registry.

   • קובצי אימג' של קונטיינרים: Docker, Helm
   • חבילות שפה: ‫Java, ‫Node.js, ‫Python, ‫Go
   • חבילות של מערכת ההפעלה: Debian,‏ RPM
   • אחר: תבניות של Kubeflow Pipeline

‫GitLab on Google Cloud

השילוב של GitLab ב- Google Cloud משתמש באיחוד שירותי אימות הזהות של עומסי עבודה לצורך הרשאה ואימות של עומסי עבודה של GitLab ב- Google Cloud , ללא צורך בחשבונות שירות או במפתחות של חשבונות שירות. מידע נוסף על השימוש באיחוד שירותי אימות הזהות של עומסי עבודה במסגרת השותפות הזו זמין במאמר Google Cloud איחוד שירותי אימות הזהות של עומסי עבודה ומדיניות IAM.

כדי להגדיר את איחוד שירותי אימות הזהות של עומסי עבודה ואת תפקידי ה-IAM הנדרשים ב-GitLab ב- Google Cloud, אפשר לעיין במדריך של GitLab בנושא Google Cloud איחוד שירותי אימות הזהות של עומסי עבודה ומדיניות IAM.

כדי לחבר את מאגר Artifact Registry, פועלים לפי המדריך של GitLab בנושא Google Artifact Registry.

תפקידים והרשאות

כל method ב-Artifact Registry API מחייבת שלחשבון המשתמש שמבצע את הבקשה יהיו ההרשאות הנדרשות לשימוש במשאב. ההרשאות מוענקות לחשבונות משתמשים באמצעות הגדרת מדיניות שמעניקה לחשבון המשתמש תפקיד מוגדר מראש במשאב.

אפשר להקצות תפקידים ב Google Cloud פרויקט או במאגר של Artifact Registry.

תפקידים מוגדרים מראש ב-Artifact Registry

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

תפקידים בסיסיים ב-IAM

לתפקידים בסיסיים יש הרבה הרשאות, והם היו קיימים לפני IAM. לא מומלץ להקצות תפקידים בסיסיים בסביבת ייצור, אבל אפשר להקצות אותם בסביבת פיתוח או בדיקה.

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

מידע נוסף על תפקידים בסיסיים זמין במאמר מסמך עזר בנושא תפקידים בסיסיים ומוגדרים מראש ב-IAM.

הקצאת תפקידים

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

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

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

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

כדי להוסיף משתמש או חשבון שירות לפרויקט ולהעניק להם תפקיד ב-Artifact Registry:

הענקת תפקידים ספציפיים למאגר

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

provider "google" {
    project = "PROJECT-ID"
}

resource "google_artifact_registry_repository" "my-repo"     {
  provider = google-beta

  location = "LOCATION"
  repository_id = "REPOSITORY"
  description = "DESCRIPTION"
  format = "FORMAT"
}

resource "google_service_account" "repo-account" {
  provider = google-beta

  account_id   = "ACCOUNT-ID"
  display_name = "Repository Service Account"
}

resource "google_artifact_registry_repository_iam_member" "repo-iam" {
  provider = google-beta

  location = google_artifact_registry_repository.my-repo.location
  repository = google_artifact_registry_repository.my-repo.name
  role   = "roles/artifactregistry.reader"
  member = "serviceAccount:${google_service_account.repo-account.email}"
}

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

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

כדי להגדיר מאגר עם גישת קריאה בלבד לציבור, צריך להעניק את התפקיד Artifact Registry Reader לחשבון הראשי allUsers. מומלץ גם להגביל את מכסות הבקשות של המשתמשים כדי שמשתמש בודד לא יוכל לנצל את המכסה הכוללת של הפרויקט.

ביטול תפקידים

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

כדי להסיר את הגישה הציבורית ממאגר, מסירים את החשבון הראשי allUsers.

הענקת גישה מותנית באמצעות תגים

אדמינים של פרויקטים יכולים ליצור תגים למשאבים ב- Google Cloudולנהל אותם במנהל המשאבים. כשמצרפים תג למאגר של Artifact Registry, האדמינים יכולים להשתמש בתג עם תנאי IAM כדי להעניק גישה מותנית למאגר.

אי אפשר לצרף תגים לפריטים ספציפיים.

מידע נוסף זמין במאמרי העזרה הבאים:

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

שילוב עם שירותים Google Cloud

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

חשבונות שירות שמוגדרים כברירת מחדל בשביל שירותים מסוימים ( Google Cloud )

Google Cloud שירותים כמו Cloud Build או Google Kubernetes Engine משתמשים בחשבון שירות ברירת מחדל או בסוכן שירות כדי ליצור אינטראקציה עם משאבים באותו פרויקט.

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

• השירות Google Cloud נמצא בפרויקט אחר מ-Artifact Registry.
• הרשאות ברירת המחדל לא מתאימות לצרכים שלכם.
• אתם משתמשים בחשבון שירות שסופק על ידי המשתמש כדי ליצור אינטראקציה עם Artifact Registry במקום להשתמש בחשבון השירות שמוגדר כברירת מחדל.
• ההגדרות של מדיניות הארגון מונעות הקצאת תפקידים אוטומטית לחשבונות שירות שמוגדרים כברירת מחדל.

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

בהתאם להגדרות של מדיניות הארגון, יכול להיות שחשבון השירות שמוגדר כברירת מחדל יקבל אוטומטית את התפקיד 'עריכה' בפרויקט. אנחנו ממליצים מאוד להשבית את הענקת התפקיד האוטומטית על ידי החלת האילוץ של מדיניות הארגון iam.automaticIamGrantsForDefaultServiceAccounts. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

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

מתן גישה למכונות של Compute Engine

למכונות וירטואליות שרוצות לגשת למאגרים צריכות להיות הרשאות ל-Artifact Registry והיקף גישה לאחסון.

רמת הגישה של חשבון שירות נקבעת לפי תפקידי ה-IAM שהוקצו לחשבון השירות, אבל היקפי הגישה במכונה וירטואלית קובעים את היקפי ברירת המחדל של OAuth לבקשות שמוגשות דרך ה-CLI של gcloud וספריות הלקוח במכונה. כתוצאה מכך, היקפי הגישה עשויים להגביל עוד יותר את הגישה לשיטות API כשמבצעים אימות באמצעות Application Default Credentials.

ב-Compute Engine מוגדרות כברירת מחדל ההגדרות הבאות:

• חשבון השירות של Compute Engine שמוגדר כברירת מחדל הוא הזהות של מכונות וירטואליות. כתובת האימייל של חשבון השירות מסתיימת בסיומת @developer.gserviceaccount.com.
• לחשבון השירות שמוגדר כברירת מחדל יש את תפקיד העריכה הבסיסי ב-IAM, אלא אם השבתתם את ההתנהגות הזו.
• למכונות שאתם יוצרים עם חשבון השירות שמוגדר כברירת מחדל יש היקפי גישה שמוגדרים כברירת מחדל ב-Compute Engine, כולל גישה לקריאה בלבד לאחסון. למרות שהתפקיד 'עריכה' בדרך כלל מעניק גישת כתיבה, היקף הגישה לאחסון read-only מגביל את חשבון השירות של המופע להורדת ארטיפקטים רק ממאגר כלשהו באותו פרויקט.

צריך להגדיר את היקף הגישה של חשבון השירות אם:

• חשבון השירות של מכונת ה-VM צריך לגשת למאגר בפרויקט אחר.
• חשבון השירות של המכונה הווירטואלית צריך לבצע פעולות אחרות מלבד קריאת ארטיפקטים ממאגרים. בדרך כלל, זה קורה כשמפעילים כלים של צד שלישי במכונה וירטואלית שצריכים לשלוח תמונות או להריץ פקודות של Artifact Registry gcloud.

כדי להגדיר תפקידים ולהגדיר את היקף הגישה:

1. בפרויקט שבו נמצאת מכונת ה-VM, מאחזרים את השם של חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. כתובת האימייל של חשבון השירות מסתיימת בסיומת @developer.gserviceaccount.com.

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

3. מגדירים את היקף הגישה באמצעות האפשרות ‎--scopes.

   1. מפסיקים את המכונה הווירטואלית. מידע נוסף על עצירת מכונה

   2. מגדירים את היקף הגישה באמצעות הפקודה הבאה:

      gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
      

      מחליפים את SCOPE בערך המתאים.

      • ב-Docker, האפשרויות הבאות נתמכות:

        • ‫storage-ro – מתן הרשאת קריאה רק לשליפת תמונות.
        • ‫storage-rw – מעניק הרשאת קריאה וכתיבה לדחיפה או למשיכה של תמונות.
        • ‫cloud-platform – צפייה בנתונים וניהול שלהם, כולל מטא-נתונים, בשירותGoogle Cloud .

      • בפורמטים אחרים, צריך להשתמש בהיקף cloud-platform.

   3. מפעילים מחדש את המכונה הווירטואלית. מידע נוסף זמין במאמר הפעלת מכונה מושבתת.

הענקת גישה לאשכולות Google Kubernetes Engine

אשכולות GKE ומאגרי צמתים יכולים לשלוף קונטיינרים ללא צורך בהגדרה נוספת, אם מתקיימות כל הדרישות הבאות:

• ‫GKE נמצא באותו פרויקט כמו Artifact Registry
• הצמתים משתמשים בחשבון השירות שמוגדר כברירת מחדל, חשבון השירות של Compute Engine שמוגדר כברירת מחדל
• נוצרו צמתים עם גישת קריאה לאחסון על ידי:
  • שימוש בהיקפי הגישה שמוגדרים כברירת מחדל ב-Compute Engine.
  • הענקת היקף הגישה cloud-platform או היקף גישה אחר שכולל גישת קריאה לאחסון.
• אתם מריצים גרסה נתמכת של GKE

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

חשבון שירות המשמש כברירת מחדל

הדרישות הבאות בנוגע להגדרות חלות על חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine:

1. אם GKE נמצא בפרויקט אחר מ-Artifact Registry, צריך להעניק את ההרשאות הנדרשות לחשבון השירות.

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

3. אם אתם לא משתמשים בגרסה נתמכת של GKE, צריך להגדיר את imagePullSecrets.

חשבון שירות שסופק על ידי המשתמש

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

1. נותנים לחשבון השירות את ההרשאות הנדרשות מGoogle Cloud הפרויקט שבו פועל Artifact Registry.

2. כברירת מחדל, כשיוצרים מאגר צמתים או אשכול עם חשבון שירות שסופק על ידי המשתמש, מוענק היקף הגישה cloud-platform.

   אם משתמשים בדגל --scopes עם הפקודה gcloud container clusters create או gcloud container node-pools create, צריך לכלול את היקפי הגישה המתאימים לשימוש ב-Artifact Registry.

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

היקפי גישה הם השיטה הקודמת להגדרת הרשאות למכונות וירטואליות ב-Compute Engine. כדי לשלוף תמונות ממאגרי Artifact Registry, לצמתי GKE צריכה להיות הרשאת גישה לקריאה בלבד לאחסון, או הרשאת גישה אחרת לאחסון שכוללת גישת קריאה לאחסון.

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

• אם אתם משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine,‏ GKE יוצר צמתים עם היקפי הגישה שמוגדרים כברירת מחדל ב-Compute Engine, שכוללים גישת קריאה בלבד לאחסון.
• אם משתמשים בחשבון שירות שסופק על ידי המשתמש, GKE יוצר צמתים עם ההיקף cloud-platform, ההיקף שנדרש לרוב השירותים שלGoogle Cloud .

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

gcloud container clusters create NAME --scopes=SCOPES

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

gcloud container node-pools create NAME --scopes=SCOPES

מחליפים את הערכים הבאים:

• ‫NAME הוא השם של האשכול או של מאגר הצמתים.

• ‫SCOPES היא רשימה מופרדת בפסיקים של היקפי גישה להענקה.

  • כדי לגשת למאגרי Docker, צריך להשתמש באחת מההרשאות הבאות:

  • ‫storage-ro – מתן הרשאת קריאה בלבד לשליפת תמונות.

  • ‫storage-rw – מעניק הרשאת קריאה וכתיבה לדחיפה או למשיכה של תמונות.

  • ‫cloud-platform – צפייה בנתונים וניהול שלהם, כולל מטא-נתונים, בשירותGoogle Cloud .

  • כדי לגשת למאגרים אחרים, צריך להשתמש בהיקף cloud-platform.

  רשימה מלאה של היקפי ההרשאות זמינה במסמכי התיעוד של gcloud container clusters create או של gcloud container node-pools create.

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

הגדרת imagePullSecret

כדי להגדיר imagePullSecret:

1. בפרויקט עם GKE, מאתרים את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. כתובת האימייל בחשבון מסתיימת בסיומת ‎@developer.gserviceaccount.com.

2. מורידים את המפתח של חשבון השירות.

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

4. בפרויקט עם האשכול, יוצרים סוד imagePullSecret בשם artifact-registry עם המפתח של חשבון השירות.

   kubectl create secret docker-registry artifact-registry \
   --docker-server=https://LOCATION-docker.pkg.dev \
   --docker-email=SERVICE-ACCOUNT-EMAIL \
   --docker-username=_json_key \
   --docker-password="$(cat KEY-FILE)"
   

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

   • ‫LOCATION הוא המיקום האזורי או המיקום במספר אזורים של המאגר.
   • ‫SERVICE-ACCOUNT-EMAIL היא כתובת האימייל של חשבון השירות של Compute Engine.
   • ‫KEY-FILE הוא השם של קובץ המפתח של חשבון השירות. לדוגמה, key.json.

5. פותחים את חשבון השירות שמוגדר כברירת מחדל:

   kubectl edit serviceaccount default --namespace default

   לכל מרחב שמות באשכול Kubernetes יש חשבון שירות שמוגדר כברירת מחדל בשם default. חשבון השירות שמוגדר כברירת מחדל משמש לשליפת קובץ האימג' של הקונטיינר.

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

   imagePullSecrets:
   - name: artifact-registry
   

   חשבון השירות שלכם אמור להיראות עכשיו כך:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: default
     namespace: default
     ...
   secrets:
   - name: default-token-zd84v
   # The secret you created:
   imagePullSecrets:
   - name: artifact-registry
   

מעכשיו, לכל פוד חדש שייווצר במרחב השמות default הנוכחי יהיה מוגדר הסוד imagePullSecret.

סוכן שירות של Artifact Registry

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

המאמרים הבאים

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

• קובצי אימג' של קונטיינרים: Docker, Helm
• חבילות שפה: Java,‏ Node.js,‏ Python,‏ Go
• חבילות של מערכת ההפעלה: Debian,‏ RPM