Avishay Saban
Cloud Solutions Architect
(OCI Identity & Access Management (IAM

אחד השירותים המעניינים והחשובים בOracle Cloud Infrastructure (OCI)  הוא שירות ה Identity & Access Management (או בקיצור ה-IAM) – שתפקידו לנהל את ההזדהות וההרשאות ב-Tenancy  (חשבון הענן).

נושא מדיניות האבטחה וההרשאות בענן הוא נושא לא פשוט המאתגר חברות רבות בתחילת דרכן בענן. במאמר זה אכיר לכם את הדרכים להגדרה של מדיניות גישה והרשאות ברורה תוך חלוקה של ההרשאות בין קבוצות שונות, ואסביר כיצד רכיב ה- Compartments  (שיוסבר בהמשך) מביא ערך מוסף לניהול היררכי מאורגן. בהמשך, נבחן קצת case studies ונכיר דרכם כמה "כללי אצבע", ובין היתר נדבר על כמה חשוב לאמץ סדר וארגון בענן אשר מתבצע ב OCI באמצעות Tagging.

אז נתחיל בהסבר מפורט יותר על שירות ה- Identity and Access Management (IAM) ב OCI:

שירות ה-IAM מאפשר לנו לקבוע מי יכול לגשת לחשבון OCI, באילו שירותים ומשאבים הוא יוכל להשתמש וכיצד יוכל להשתמש במשאבים אלה. המשאב הוא למעשה אובייקט בענן שיוצרים ומשתמשים בו ב OCI (לדוגמא, מכונות וירטואליות, Block Storage Volumes, Virtual Cloud Network).

לשירות ה-IAM ישנם כמה מרכיבים בסיסיים שהם חלק בלתי נפרד ממנו:

  • Principals
  • Authentication
  • Authorization
  • Policies
  • Tenants and Compartments

ה Principal היא ישות בIAM  המאפשרת אינטרקציה עם כל המשאבים שברצוני לייצר ב OCI, כאשר ישנם שני סוגים של Principals: סוג אחד הוא  IAM Users and Groupsוהסוג השני הוא Instance Principals.

הסוג הראשון, משתמשים וקבוצות: כאשר משתמש נרשם לראשונה לענן הוא נוצר כברירת מחדל כ User בשם Administrator שאותו לא ניתן לשנות. משתמש זה הוא למעשה "Super User" עם הרשאות מלאות בחשבון. עם המשתמש הזה אני יכול להתחיל ליצור משתמשים רלוונטים אחרים ולצרף אותם תחת קבוצה מסוימת (או כמה קבוצות) שתהיה אחראית על משאבים מסוימים.

הסוג השני, Instance Principals: מאפשר למכונות ואפליקציות ליצור קריאות API מול שאר השירותים ללא צורך בהגדרת הרשאות משתמשים, וללא צורך ביצירה ידנית ושמירה של מפתחות הצפנה.

שירות ה-IAM מבצע Authentication על גבי ה Principals באמצעות שם משתמש וסיסמא בכניסה לWeb console וזאת על ידי סיסמא ראשונית חד פעמית, שאותה מחליפים בסיסמא קבועה, או לחילופין באמצעותAPI Signing Key: להבדיל מהכניסה הרגילה לענן דרך שם משתמש וסיסמא – כאן אני מבצע חתימה דיגיטילת ומאפשר גישת קבע דרך קריאות מול ה API כאשר משתמשים ב SDK/CLI.

הנה דוגמא למסך שבו נדרש המשתמש להכניס את המפתח הציבורי שלו בעת יצירה של משאב OCI שמולו ירצה המשתמש להזדהות בהמשך:

Authorization

השלב הבא, לאחר שהוגדרו המשתמשים וחולקו לקבוצות, הוא מתן הרשאה נכונה לקבוצה מסוימת. לדוגמא, נרצה להגדיר שקבוצת המשתמשים במחלקת ה-Networking תוכל לקבל גישה למשאבים של VCN (Virtual Cloud Network). ב OCI ההרשאות למשאבים מחולקות לקבוצות, ובהמשך אנו נראה מספר דוגמאות.

כדי לאפשר את הרשאות הגישה המתאימות נגדיר מדיניות (Policy) המורכבת מחוקים (Rules) עפ"י התבנית בדוגמאות הבאות:

Allow group <group_name> to <verb> <resource-type> in tenancy

[<Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name> [where <conditions

ברגע שהוחל סט החוקים הרלוונטיים (המדיניות) – המשתמשים יכולים להשתמש במשאבי חשבון הענן אך ורק בהתאם למדיניות שנקבעה. החלה של מדיניות מתבצעת ברמה של Compartment או של Tenancy. חשוב לציין כאן שלא ניתן להחיל מדיניות על IAM User אלה רק על IAM Groups , ולכן הדרך היחידה לאפשר למשתמש הרשאות היא לשייך אותו לקבוצה מסויימת.

האיור הבא מפרט את הסינטקס להגדרת חוקי המדיניות ב OCI:

Verb (משמאל) מגדיר רמות שונות של גישה למשאב.

 Resource-types(מימין) מגדירים באילו משפחות של משאבים ותתי-משאבים ניתן להשתמש עפ"י החוק המסוים.

רמות הגישה השונות למשאב הן:

רמת הגישה הנמוכה ביותר למשאב היא לקרוא רק את ה MetaData  שלו, הרמות הבאות הן קריאה שלו, שימוש בו ולבסוף שליטה מלאה על המשאב (כולל יצירה וביטול שלו). כל ההרשאות הללו יכולות להנתן ברמת ה Compartment  או ה Tenancy.

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

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

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

allow group Admins to manage all-resources in tenancy

הרשאה לקבוצת המנהלים לנהל את כל המשאבים בחשבון (למעשה לעשות הכל – SuperUser)

allow group NetworkAdmins to manage virtual-network-family in tenancy

הרשאה לקבוצת ה NetworkAdmins לנהל את כל משאבי ה  Virtual network family, הכולל את כל המשאבים הרלוונטיים לנושא הרשת (ראו בטבלה למעלה).

allow group HRAdmins to use instance-family in compartment HR

הרשאה לקבוצת ה HR להשתמש במשאבים מה Instance family, וברמת הCompartment  של HR בלבד.

ניתן לתת הרשאה גם ברמת משאב יחיד, באופן הבא:

allow group NetworkAdmins to manage subnet in compartment Marketing

הרשאה ל  NetworkAdminsלנהל את ה subnets ברמת הCompartment  של ה Marketing.

allow group HRAdmins to volume-attachments in compartment HR

הרשאה לקבוצת HRAdmins לבצע attachment לאחסון חיצוני בcompartment  HR.

allow group ServerAdmins to read objects in compartment IT

הרשאה לקבוצת ServerAdmins  לקרוא אובייקטים ב compartment  IT.

Tenants and Compartments

הרעיון מאחורי החלוקה של Tenants and Compartments מאוד מזכיר את מערכת הפעלה לינוקס, כאשר הRoot  הוא השורש בהיררכיה. במקרה הנל הRoot הוא ה Tenancy ומתחתיו ישנה חלוקה למספר סביבות, כאשר סביבות אלה נקראות Compartments.

באמצעות הCompartments  נוכל לבצע חלוקה לוגית של החשבון שלנו לסביבות מבודדות זו מזו. מי שיוצר אותם ונותן הרשאות וגישה אליהם הוא ה Admin של החשבון ב OCI.

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

מה קורה כאשר נרשמים ל OCI?

התמונה מציגה מה קורה כאשר אנו נכנסים בפעם הראשונה לחשבון הענן שלנו ב OCI. דבר ראשון אנו יוצרים חשבון Tenancy name חדש מתחתיו נמצא הroot compartment. מעליו נוצר כברירת המחדל משתמש Admin כאשר הוא כבר משוייך לקבוצה ה Admin עם חוק שמאפשר למשתמש הזה לעשות הכל בחשבון.

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

כל פעילות שלנו בחשבון הענן מחייבת בחירה של ה Compartment שבתוכו אנו פועלים – וכמובן צריכות להיות לנו ההרשאות המתאימות לפעול בו.

במסכי ה Console הבחירה של ה Compartment נראית כך

העולם האמיתי של Compartments

בוא נבחן מקרה של מימוש מבנה מסודר באמצעות Compartments ונבין מה עשינו בכך.

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

ההסבר הוא משמאל לימין.

  • תחילה כברירת המחדל ישנה קבוצת הAdministrators כאשר החוק עבורה (בצבע כתום למטה משמאל) מאפשר למנהלים ליצור כל דבר
  • לאחר מכן ה Admin User יצר את קבוצת ה NetworksAdmin ושייך לקבוצה משתמש בשם John, ולקבוצה הזאת יש Compartment בשם Networks. החוקים שהוגדרו על ה Compartment  הם לאפשר ראשית לקבוצה לנהל את כל מה שקשור למשפחת משאבי הVirtual-network ב Compartment הNetworks. החוק השני מאפשר לקבוצת ה NetworksAdmin לנהל את גם את משפחת הInstances כדי ליצור מכונות ב  Networks Compartment.
  • אחריו המנהל יצר עוד קבוצה בשם A-Admins כאשר שם המשתמש שם הוא Tom, לקבוצה זאת הוא יצר Compartment בשם A-project. החוקים שהוגדרו וחלו על A-project הם לאפשר לקבוצה של A-Admins הרשאה מסוג Use כלומר להשתמש במשאבי ה Compartment Networks . בנוסף חל חוק שאומר שלקבוצת A-Admins הרשאות מלאות לבצע הכל ב Compartment שלה, שהוא A-Project.

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

John ממחלקת Networks יצר VCN (רשת וירטואלית) תחת הקבוצה שלו, המשוייך ל Compartment Networks, אך הוא אינו רשאי לבטל, למחוק או ליצור מכונות ב A-project Compartment.

Tom שהוא מקבוצת ה A-Admins יצר מכונות המשתמשות ב-VCN של Network Compartment אך הוא לא יכול ליצור מכונות תחת Compartment Network.

בסיפור המקרה הזה אנו רואים שיתוף בין שתי מחלקות, כאשר מחלקה אחת מייצרת משאבים עבור שימוש של מחלקה אחרת.  Tom יוצר את המכונות שלו על גבי ה VCN ש John מקבוצת ה Networking יצר בCompartment שלה. Tom אינו יכול להגדיר או לשנות רשתות – רק להשתמש בהן.  John אינו יכול ליצור מכונות בפרוייקט של Tom, אלא רק להגדיר ולנהל עבורו את הרשתות.

 

פריסה גאוגרפית של שירות ה IAM

שירות ה IAM מנוהל ברמה הקולקטיבית הגלובלית, כלומר גם אם שירותי הענן שאנו צורכים מפוזרים בין איזורים גאוגרפים שונים בענן, אותן ההגדרות חלות על כל האזורים. כלל זה חל על כל סוגי המשאבים בשירות ה IAM: compartments, users, groups, and policies.

האיור הבא מציג דוגמא של פריסה של Compartment אחד בין 3 אזורים גאוגרפיים (Regions) שונים ב OCI:

 

Home Region – הוא האיזור אשר נבחר להשתמש בו בכניסה הראשונה לחשבון. לא ניתן לשנות את ה Home Region, אך תמיד ניתן לבצע subscription לאיזורים גיאוגרפיים (Regions) נוספים, כמודגם באיור הבא:

OCI Tagging

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

לדוגמא, אם לחברה (בייחוד חברות גדולות) ישנן 20 מכונות עם אותו Shape החברה תרצה לדעת מה השימוש והמטרה של אותה מכונה ספציפית ומי משתמש בה, האם היא שייכת לקבוצת QA או קבוצת ה- .DEVכדי לאפשר זאת ניתן לתייג את המכונות השונות בעת יצירתן. סיבה נוספת להשתמש ב Tagging היא קבלת תמונה ברורה יותר של חלוקת החשבון הכולל, לדוגמא מהו החלק של כל משאבי האחסון מתוך חשבון הענן הכולל, ללא הקשר לשיוך המחלקתי של משאבי האחסון.

Federation

נושא הFederation הוא חלק בלתי נפרד מה IAM ב OCI, כאשר ישנה אופציה להשתמש ב  Identity Providers חיצוניים ל OCI שכבר זיהו את המשתמשים, ובכך לממש מנגנון של SSO.

שירותי ניהול הזהויות הנתמכים כיום ב OCI Federation הם  Microsoft ADFS ו  Oracle IDCS.

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

לסיכום

  • Identity and Access Management Service (IAM) מאפשר שליטה מלאה על המשתמשים והגדרה של הרשאות בחשבון הOCI.
  • IAM service Principals – מכיל בתוכו את Users/Groups, Instance Principals.
  • Authentication– מתבצע דרך שם משתמש\ססמא ו API Signing Key
  • Authorization– מתבצע על ידי הגדרת מדויקת של הרשאות המשתמש בחוקים של מדיניות והחלה של המדיניות על ידי סינטקס ברור.
  • סט החוקים מוגדר באמצעות סינטקס Human readable שהוא ברור ומאוד קל להבנה
  • Compartment– תכונה ייחודית ל OCI המאפשרת ארגון משאבים והפרדה מוחלטת של סביבות תחת אותו החשבון
  • תמיכה מלאה ב OCI Tagging והמשמעות מאחוריה.
  • תמיכה בFederation עם ADFS וIDCS  של אורקל.

מקווה שבפוסט זה ניהנתם לקרוא על שירות הIAM של OCI .

לינקים רלוונטים:

  • מידע מלא על IAM ניתן למצוא כאן בתיעוד של OCI וגם White paper כאן.
  • 300 דולר חינם או 3500 שעות, למי שנרשם ורוצה להתנסות. זה הזמן ! זה לא עולה לכם כסף …

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

אבישי סבן יועץ וארכיטקט ענן אורקל ישראל

 

Share on FacebookShare on LinkedInTweet about this on Twitter
(OCI Identity & Access Management (IAM Reviewed by on . אחד השירותים המעניינים והחשובים בOracle Cloud Infrastructure (OCI)  הוא שירות ה Identity & Access Management (או בקיצור ה-IAM) – שתפקידו לנהל את ההזדהות והה אחד השירותים המעניינים והחשובים בOracle Cloud Infrastructure (OCI)  הוא שירות ה Identity & Access Management (או בקיצור ה-IAM) – שתפקידו לנהל את ההזדהות והה Rating: 0

הגיבו באמצעות פייסבוק

scroll to top
%d בלוגרים אהבו את זה: