Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

בדף הזה מוסבר על בקרת גישה באמצעות ניהול זהויות והרשאות גישה (IAM) ב-Artifact Registry.

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

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

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

מפעילים את Artifact Registry, כולל הפעלת ה-API והתקנת Google Cloud CLI.
אם רוצים להחיל הרשאות ספציפיות למאגר, צריך ליצור מאגר 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 לזהויות חיצוניות, כולל היכולת להתחזות לחשבונות שירות. הגישה הזו מבטלת את נטל התחזוקה והאבטחה שקשורים למפתחות של חשבונות שירות.

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

יוצרים מאגר של איחוד שירותי אימות הזהות של עומסי עבודה.
יוצרים ספק של איחוד שירותי אימות הזהות של עומסי עבודה.
מעניקים את התפקיד המתאים ב-Artifact Registry למאגר הזהויות של עומסי העבודה כדי לאפשר גישה למאגר. מידע נוסף זמין במאמר בנושא מתן גישה למשאבי Google Cloud לעומסי עבודה חיצוניים.
אם אתם צריכים לגשת ל-Artifact Registry לתקופות ארוכות יותר, אתם יכולים להגדיר את זמן התפוגה של אסימון OIDC לתקופה ארוכה יותר בהגדרות האישורים.
מגדירים את הלקוח של הצד השלישי לאימות ב-Artifact Registry.
- Container images: Docker, Helm
- Language packages: Java, Node.js, Python, Go
- OS packages: Debian, RPM
- Other: Kubeflow Pipeline templates

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

יוצרים חשבון שירות שיפעל בשם האפליקציה, או בוחרים חשבון שירות קיים שבו רוצים להשתמש לאוטומציה של CI/CD.
מקצים לחשבון השירות את התפקיד המתאים ב-Artifact Registry כדי לתת גישה למאגר.
מגדירים את הלקוח של הצד השלישי לאימות ב-Artifact Registry.
- Container images: Docker, Helm
- Language packages: Java, Node.js, Python, Go
- OS packages: Debian, RPM
- Other: Kubeflow Pipeline templates

‫GitLab ב- 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 .

משתמשים בתפקידים המוגדרים מראש הבאים למאגרי קוד בדומיין pkg.dev:

תפקיד	תיאור
קורא של Artifact Registry (`roles/artifactregistry.reader`)	צפייה בארטיפקטים וקבלתם, צפייה במטא-נתונים של המאגר.
Artifact Registry Writer (`roles/artifactregistry.writer`)	קריאה וכתיבה של ארטיפקטים.
מנהל מאגר של Artifact Registry (`roles/artifactregistry.repoAdmin`)	קריאה, כתיבה ומחיקה של ארטיפקטים.
אדמין של Artifact Registry (`roles/artifactregistry.admin`)	ליצור ולנהל מאגרי מידע וארטיפקטים.

התפקידים המוגדרים מראש הנוספים הבאים מכילים את ההרשאות שנדרשות כדי לבצע מיגרציה מ-Container Registry ל-Artifact Registry.

תפקיד	תיאור
אדמין של העברה מ-Container Registry אל Artifact Registry (`roles/artifactregistry.containerRegistryMigrationAdmin`)	כולל את כל ההרשאות שנדרשות להפעלת כלי ההעברה
כותב של Artifact Registry Create-on-push (`roles/artifactregistry.createOnPushWriter`)	קריאה וכתיבה של ארטיפקטים. יצירת מאגרי gcr.io כשמבצעים push לכתובות URL של `gcr.io`.
מנהל מאגר של Artifact Registry עם הרשאת יצירה בהעלאה (`roles/artifactregistry.createOnPushRepoAdmin`)	קריאה, כתיבה ומחיקה של ארטיפקטים. יצירת מאגרי gcr.io.

רשימה מלאה של ההרשאות הנפרדות בכל תפקיד מופיעה במאמר תפקידים ב-Artifact Registry. אפשר גם להשתמש בפקודה gcloud iam roles describe כדי לראות רשימה של ההרשאות בכל תפקיד.

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

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

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

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

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

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

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

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

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

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

הערה: כשמנהלים גישה למשתמשים בספקי זהויות חיצוניים, צריך להחליף מופעים של מזהי ישויות (principals) של חשבון Google – כמו user:kiran@example.com,‏ group:support@example.com ו-domain:example.com – במזהי ישויות (principals) מתאימים של איחוד שירותי אימות הזהות של כוח עבודה.

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

המסוף

