בדף הזה מוסבר איך מגדירים הרשאות ספציפיות של קריאה, כתיבה או אדמין לניהול זהויות והרשאות גישה (IAM) לאזורים מנוהלים שונים באותו פרויקט.
מידע מפורט על מדיניות IAM מופיע במאמר הסבר על מדיניות הרשאות. מידע על IAM Policy API זמין במאמר Policy. במאמר הסבר על תפקידים בהתאמה אישית ב-IAM מוסבר איך יוצרים תפקידים בהתאמה אישית ב-IAM שאפשר להשתמש בהם באזורים מנוהלים.
ההליך הזה מניח שיצרתם אזור מנוהל בפרויקט. הוראות ליצירת אזור מנוהל מופיעות במאמר יצירה, שינוי ומחיקה של אזורים.
הגדרת מדיניות IAM לאזור מנוהל
כדי להגדיר את מדיניות IAM באזור מנוהל ספציפי, פועלים לפי השלבים הבאים.
המסוף
נכנסים לדף Cloud DNS zones במסוף Cloud de Confiance .
בוחרים אזור אחד או יותר שרוצים להוסיף להם הרשאות של בקרת גישה.
בדף Permissions to resources, לוחצים על Add principal.
בדף Grant access to resource, בקטע New principals, מוסיפים את כתובת האימייל של המשתמש, הקבוצה, הדומיין או חשבון השירות שרוצים להוסיף כגורם החדש.
ברשימה Assign roles, בוחרים את התפקיד שרוצים להקצות לחשבון המשתמש.
כדי להקצות עוד תפקידים, לוחצים על Add another role.
לוחצים על Save.
gcloud
מריצים את הפקודה gcloud dns managed-zones set-iam-policy:
gcloud dns managed-zones set-iam-policy NAME \ --policy-file=POLICY-FILE
מחליפים את מה שכתוב בשדות הבאים:
-
NAME: השם של האזור המנוהל שעבורו רוצים להגדיר את הרשאת ה-IAM -
POLICY-FILE: הקובץ שמכיל את מדיניות ה-IAM שרוצים לציין לאזור המנוהל. דוגמה לקובץ מדיניות מופיעה במאמר מדיניות.
אם הפקודה הזו פועלת בהצלחה, היא מחזירה את מדיניות IAM. אחרת, תוחזר הודעת שגיאה עם פירוט השגיאה.
API
שולחים בקשת POST באמצעות השיטה managedZone.setIamPolicy:
POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE:setIamPolicy
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: השם או המזהה של הפרויקט -
MANAGED_ZONE: השם של האזור המנוהל שעבורו רוצים להגדיר את הרשאת ה-IAM
מידע מפורט על הקריאה הזו ל-API מופיע בקטע Binding בדף IAM Policy API.
הענקת גישה לקבוצות ספציפיות של רשומות משאבים
Cloud DNS תומך בשימוש בתנאים של IAM כדי לספק בקרת גישה פרטנית לקבוצות ספציפיות של רשומות משאבים (RRsets) בתחום מנוהל.
אפשר להגדיר בקרת גישה ברמת פירוט גבוהה באחת מהשיטות הבאות:
- תפקיד רגיל (מומלץ): משתמשים בתפקיד הרגיל
roles/dns.adminעם תנאי IAM ספציפי שמאפשר פעולות נדרשות שלא קשורות לערכות רשומות. זו הגישה הכי פשוטה כי היא לא דורשת יצירה של תפקידים בהתאמה אישית. - תפקידים בהתאמה אישית: יוצרים שני תפקידים בהתאמה אישית כדי להפריד בין ניהול של קבוצות רשומות לבין משימות אדמיניסטרטיביות אחרות.
שיטה 1: תפקיד רגיל (מומלץ)
כדי להשתמש בתפקיד הרגיל roles/dns.admin, צריך לכלול משאבים נוספים בתנאי IAM. הסיבה לכך היא שכדי לשנות רשומות DNS בהצלחה, לחשבון המשתמש צריכה להיות הרשאה לבצע את השינוי ברשומה עצמה ואת הפעולות המשויכות במשאבי Change.
בהתאם לדרישות האבטחה שלכם, תוכלו לבחור באחת ממבני התנאים הבאים:
- מתירנית: מאפשרת את כל הפעולות האדמיניסטרטיביות האחרות ב-DNS. הגישה הזו שוות ערך לגישת התפקידים בהתאמה אישית, אם התפקיד המשני מכיל את כל הרשאות האדמין הסטנדרטיות האחרות.
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && <RRSET_CONDITION>) || (resource.type != 'dns.googleapis.com/ResourceRecordSet') - מגבילה: מאפשרת רק שינויים במערך הרשומות ופעולות במשאבי שינוי. פעולות ניהול אחרות, כולל הצגת רשומות (
dns.resourceRecordSets.list) ותיאור האזור המנוהל, חסומות.none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && <RRSET_CONDITION>) || (resource.type == 'dns.googleapis.com/Change')
מחליפים את הערך <RRSET_CONDITION> בדרישות הגישה הספציפיות שלכם (ראו דוגמאות לתנאים).
כדי להעניק הרשאות:
1. מקצים את התפקיד roles/dns.admin לחשבון המשתמש באזור המנוהל.
- מוסיפים את התנאי (מתיר או מגביל) לקישור.
שיטה 2: תפקידים בהתאמה אישית
אם אתם לא רוצים להשתמש בתנאים מורכבים, אתם יכולים ליצור תפקידים בהתאמה אישית כדי להפריד בין ההרשאות.
דרישה מוקדמת: יצירת תפקידים בהתאמה אישית
יוצרים תפקיד לניהול קבוצות רשומות (לדוגמה,
DnsRecordSetAdmin) שמכיל את ההרשאות הבאות:dns.resourceRecordSets.createdns.resourceRecordSets.deletedns.resourceRecordSets.getdns.resourceRecordSets.update
יוצרים תפקיד משלים (לדוגמה,
DnsNonRecordSetAdmin) שמכיל את כל ההרשאות שנותרו מהתפקיד הרגילroles/dns.admin. ההרשאות הנוספות האלה (למשלdns.changes.createו-dns.managedZones.get) נחוצות לניהול הכולל של האזור ולביצוע בדיקות של דרישות מוקדמות כשמשנים רשומות.
מתן הרשאות
כדי לוודא שהמדיניות המותנית פועלת כמצופה, צריך להקצות את התפקידים האלה לחשבון המשתמש באופן הבא:
- הקצאת התפקיד המשני ללא תנאי: מקצים את התפקיד שמכיל את הרשאות האדמין שנותרו (לדוגמה,
DnsNonRecordSetAdmin) לחשבון הראשי ללא תנאי באזור המנוהל. - הקצאת התפקיד לניהול קבוצות רשומות באופן מותנה: מקצים את התפקיד שמכיל את ההרשאות לקבוצות רשומות (לדוגמה,
DnsRecordSetAdmin) לחשבון המשתמש באופן מותנה בהתאם לדרישות הגישה הספציפיות שלכם.
תנאים לדוגמה
בדוגמאות הבאות אפשר לראות איך מגבילים את הגישה באמצעות המאפיינים resource.name ו-resource.type.
אם אתם משתמשים בשיטה 1 (תפקיד רגיל), אתם צריכים להוסיף את הסעיף המתאים שאינו קשור לערכת רשומות (לדוגמה, || (resource.type != 'dns.googleapis.com/ResourceRecordSet')) לביטויים האלה.
התאמה מדויקת של רשומת A: מתן הרשאה לניהול רק של רשומת A עבור
api.example.com..- תפקידים בהתאמה אישית / תנאי גולמי:
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.endsWith('/rrsets/api.example.com./A')) - תפקיד רגיל (מתירני):
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.endsWith('/rrsets/api.example.com./A')) || (resource.type != 'dns.googleapis.com/ResourceRecordSet') - תפקיד רגיל (מוגבל):
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.endsWith('/rrsets/api.example.com./A')) || (resource.type == 'dns.googleapis.com/Change')
- תפקידים בהתאמה אישית / תנאי גולמי:
הענקת הרשאות לתת-דומיין: הענקת הרשאה לניהול כל הרשומות בתת-הדומיין
p.example.com..- תפקידים בהתאמה אישית / תנאי גולמי:
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.extract('/rrsets/{name}/').endsWith('.p.example.com.')) - תפקיד רגיל (מתירני):
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.extract('/rrsets/{name}/').endsWith('.p.example.com.')) || (resource.type != 'dns.googleapis.com/ResourceRecordSet')
- תפקידים בהתאמה אישית / תנאי גולמי:
ניהול כל הרשומות מסוג מסוים: מעניק הרשאה לניהול כל הרשומות מסוג
Aבאזור.- תפקידים בהתאמה אישית / תנאי גולמי:
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.endsWith('/A')) - תפקיד רגיל (מתירני):
none (resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.endsWith('/A')) || (resource.type != 'dns.googleapis.com/ResourceRecordSet')
- תפקידים בהתאמה אישית / תנאי גולמי:
קבלת מדיניות IAM עבור אזור מנוהל
כדי לקבל את מדיניות IAM של אזור מנוהל ספציפי, צריך לפעול לפי השלבים הבאים.
gcloud
מריצים את הפקודה gcloud dns managed-zones get-iam-policy:
gcloud dns managed-zones get-iam-policy NAME
מחליפים את NAME בשם של האזור המנוהל שרוצים לקבל את מדיניות ה-IAM שלו.
אם הפקודה הזו פועלת בהצלחה, היא מחזירה את מדיניות IAM. אחרת, תוחזר הודעת שגיאה עם פירוט השגיאה.
API
שולחים בקשת POST באמצעות השיטה managedZone.getIamPolicy:
POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/ManagedZone:getIamPolicy
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: השם או המזהה של הפרויקט -
MANAGED_ZONE: השם של האזור המנוהל שעבורו רוצים להגדיר את הרשאת ה-IAM
בדיקת הרשאות IAM לאזור מנוהל
שולחים בקשת POST באמצעות השיטה managedZone.testIamPermissions:
POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/ManagedZone:testIamPermissions
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: השם או המזהה של הפרויקט -
MANAGED_ZONE: השם של האזור המנוהל שרוצים לבדוק את הרשאת ה-IAM שלו
המאמרים הבאים
- כדי לעבוד עם אזורים מנוהלים, אפשר לעיין במאמר בנושא יצירה, שינוי ומחיקה של אזורים.
- כדי למצוא פתרונות לבעיות נפוצות שאתם עשויים להיתקל בהן במהלך השימוש ב-Cloud DNS, אפשר לעיין במאמר בנושא פתרון בעיות.
- לסקירה כללית על Cloud DNS, ראו סקירה כללית על Cloud DNS.