במאמר הזה מוסבר איך להשתמש בניהול זהויות והרשאות גישה (IAM) כדי לנהל את בקרת הגישה למשאבים ב-Knowledge Catalog (לשעבר Dataplex Universal Catalog). IAM שולט בגישה למשאבים של Knowledge Catalog ב Google Cloud רמת המשאב. באמצעות Google Cloud המסוף, Google Cloud CLI, ספריות לקוח או ממשקי API, אפשר לקבוע אילו גורמים יכולים לנהל משאבים ספציפיים, כמו קבוצות ורשומות של רשומות.
מידע נוסף על IAM זמין במאמרי העזרה בנושא IAM.
סקירה כללית על IAM
כשיוצרים פרויקט חדש Google Cloud , יוצר הפרויקט המקורי מקבל את התפקיד 'בעלים'. יכול להיות שקיימים או שייווצרו חשבונות שירות אחרים שמנוהלים על ידי Google כשתפעילו API כדי לבצע משימות ספציפיות. עם זאת, לאף משתמש פרטי אחר אין גישה לפרויקט ולמשאבים שלו, כולל משאבים של Knowledge Catalog. הגישה הזו ניתנת רק כשמוסיפים משתמשים באופן מפורש כחברים בפרויקט או כשנותנים להם תפקידים במשאבים ספציפיים.
בעזרת IAM תוכלו לתת גישה פרטנית למשאבים ב- Google Cloudולמנוע גישה למשאבים אחרים. בעזרת IAM אתם יכולים לשמור על עקרון האבטחה של הרשאות מינימליות, וכך לתת למי שצריך רק את רמת הגישה הדרושה למשאבים השונים.
בעזרת IAM תוכלו לקבוע למי (חשבונות משתמשים) יש הרשאות גישה (תפקידים) לאילו משאבים.
חשבון משתמש
חשבון משתמש יכול להיות חשבון Google (למשתמשי קצה), חשבון שירות (לאפליקציות ולמכונות וירטואליות), קבוצה ב-Google, דומיין ב-Google Workspace או דומיין ב-Cloud Identity. למשתמשים האלה יש גישה למשאב. כשמעניקים תפקידים, צריך לזהות את החשבון באמצעות מזהה, כמו שמתואר במאמר הפניה לקישור מדיניות.
מידע נוסף מופיע במאמר סקירה כללית על IAM: חשבונות משתמשים.
סוכן השירות
ב-Knowledge Catalog נעשה שימוש ב Google Cloud חשבון שירות מנוהל, סוכן שירות, כדי לגשת למשאבים שלכם. סוכני שירות הם חשבונות שירות שמנוהלים על ידי Google ומאפשרים לשירותים לגשת למשאבים בפרויקט שלכם. Google Cloud זה שונה מחשבונות שירות בניהול המשתמשים, שאתם יוצרים ומשתמשים בהם כדי לייצג את האפליקציות או עומסי העבודה שלכם.
סוכן השירות נוצר כשמפעילים את Dataplex API. אפשר לזהות את סוכן השירות לפי מזהה האימייל שלו:
service-CUSTOMER_PROJECT_NUMBER@gcp-sa-dataplex.iam.gserviceaccount.com
CUSTOMER_PROJECT_NUMBER הוא מספר הפרויקט שבו הפעלתם את Dataplex API.
סוכן השירות צריך את התפקיד Dataplex Service Agent (roles/dataplex.serviceAgent) בפרויקט כדי לנהל משאבים של Knowledge Catalog. כשמפעילים את ה-API, המערכת מעניקה את התפקיד הזה באופן אוטומטי. אם תבטלו את התפקיד הזה, יכול להיות ש-Knowledge Catalog לא יפעל כמו שצריך.
אם ל-Knowledge Catalog נדרשת גישה למשאבים בפרויקטים אחרים (לדוגמה, קטגוריות של Cloud Storage או מערכי נתונים ב-BigQuery שרוצים לצרף כנכסים או לסרוק כדי ליצור פרופילים של נתונים), צריך להעניק לסוכן השירות הזה את ההרשאות הנדרשות בפרויקטים שמכילים את המשאבים האלה.
מידע נוסף על מתן הרשאות לסוכן השירות לצירוף נכסים זמין במאמר ניהול נכסי נתונים.
מידע נוסף על הענקת הרשאות לסוכן השירות לצורך יצירת פרופיל נתונים זמין במאמר יצירה ושימוש בסריקות של פרופיל נתונים.
זהות הביצוע לסריקות נתונים
כברירת מחדל, Knowledge Catalog משתמש בסוכן השירות כדי להריץ את הסריקות של איכות הנתונים ופרופיל הנתונים. עם זאת, אתם יכולים לבחור לבטל את ההתנהגות הזו ולהריץ סריקות באמצעות חשבון שירות בהתאמה אישית או באמצעות פרטי הכניסה של משתמש הקצה שלכם (EUC).
אם מציינים חשבון שירות בהתאמה אישית לזהות הביצוע של הסריקה, לסוכן השירות צריך להיות התפקיד Service Account Token Creator (roles/iam.serviceAccountTokenCreator) (או ההרשאה iam.serviceAccounts.getAccessToken) בחשבון השירות המיועד כדי להתחזות אליו ולהריץ את העבודה. פרטים נוספים מופיעים במסמכי התיעוד בנושא זהות הביצוע של איכות הנתונים ופרופיל הנתונים.
משאב
המשאבים שאפשר להעניק להם גישה ב-Knowledge Catalog כוללים פרויקטים, קבוצות רשומות, רשומות, קישורי רשומות, סוגי היבטים, סוגי רשומות וסוגי קישורי רשומות.
חלק מהשיטות ב-API דורשות הרשאות למספר משאבים. לדוגמה, כדי לצרף היבט לרשומה, נדרשות הרשאות גם לרשומה וגם לסוג ההיבט.
תפקיד
תפקיד הוא אוסף של הרשאות שקובעות אילו פעולות חשבון משתמש יכול לבצע במשאב. כשמקצים תפקיד לחשבון משתמש, מעניקים לו את כל ההרשאות שהתפקיד מכיל.
אפשר להקצות תפקיד אחד או יותר לחשבון משתמש.
בדומה למוצרים אחרים, ב-Knowledge Catalog יש תמיכה בשלושה סוגים של תפקידים: Google Cloud
תפקידים בסיסיים: תפקידים עם הרבה הרשאות (בעלים, עריכה, צפייה) שהיו קיימים לפני שהוצג IAM. מידע נוסף על תפקידים בסיסיים זמין במאמר תפקידים בסיסיים.
תפקידים מוגדרים מראש: מאפשרים גישה פרטנית למשאבים ספציפיים ב- Google Cloud. מידע נוסף על תפקידים מוגדרים מראש זמין במאמר תפקידים מוגדרים מראש. במסמכי התיעוד בנושא תפקידי IAM ב-Knowledge Catalog מפורטים התפקידים המוגדרים מראש ב-Knowledge Catalog.
תפקידים בהתאמה אישית: עוזרים לאכוף את העיקרון של הרשאות מינימליות על ידי מתן רק ההרשאות הספציפיות שנדרשות. מידע נוסף על תפקידים בהתאמה אישית זמין במאמר תפקידים בהתאמה אישית.
לדוגמה, התפקיד המוגדר מראש Dataplex Viewer (roles/dataplex.viewer) מספק גישת קריאה בלבד למשאבים של Knowledge Catalog. משתמש ראשי עם התפקיד הזה יכול לצפות בקבוצות של רשומות, ברשומות, בקישורים לרשומות, בסוגי היבטים, בסוגי רשומות ובסוגי קישורים לרשומות, אבל הוא לא יכול ליצור, לעדכן או למחוק אותם.
לעומת זאת, התפקיד Dataplex Administrator (roles/dataplex.admin) מעניק גישה רחבה לניהול משאבים ב-Knowledge Catalog.
מידע נוסף על הקצאת תפקידים זמין במאמר הענקה, שינוי וביטול של הרשאות גישה.
כדי לדעת אילו הרשאות נדרשות לביצוע משימה ספציפית, אפשר לעיין בדפי העזר בנושא תפקידים בקטלוג הידע והרשאות בקטלוג הידע.
לדוגמה, תוכלו להקצות לחשבון Google את התפקיד roles/dataplex.admin במשאב של פרויקט. לאחר מכן, החשבון יוכל לנהל את המשאבים של Knowledge Catalog בפרויקט, אבל לא יוכל לנהל משאבים אחרים. אפשר גם להשתמש ב-IAM כדי לנהל את התפקידים הבסיסיים שניתנו לחברי צוות הפרויקט.
מדיניות IAM למשאבים
מדיניות IAM מאפשרת לכם לנהל תפקידי IAM במשאבים במקום לנהל תפקידים ברמת הפרויקט, או בנוסף לניהול תפקידים ברמת הפרויקט. כך אפשר ליישם את העיקרון של הרשאות מינימליות, ולתת גישה רק למשאבים הספציפיים שהמשתפים צריכים כדי לבצע את העבודה שלהם.
המשאבים יורשים את המדיניות של משאבי ההורה שלהם. אם מגדירים מדיניות ברמת הפרויקט, היא עוברת בירושה לכל המשאבים הצאצאים. המדיניות בפועל של משאב היא האיחוד של המדיניות שהוגדרה למשאב הזה, יחד עם המדיניות שעוברת בירושה מרמות גבוהות יותר בהיררכיה. מידע נוסף זמין במאמר היררכיית מדיניות IAM.
אפשר לקבל ולהגדיר מדיניות IAM באמצעות מסוף Google Cloud , Identity and Access Management API או ה-CLI של gcloud.
- במאמר בקרת גישה באמצעות מסוףGoogle Cloud מוסבר איך עושים זאת במסוף Google Cloud .
- למידע על ה-API, אפשר לעיין במאמר בקרת גישה באמצעות ה-API.
- ב-CLI של gcloud, אפשר לקרוא את המאמר בקרת גישה באמצעות CLI של gcloud .