OCI - IAM I

 IAM Identity and Access Management Service - שירות ניהול זהויות וגישה מאפשר שליטה ובחירה בסוג הגישה לקבוצות משתמשים למשאבים ספציפיים ובסוגי גישה שונים. IAM משתמש במושגי זיהות מוכרים כמו 

Principals -  Users, Groups, Authentication, Authorization וכן ביכולת חדשה הנקראת Compartment 
להרחבה - סרטון מצויר על IAM

Resource (משאב) - הוא אובייקט ענן (cloud object) שאנו יוצרים ומשתמשים בתשתית הענן של אורקל (OCI).

OCID -  לכל משאב בענן יש מזהה ייחודי (Oracle Cloud ID)

כמו שניתן לראות בתרשים מטה Principals, מנהלים את הקבוצות והמשתמשים או הinstances הם אלו שזקוקים להרשאות Permissins כשההרשאות ניתנות לפי כללים, מדיניות Policies שבנויים תחת Compartment שאחראי על המשאבים.

מתוך ערוץ Youtube של Oracle Learning

Principals - 

• Principal יישות IAM שמאפשרת אינטראקציה עם משאבי OCI (למשל - compute instances, block volumes, or virtual cloud networks)
• ישנם שני סוגי Principals
• IAM users - משתמשי OCI קבועים או אפליקציות, כשהמשתמש הראשון במערכת הוא Administrator שמגדיר את שאר המשתמשים והקבוצות. לנ"ל ישנם שני עקרונות אבטחה שחייבים להתקיים אחרת משתמשים לא יהיו יכולים לעשות דבר במסגרת תשתית הענן של אורקל:
• למשתמשים אין הרשאה עד שהם ממוקמים בקבוצה אחת או יותר.
• לקבוצה תהיה לפחות מדיניות אחת הכוללת הרשאות
• Group - אוסף משתמשים שכולם זקוקים לאותו סוג גישה למערכת משאבים מסוימת. ניתן ליצור כל סוג של קבוצה. (כשמשתמש יכול להיות חבר במספר קבוצות.
• Instance Principal - מאפשר בעצם למופעים ויישומים הפועלים באותם מופעים לבצע פניות דרך API כנגד שירותי OCI אחרים. למשל יישום שפועל וצריך ללכת לגשת לשכבת האחסון (storage layer) ה Instance Principal יאפשר ליישום לפנות ב API ללא צורך בהגדרת של אישור למשתמש.

Authentication -אימות

• שם משתמש וסיסמא למשתמשים
• API Signing Key - בעת שימוש בשירות OCI API, בשילוב עם ה- SDK או CLI  כשאנו מריצים פקודות הפעלה מול המערכת בcommand-line interface) CLI) , אנו נדרשים לאימות באמצעות מפתח ה API שבנוי מצמד מפתחות RSA בפורמט PE
• Auth tokens - מחרוזות tokens שמיועדות לאימות מול משתמשי API של צד שלישי, שלא תומכים באימות מבוסס חתימה למשל במערכות מידע אוטונומיות (autonomous data warehouse) שלא ניתן להגדיר בהן API Signing Key בכל שלב לכן נגדיר Token לפעולה ספציפית.

Authorization -הרשאות

• הפעולות הניתנות לבצע על ידי Principal , ברמת groups (ולא ברמת משתמש).
• OCI authorization  - מוגדר על ידי מתן הרשאות סצפציפיות (privileges) בתוך הגדרת מדיניות (policies) ושיוך ה policies ל - principals.

Policies

•  ייכתב בפורמט הבא -

Allow <subject> to <verb> <resource-type> in <location>

• subject  - במקרה שלנו Groups
• verb - ישנן 4 אפשרויות
•  Inspect - מאפשר רישום משאבי ענן resources וקריאה
•  read - מאפשר קריאה כמו Inspect אך גם נגישות גדולה יותר למשל למטה דאטה של קבצים.
• use - קריאה, כתיבה ושימוש ב resources.
• manage - מתן הרשאות ל resources.
• אם נרצה לתת הרשאה כוללת נציין בשדה זה את סוג ה resource הכולל - All-resources
• מדיניות ההרשאות כברירת מחדל מונעת כל פעולה מצד המשתמש, אלא אם ניתנה הרשאה.
  להדגמה ב OCI לחצו כאן
