היקפי גישה ב-GKE

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

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

מהם היקפי גישה?

היקפי גישה הם השיטה הקודמת למתן הרשאות לצמתים ולעומסי עבודה שפועלים בצמתים, אם עומסי העבודה משתמשים בפרטי כניסה שמוגדרים כברירת מחדל באפליקציה (ADC). היקפי גישה מגדירים את היקפי ה-OAuth שמשמשים בקריאות ל-API מספריות לקוח או מ-CLI של gcloud.

מומלץ לא לציין היקפי גישה משלכם. במקום זאת, צריך להשתמש בהרשאות IAM או בבקרת גישה שמבוססת על תפקידים (RBAC) ב-Kubernetes כדי להעניק גישה לחשבונות שירות ספציפיים ב-IAM או לחשבונות שירות ספציפיים ב-Kubernetes.

היקפי גישה שמוגדרים כברירת מחדל

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

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

אשכולות במצב Autopilot

חשבון שירות האם ציינתם באופן ידני את היקפי הגישה? היקפי גישה ש-GKE מוסיף
חשבון השירות של Compute Engine שמוגדר כברירת מחדל לא
  • https://www.googleapis.com/auth/devstorage.read_only
  • https://www.googleapis.com/auth/service.management.readonly
  • https://www.googleapis.com/auth/servicecontrol
  • https://www.googleapis.com/auth/trace.append
  • ‫https://www.googleapis.com/auth/logging.write: נוסף אם Cloud Logging מופעל
  • ‫https://www.googleapis.com/auth/monitoring: נוסף אם Cloud Monitoring מופעל
כן היקפי הרשאות שצוינו באופן ידני
חשבון שירות בהתאמה אישית לא https://www.googleapis.com/auth/cloud-platform
כן היקפי הרשאות שצוינו באופן ידני

אשכולות רגילים

חשבון שירות היקפי גישה שצוינו באופן ידני? היקפי גישה ב-GKE
חשבון השירות של Compute Engine שמוגדר כברירת מחדל לא
  • https://www.googleapis.com/auth/devstorage.read_only
  • https://www.googleapis.com/auth/service.management.readonly
  • https://www.googleapis.com/auth/servicecontrol
  • https://www.googleapis.com/auth/trace.append
  • ‫https://www.googleapis.com/auth/logging.write: נוסף אם Cloud Logging מופעל
  • ‫https://www.googleapis.com/auth/monitoring: נוסף אם Cloud Monitoring מופעל
כן
  • היקפי הרשאות שצוינו באופן ידני
  • https://www.googleapis.com/auth/monitoring.write
  • ‫https://www.googleapis.com/auth/logging.write: נוסף אם Cloud Logging מופעל
  • ‫https://www.googleapis.com/auth/monitoring: נוסף אם Cloud Monitoring מופעל
חשבון שירות בהתאמה אישית לא
  • https://www.googleapis.com/auth/userinfo.email
  • https://www.googleapis.com/auth/cloud-platform
כן
  • היקפי הרשאות שצוינו באופן ידני
  • https://www.googleapis.com/auth/monitoring.write
  • ‫https://www.googleapis.com/auth/logging.write: נוסף אם Cloud Logging מופעל
  • ‫https://www.googleapis.com/auth/monitoring: נוסף אם Cloud Monitoring מופעל

הגדרת חשבון שירות מותאם אישית לעומסי עבודה

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

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

יצירה של חשבון שירות

כדי ליצור חשבון שירות מותאם אישית בשם kubernetes-engine-node-sa, מריצים את הפקודות הבאות:

export NODE_SA_NAME=kubernetes-engine-node-sa
gcloud iam service-accounts create $NODE_SA_NAME \
  --display-name "GKE Node Service Account"
export NODE_SA_EMAIL=`gcloud iam service-accounts list --format='value(email)' \
  --filter='displayName:GKE Node Service Account'`

הקצאת תפקידים עם הרשאות מינימליות

כדי להגדיר את חשבון השירות עם התפקידים וההרשאות המינימליים שנדרשים לפעולה של צומת GKE, מריצים את הפקודות הבאות, כאשר $PROJECT הוא מזהה הפרויקט:

export PROJECT=`gcloud config get-value project`
gcloud projects add-iam-policy-binding $PROJECT \
  --member serviceAccount:$NODE_SA_EMAIL \
  --role roles/monitoring.metricWriter
gcloud projects add-iam-policy-binding $PROJECT \
  --member serviceAccount:$NODE_SA_EMAIL \
  --role roles/monitoring.viewer
gcloud projects add-iam-policy-binding $PROJECT \
  --member serviceAccount:$NODE_SA_EMAIL \
  --role roles/logging.logWriter

הקצאת תפקידים נוספים

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

gcloud projects add-iam-policy-binding $PROJECT \
  --member serviceAccount:$NODE_SA_EMAIL \
  --role roles/compute.admin

במאמר מתן גישה לאשכולות Google Kubernetes Engine מוסבר איך נותנים לחשבונות שירות גישה לתמונות פרטיות שמאוחסנות ב-Artifact Registry.

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

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

gcloud container clusters create --service-account=$NODE_SA_EMAIL

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

gcloud container node-pools create --service-account=$NODE_SA_EMAIL