OCI - IAM II

 Policy Inheritance

• עקרון הירושה (Concept of inheritance) :
• Compartments יורשים כל policies מ compartment האב, כך למשל קבוצת Administrators שמוגדרת להרשאה כוללת ב root מקבלת אוטו' את ההרשאה הכוללת בתאים הבנים ואין צורך להגדיר את policies בכל תא בן, נכד, נין...
• עקרון Attachment - 
• כשיוצרים policy חובה לצרף אותה לcompartment  (או לtenancy). המיקום ישפיע על מי שישלוט בו ויוכל לשנות אותו או למחוק אותו.
  נצרף אותו לtenancy (תא שורש root compartment), ואז כל מי שיש לו גישה לניהול מדיניות בtenancy יכול לשנות או למחוק אותו.
  אם נצרף לתא ילד, כל מי שיש לו גישה לניהול המדיניות בcompartment זה (למשל מנהלי הcompartment) יכול לשנות או למחוק אותו.
• לדוג' אם יש לנו רצף של tenancy תחתיו compartment A תחתיו compartment B תחתיו compartment C
• אם נגדיר ב C או B - יאפשר לקבוצה שלה נגדיר את הרשאות הpolicy להגדיר ולשנות ב B/C
• אם נגדיר ב A - יאפשר לקבוצה שלה נגדיר את ההרשאות להגדיר ולשנות ב A,B,C ורק המנהלים של A יוכלו לשנות.
• אם נגדיר ב tenancy - יאפשר שליטה מלאה בכל הרמות.

Moving Compartments

• העברת תא לתא הורה אחר - ניתן להעביר תא, תחת תא הורה אחר באותו שכירות. כשמעבירים compartment , כל התוכן שלו (תאי משנה ומשאבים) מועבר איתו.
• מגבלות :
• לא ניתו להעביר תא לתא יעד בשם זהה לתא המועבר
• שני תאים באותו הורה לא יכולים להיות בעלי אותו שם. לכן אינך יכול להעביר תא לתא יעד בו כבר קיים תא בשם זהה.
• Policies המציינת את היררכיית התא עד לתא המועבר תתעדכן אוטומטית כאשר הPolicies תחובר לאב קדמון (ancestor) משותף של ההורה הנוכחי והיעד
• Policy המצורפת ישירות לתא שהועבר אינה מתעדכנת אוטומטית.
• דוגמאות לנ"ל כאן

Tags

• שני סוגי תגים נתמכים ב OCI
• Free form tags - יישום המורכב באופן בסיסי מ key ו value
  לדוג' אנחנו יכולים להגדיר למשל Instance בkey בשם environment את התגproduction
  ובתג נוסף עם הkey שהוא project נגדיר ערך למשל - Alpha.
  פשוט, חופשי וקל להגדרה.
• Define Tags - יותר תכונות, יותר שליטה בתגיות מוגדרות על ידי מרחב שמות שמוגדר מראש בשם Tag Namespace ועל ידי כך לשלוט בהגדרות אבטחה לפי תגים.
• Tag Namespace - 
• a container for set of tag keys with tag key definitions
• לא ניתן למחוק key definition או tag namespace 
• ניתו להפעיל מחדש מרחב שמות של תגיות או הגדרות מפתח של תגים שהופסקו בכדי להחזיר את השימוש בו ל tenancy.
• עבודה עם Define Tags
• נגדיר לפי Namespace, Key ו value
• יש להגדיר את Namespace ואת הkeys  ב tenancy לפני שהמשתמשים יחילו אותם.
• tag key יכול להכיל tag value type של srting או של רשימת ערכים (list pf value) שמהם המשתמש צריך לבחור.
• ניתן להשתמש במשתנים כדי להגדיר value של תג, כשנצרף את התג לresourceת המשתנה יכיל את הנתונים שהוא מייצג למשל

• Operations.CostCenter = ${iam.principal.name} at ${oci.datetime}

Operations is the namespace,
CostCenter is the tag key
 tag value contains two tag variables ${iam.principal.name} and ${oci.datetime}

• כשנוסיף תג זה לresouce, הvariable מחליף לשם המשתמש (שם המנהל שהחיל את התג) ומוסיף חותמת תאריך זמן לתג.
• להדגמה ב OCI לחצו כאן
• דוגמא להגדרת הרשאות ואבטחה באמצעות תגים - 
  Allow group InstanceLaunchers to use tag-namespaces in compartment A where target.tag-namespace.name='Operations

לסיכום IAM

• IAM Principals - משתמשי IAM וInstance Principals
• Authentication - שם משתמש / סיסמה, API Signing keys, Auth Tokens
• Authorization -  (מדיניות) Policies ו - השיוך שלהם עם Principals
• Policies syntax and examples of advanced policies 
• Compartment, a unique OCI feature, can be used to organize and isolate related cloud resources
• Concept of Policy Inheritance and Attachment for compartments
• OCI supports both free form tags and defined tags with a schema and secured by policies
  
  פלייליסט IAM ב Youtube

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