פותחים את הדף IAM במסוף Google Cloud .
כניסה לדף IAM
לוחצים על Select a project, בוחרים את הפרויקט שבו Artifact Registry פועל ולוחצים על Open.
לוחצים על הוספה.
מזינים כתובת אימייל. תוכלו להוסיף אנשים, חשבונות שירות או קבוצות Google כחשבונות משתמשים.
בוחרים תפקיד לחשבון הראשי. בהתאם לעקרון האבטחה של הרשאות מינימליות, מומלץ להעניק את רמת ההרשאות המינימלית שנדרשת לגישה למשאבי Artifact Registry. מידע על הרשאות ותפקידים מוגדרים מראש ב-Artifact Registry זמין במאמר תפקידים מוגדרים מראש ב-Artifact Registry.
לוחצים על Save.

gcloud

במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
כדי להקצות תפקיד לחשבון ראשי יחיד, מריצים את הפקודה הבאה:
```
gcloud projects add-iam-policy-binding PROJECT \
   --member=PRINCIPAL \
   --role=ROLE
```
איפה
- ‫PROJECT הוא מזהה הפרויקט שבו פועל Artifact Registry.
- ‫PRINCIPAL הוא החשבון הראשי שרוצים להוסיף לו את הקישור. אפשר להשתמש ב-user|group|serviceAccount:email או ב-domain:domain.
  
  דוגמאות: user:test-user@gmail.com,‏ group:admins@example.com,‏ serviceAccount:test123@example.domain.com או domain:example.domain.com.
- ‫ROLE הוא התפקיד שרוצים להקצות.
מידע נוסף זמין במאמר בנושא add-iam-policy-binding.

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

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

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

המסוף

כדי להעניק גישה למאגר ספציפי:

פותחים את הדף Repositories במסוף Google Cloud .

פתיחת הדף Repositories
בוחרים את המאגר המתאים.
אם חלונית המידע לא מוצגת, לוחצים על Show Info Panel בסרגל התפריטים.
בכרטיסייה Permissions (הרשאות), לוחצים על Add Principal (הוספת גורם ראשי).
מזינים כתובת אימייל. תוכלו להוסיף אנשים, חשבונות שירות או קבוצות Google כחשבונות משתמשים.
בוחרים תפקיד לחשבון הראשי. בהתאם לעקרון האבטחה של הרשאות מינימליות, מומלץ להעניק את רמת ההרשאות המינימלית שנדרשת לגישה למשאבי Artifact Registry. מידע על תפקידים מוגדרים מראש והרשאות ב-Artifact Registry
לוחצים על Save.

gcloud

במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

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

כדי להקצות תפקיד לחשבון ראשי יחיד, מריצים את הפקודה הבאה:
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --member=PRINCIPAL \
   --role=ROLE
```
איפה
- ‫REPOSITORY הוא המזהה של המאגר.
- ‫PRINCIPAL הוא החשבון הראשי שרוצים להוסיף לו את הקישור. אפשר להשתמש ב-user|group|serviceAccount:email או ב-domain:domain.
  
  דוגמאות: user:test-user@gmail.com,‏ group:admins@example.com,‏ serviceAccount:test123@example.domain.com או domain:example.domain.com.
- ‫ROLE הוא התפקיד שרוצים להקצות.
- ‫LOCATION הוא המיקום האזורי או המיקום במספר אזורים של המאגר.
לדוגמה, כדי להוסיף קישור למדיניות IAM לתפקיד roles/artifactregistry.writer עבור המשתמש write@gmail.com במאגר my-repo במיקום --us-west1, מריצים את הפקודה:
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
--location=us-west1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
```
כדי להקצות תפקידים באמצעות קובץ מדיניות, צריך להשתמש בהליך שמתואר במאמר הקצאה או ביטול של כמה תפקידים באופן פרוגרמטי עם הפקודות gcloud artifacts repositories get-iam-policy ו-gcloud artifacts repositories set-iam-policy.

Terraform

משתמשים במשאב google_artifact_registry_repository_iam כדי להגדיר מדיניות IAM. בדוגמה הבאה מוגדר חשבון שירות עם שם המשאב repo-account, וניתנת לו גישת קריאה למאגר עם שם המשאב my-repo.

אם אתם חדשים בשימוש ב-Terraform עבור Google Cloud, תוכלו לעיין בדף תחילת העבודה – Google Cloud באתר HashiCorp.

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}"
}