• דוגמאות ל Policies נפוצים
• הרשאה לקבוצת מנהלי הרשת לנהל את הרשת בענן תכתב כך :
Allow group NetworkAdmins to manage virtual-network-family in tenancy


• הרשאה למשתמשים לשימוש במופעי חישוב (compute instances) להלן מספר דוגמאות :
Allow group InstanceLaunchers to manage instance-family in compartment ABC
Allow group InstanceLaunchers to read app-catalog-listing in tenancy
Allow group InstanceLaunchers to use volum-family in compartment ABC
Allow group InstanceLaunchers to use virtual-network-family in compartment XYZ


• Advanced policy syntax כמו התחביר שראינו מעלה אך בליווי תנאי :
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
• התנאי יכול להכיל שני סוגי משתנים Request, משתנה שמיוחס לבקשה עצמה למשל בהינתן API נגדיר את התנאי על request.operations.
  המשתנה השני הוא Target, שמתייחס למשאבי/ם (resources) במקרה כזה נגדיר לדוג' Target.group.name.
  כפי שניתן לראות בשתי הדוגמאות נגדיר את המשתנה עם קידומת על פי הסוג target או request.
• בדוגמא הזו 
  Allow group Phoneix-Admins to manage all-resources in tenacy where request.region='phx'
  המנהלים של פיניקס יכולים לנהל את כל resources אבל רק באזור phx של פיניקס ולא בשאר האזורים.


• להדגמה בסרטון על הגדרת Policies ב OCI

Compartment

• תא הוא אוסף של משאבים קשורים ( VCN, instances, ..) אליהם ניתן לגשת רק על ידי קבוצות שקיבלו הרשאה (על ידי מנהל מערכת בארגון שלך)
• התאים עוזרים לארגן ולשלוט בגישה למשאבים שלנו.
• שיקולי עיצוב:
• כל resource שייך לcompartment  אחד אך ניתן לחבר / לשתף resources בין תאים (VCN ורשתות המשנה שלו יכולות לחיות בתאים שונים)
• ניתן למחוק compartment לאחר היצירה או לשנות את שמו
• בCompartments  יכולים להיות compartments  משנה שיכולים להיות עד שש רמות.
• לא ניתן להקצות resource לcompartment  אחר לאחר היצירה (יוצא מן הכלל: Buckets)
• לאחר יצירת compartment, יש להגדיר לפחות policy אחד עבורו, אחרת לא ניתן לגשת אליו (למעט על ידי מנהלים או משתמשים שיש להם הרשאה לtenancy)
• Sub compartment יורש הרשאות גישה מתאים הגבוהים יותר בהיררכיה שלו
• כשיוצרים policy, יש לציין לאיזה compartment לצרף אותה

מתוך הסרטון

• בחיבור הראשוני ל OCI, אנחנו במצב של tenancy, שבו אנחנו ב root compartment האב העליון של כל התאים שניצור. אנחנו יוצרים משתמש ראשוני Default administrator  שהוא חלק מקבוצה (שלא ניתן למחוק) בשם Administrators שלא יכולה להיות ריקה וחייבת להכיל משתמש אחד לפחות.
• Tenancy Policy gives Administrators group access to all resources ואי אפשר לשנות את המדיניות בקבוצה זו.
• לחברים בקבוצה Administrators  יש full access to all the resources.
• Root compartment - יכול להכיל את כל ה resources שלנו.
  ה Best practice הוא לחלק את הresources  בין תאים ייעודים ולא להציב את כולם ב root
• Compartment Quotas
• בדומה ל  service limits שמוגדרים על ידי Oracle בשירותים, compartment quotas מוגדרים על ידי Admins על ידי שימוש ב policies. משמש בד"כ להגבלת זלילת משאבים לדוג' נניח שאנו משתמשים ב bare-metal instances אך הם יקרים ולכן נרצה להגביל אותם למשל לאזור ספציפי.
  נכתוב כך - zero compute quotas /*bm*/ in teanacy
• ישנם שלושה סוגי תחביר
• Set - הגדרת מספר מירבי של resources
• Unset - איפוס מגבלות ברירת המחדל 
• Zero  - הגבלת גישה  remove access to a cloud resource
• להדגמה בסרטון על הגדרת Compartment ב OCI