‫ACCOUNT-ID הוא המזהה של חשבון השירות. זה החלק בשדה של כתובת האימייל בחשבון השירות לפני הסמל @.

דוגמאות נוספות זמינות במאמרי העזרה בנושא המשאב google_artifact_registry_repository_iam.

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

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

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

המסוף

פותחים את הדף Repositories במסוף Google Cloud .

פתיחת הדף Repositories
בוחרים את המאגר המתאים.
אם חלונית המידע לא מוצגת, לוחצים על Show Info Panel בסרגל התפריטים.
בכרטיסייה Permissions (הרשאות), לוחצים על Add Principal (הוספת גורם ראשי).
בשדה New principals, מזינים allUsers.
בוחרים את התפקיד Artifact Registry Reader.
כדי למנוע שימוש לרעה על ידי משתמשים לא מאומתים, מגדירים מגבלה לכל משתמש על בקשות ל-Artifact Registry API. ההוראות מפורטות במאמר בנושא הגבלת השימוש.

gcloud

במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
מריצים את הפקודה הבאה:
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
--location=LOCATION --member=allUsers --role=ROLE
```
איפה
- ‫REPOSITORY הוא המזהה של המאגר.
- ‫ROLE הוא התפקיד שרוצים להעניק. ‫
- ‫LOCATION הוא המיקום האזורי או המיקום במספר אזורים של המאגר.
לדוגמה, כדי להגדיר את המאגר my-repo במיקום --us-west1 כציבורי, מריצים את הפקודה:
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location=us-west1 --member=allUsers --role=roles/artifactregistry.reader
```
‫
כדי למנוע שימוש לרעה על ידי משתמשים לא מאומתים, מגדירים מגבלה לכל משתמש על בקשות ל-Artifact Registry API. ההוראות מפורטות במאמר בנושא הגבלת השימוש.

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

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

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

המסוף

כדי לבטל הרשאות:

פותחים את הדף Repositories במסוף Google Cloud .

פתיחת הדף Repositories
בוחרים את המאגר המתאים.
אם חלונית המידע לא מוצגת, לוחצים על Show Info Panel בסרגל התפריטים.
בכרטיסייה Permissions (הרשאות), מרחיבים את העיקרון המתאים. אם אתם הופכים מאגר ציבורי לפרטי, מרחיבים את העיקרון allUsers.
לוחצים על הסרת הגורם המקורי כדי לבטל את הגישה.

gcloud

במסוף Google Cloud , מפעילים את Cloud Shell.

הפעלת Cloud Shell

בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
כדי לבטל תפקיד ברמת הפרויקט, מריצים את הפקודה הבאה:
```
gcloud projects remove-iam-policy-binding PROJECT \
   --member=PRINCIPAL \
   --role=ROLE
```
- ‫PROJECT הוא מזהה הפרויקט.
- ‫PRINCIPAL הוא החשבון הראשי שרוצים להסיר את הקישור שלו. אפשר להשתמש ב-user|group|serviceAccount:email או ב-domain:domain.
  
  דוגמאות: user:test-user@gmail.com,‏ group:admins@example.com,‏ serviceAccount:test123@example.domain.com או domain:example.domain.com.
- ‫ROLE הוא התפקיד שרוצים לבטל.
כדי לבטל תפקיד במאגר, מריצים את הפקודה הבאה:
```
gcloud artifacts repositories remove-iam-policy-binding REPOSITORY
   --location=LOCATION \
   --member=PRINCIPAL \
   --role=ROLE
```
איפה
- ‫REPOSITORY הוא המזהה של המאגר.
- ‫PRINCIPAL הוא החשבון הראשי שרוצים להסיר את הקישור שלו. אפשר להשתמש ב-user|group|serviceAccount:email או ב-domain:domain.
  
  דוגמאות: user:test-user@gmail.com,‏ group:admins@example.com,‏ serviceAccount:test123@example.domain.com או domain:example.domain.com.
  
  כדי לבטל את הגישה הציבורית למאגר, מציינים את הגורם המורשה allUsers.
- ‫ROLE הוא התפקיד שרוצים לבטל.
לדוגמה, כדי להסיר קישור למדיניות עבור התפקיד roles/artifactregistry.writer למשתמש write@gmail.com במאגר my-repo במיקום --us-west1, מריצים את הפקודה:
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=us-west1 \
   --member=user:write@gmail.com \
   --role=roles/artifactregistry.writer
```
כדי לבטל את הגישה לכולם אל my-repo במיקום --us-west1, מריצים את הפקודה:
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=us-west1 \
   --member=allUsers \
   --role=roles/artifactregistry.reader
```

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

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

שירות	חשבון שירות	כתובת האימייל
סביבה גמישה של App Engine	חשבון שירות של App Engine	`PROJECT-ID`@appspot.gserviceaccount.com
Compute Engine	חשבון השירות של Compute Engine שמוגדר כברירת מחדל	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com
Cloud Build	חשבון שירות של Compute Engine או חשבון שירות מדור קודם של Cloud Build	בהתאם להגדרות הארגון, כתובת האימייל של חשבון השירות שמוגדרת כברירת מחדל היא אחת מהאפשרויות הבאות: ‫Compute Engine: ‏ `PROJECT-NUMBER`-compute@developer.gserviceaccount.com Cloud Build: ‏ `PROJECT-NUMBER`@cloudbuild.gserviceaccount.com הערה: חשבון השירות שמוגדר כברירת מחדל ב-Cloud Build, שמשמש להרצת בנייה, השתנה מחשבון השירות מדור קודם של Cloud Build לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. מידע נוסף זמין במאמר בנושא שינוי בחשבון השירות של Cloud Build.
Cloud Run	סוכן השירות של Cloud Run סוכן השירות של `run.googleapis.com`.	service-`PROJECT-NUMBER`@serverless-robot-prod.iam.gserviceaccount.com
GKE	חשבון השירות של Compute Engine שמוגדר כברירת מחדל חשבון השירות שמוגדר כברירת מחדל לצמתים.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com

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

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

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

מתן גישה למכונות של 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.

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

בפרויקט שבו נמצאת מכונת ה-VM, מאחזרים את השם של חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. כתובת האימייל של חשבון השירות מסתיימת בסיומת @developer.gserviceaccount.com.
בפרויקט עם המאגר, מעניקים הרשאות כדי שחשבון השירות יוכל לגשת למאגר.
מגדירים את היקף הגישה באמצעות האפשרות ‎--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:

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

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

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

מעניקים את ההרשאות הנדרשות לחשבון השירות מהפרויקטGoogle Cloud שבו פועל Artifact Registry.
כברירת מחדל, כשיוצרים מאגר צמתים או אשכול עם חשבון שירות שסופק על ידי המשתמש, מוענק היקף הגישה 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:

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

הערה: אם לא מנהלים כראוי את המפתחות לחשבונות השירות הם עלולים לסכן את האבטחה. כשזה אפשרי, מומלץ לבחור שיטה מאובטחת יותר ממפתחות של חשבונות שירות. אם אתם מוכרחים לבצע אימות באמצעות מפתח של חשבון שירות, באחריותכם לאבטח את המפתח הפרטי ולבצע פעולות אחרות שמתוארות במאמר שיטות מומלצות לניהול מפתחות לחשבונות שירות. אם אין לכם אפשרות ליצור מפתח לחשבון שירות, יכול להיות שהיצירה של מפתחות לחשבון שירות מושבתת בארגון שלכם. מידע נוסף זמין במאמר בנושא ניהול משאבי ארגון שמוגדרים כמאובטחים כברירת מחדל.
אם קיבלתם את המפתח של חשבון השירות ממקור חיצוני, אתם צריכים לאמת אותו לפני השימוש. מידע נוסף זמין במאמר בנושא דרישות אבטחה לגבי אישורים ממקורות חיצוניים.
בפרויקט עם המאגר, מוודאים שהענקתם הרשאות למאגר.
בפרויקט עם האשכול, יוצרים סוד 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`.
פותחים את חשבון השירות שמוגדר כברירת מחדל:
```
kubectl edit serviceaccount default --namespace default
```
לכל מרחב שמות באשכול Kubernetes יש חשבון שירות שמוגדר כברירת מחדל בשם default. חשבון השירות שמוגדר כברירת מחדל משמש לשליפת קובץ האימג' של הקונטיינר.

מוסיפים את הסוד 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.

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

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

Container images: Docker, Helm
Language packages: Java, Node.js, Python, Go
OS packages: Debian, RPM

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

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

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

סקירה כללית

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

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

‫GitLab ב- Google Cloud

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

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

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

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

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

המסוף

gcloud

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

המסוף

gcloud

Terraform

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

המסוף

gcloud

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

המסוף

gcloud

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

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

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

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

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

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

הגדרת imagePullSecret

חשבון השירות של Artifact Registry

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

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

הגדרת `imagePullSecret`