שימוש בבקרת גישה בממשק המשתמש של Airflow

‫Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)

בדף הזה מתוארים מנגנונים שונים של בקרת גישה לממשק המשתמש של Airflow ולממשק המשתמש של DAG. אתם יכולים להשתמש במנגנונים האלה, בנוסף לבקרת הגישה שמסופקת על ידי IAM, כדי להפריד בין משתמשים בממשק המשתמש של Airflow ובממשק המשתמש של DAG בסביבה שלכם.

סקירה כללית על בקרת הגישה לממשק המשתמש של Airflow ב-Managed Airflow

הגישה לממשק המשתמש של Airflow ולממשק המשתמש של DAG והנראות של הנתונים והפעולות בממשקי המשתמש האלה נשלטות בשתי רמות ב-Managed Airflow:

  1. הגישה לממשק המשתמש של Airflow ולממשק המשתמש של DAG ב-Managed Airflow נשלטת על ידי IAM.

    אם לחשבון אין תפקיד שמאפשר לצפות בסביבות Managed Airflow בפרויקט, ממשקי המשתמש של Airflow ו-DAG לא יהיו זמינים.

    ‫IAM לא מספק בקרת הרשאות פרטנית נוספת בממשק המשתמש של Airflow או בממשק המשתמש של DAG.

  2. מודל בקרת הגישה של Apache Airflow מאפשר לצמצם את הנראות בממשק המשתמש של Airflow ובממשק המשתמש של DAG על סמך תפקיד המשתמש.

    בקרת הגישה ב-Apache Airflow היא תכונה של Airflow, עם מודל משלה של משתמשים, תפקידים והרשאות, ששונה מ-IAM.

בקרת הגישה ב-Apache Airflow מבוססת על הרשאות לפי משאבים. כל המשתמשים ב-Airflow עם תפקיד ספציפי ב-Airflow מקבלים את ההרשאות של התפקיד הזה. לדוגמה, משתמשי Airflow שיש להם תפקיד עם ההרשאה can delete on Connections יכולים למחוק חיבורים בדף Connections בממשק המשתמש של Airflow.

אפשר גם להקצות הרשאות ברמת DAG ל-DAG ספציפיים. לדוגמה, כדי שרק משתמשים עם תפקיד ספציפי ב-Airflow יוכלו לראות DAG מסוים בממשק המשתמש של Airflow. ב-Managed Airflow, אפשר להקצות הרשאות ברמת DAG באופן אוטומטי על סמך תיקיית המשנה שבה קובץ ה-DAG ממוקם בקטגוריה של הסביבה.

לפני שמתחילים

  • ממשק המשתמש של Airflow עם בקרת גישה זמין בגרסאות Managed Airflow מגרסה 1.13.4 ואילך וב-Airflow מגרסה 1.10.10 ואילך. בנוסף, בסביבה צריכה לפעול Python 3.

  • הרשמה של תפקידים לכל תיקייה זמינה ב-Managed Airflow מגרסה 1.18.12 ואילך ב-Airflow 2, וב-Managed Airflow מגרסה 1.13.4 ואילך ב-Airflow 1.

הפעלת בקרת גישה לממשק המשתמש של Airflow

Airflow 2

ממשק המשתמש של Airflow עם בקרת גישה תמיד מופעל ב-Airflow 2.

Airflow 1

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

קטע מפתח ערך
webserver rbac True

אפשר לעשות את זה בסביבה קיימת או כשיוצרים סביבה חדשה.

בהגדרה הזו, סביבת העבודה מריצה את ממשק המשתמש של Airflow עם בקרת גישה במקום ממשק המשתמש הקלאסי של Airflow.

ניהול תפקידים והגדרות בקרת גישה ב-Airflow

משתמשים עם תפקיד אדמין (או תפקיד מקביל) יכולים להציג ולשנות את הגדרות בקרת הגישה בממשק המשתמש של Airflow.

בממשק המשתמש של Airflow, אפשר להגדיר את הגדרות בקרת הגישה בתפריט Security. מידע נוסף על מודל בקרת הגישה של Airflow, על ההרשאות הזמינות ועל תפקידי ברירת המחדל זמין במסמכי התיעוד של בקרת הגישה בממשק המשתמש של Airflow.

ב-Airflow 1, תפקיד המשתמש נחשב כתבנית לכל התפקידים המותאמים אישית. ‫Airflow מעתיק באופן רציף הרשאות מתפקיד המשתמש לכל התפקידים בהתאמה אישית, למעט הרשאות ל-all_dags.

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

רישום משתמשים בממשק המשתמש של Airflow

משתמשים חדשים נרשמים אוטומטית כשהם פותחים את ממשק המשתמש של Airflow בסביבת Managed Airflow בפעם הראשונה.

במהלך ההרשמה, המשתמשים מקבלים את התפקיד שצוין באפשרות ההגדרה [webserver]rbac_user_registration_role Airflow. אתם יכולים לשלוט בתפקיד של משתמשים חדשים שנרשמו על ידי החלפת הערך של אפשרות ההגדרה הזו ב-Airflow בערך אחר.

אם לא מציינים תפקיד, תפקיד ההרשמה שמוגדר כברירת מחדל הוא Op בסביבות עם Airflow 2 ו-3.

בסביבות עם Airflow 1.10.*, תפקיד ברירת המחדל לרישום הוא Admin.

מומלץ לבצע את השלבים הבאים כדי ליצור הגדרת תפקיד בסיסית לממשק המשתמש של Airflow:

Airflow 2

  1. אדמינים של סביבות פותחים את ממשק המשתמש של Airflow עבור הסביבה החדשה שנוצרה.

  2. מקצים לחשבונות האדמין את התפקיד Admin. תפקיד ברירת המחדל בחשבונות חדשים הוא Op. כדי להקצות את התפקיד Admin, מריצים את הפקודה הבאה ב-CLI של Airflow באמצעות ה-CLI של gcloud:

      gcloud composer environments run ENVIRONMENT_NAME \
    --location LOCATION \
    users add-role -- -e USER_EMAIL -r Admin

    מחליפים את:

    • ‫ENVIRONMENT_NAME בשם הסביבה.
    • ‫LOCATION עם האזור שבו הסביבה ממוקמת.
    • ‫USER_EMAIL עם כתובת האימייל של חשבון משתמש.

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

Airflow 1

  1. אדמינים של סביבות פותחים את ממשק המשתמש של Airflow עבור הסביבה החדשה שנוצרה, שבה הם רשומים אוטומטית עם התפקיד Admin.

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

    קטע מפתח ערך
    webserver rbac_user_registration_role ‫User או תפקיד אחר שאינו אדמין

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

משתמשים שנרשמו מראש

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

כדי לבצע רישום מראש של משתמשים, אפשר להשתמש בממשק המשתמש של Airflow או להריץ פקודה של Airflow CLI דרך Google Cloud CLI.

כדי לבצע רישום מראש של משתמש עם תפקיד מותאם אישית באמצעות Google Cloud CLI, מריצים את הפקודה הבאה של Airflow CLI:

gcloud composer environments run ENVIRONMENT_NAME \
  --location LOCATION \
  users create -- \
  -r ROLE \
  -e USER_EMAIL \
  -u USER_EMAIL \
  -f FIRST_NAME \
  -l LAST_NAME \
  --use-random-password # The password value is required, but is not used

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ENVIRONMENT_NAME: שם הסביבה
  • ‫LOCATION: האזור שבו נמצאת הסביבה
  • ‫ROLE: תפקיד Airflow של המשתמש, לדוגמה, Op
  • ‫USER_EMAIL: כתובת האימייל של המשתמש
  • ‫FIRST_NAME ו-LAST_NAME: השם הפרטי ושם המשפחה של המשתמש

דוגמה:

gcloud composer environments run example-environment \
  --location us-central1 \
  users create -- \
  -r Op \
  -e "example-user@example.com" \
  -u "example-user@example.com" \
  -f "Name" \
  -l "Surname" \
  --use-random-password

הסרת משתמשים

מחיקת משתמש מ-Airflow לא מבטלת את הגישה שלו, כי הוא נרשם מחדש באופן אוטומטי בפעם הבאה שהוא ניגש לממשק המשתמש של Airflow. כדי לבטל את הגישה לממשק המשתמש של Airflow, צריך להסיר את ההרשאה composer.environments.get ממדיניות ההרשאות של הפרויקט.

אפשר גם לשנות את התפקיד של המשתמש ל'ציבורי'. כך הרישום של המשתמש נשמר, אבל כל ההרשאות לממשק המשתמש של Airflow מוסרות.

הגדרת הרשאות ברמת ה-DAG באופן אוטומטי

התכונה 'הרשמה לתפקידים לפי תיקייה' יוצרת באופן אוטומטי תפקיד מותאם אישית ב-Airflow לכל תיקיית משנה שנמצאת ישירות בתוך התיקייה /dags, ומעניקה לתפקיד הזה גישה ברמת DAG לכל ה-DAGs שקובץ המקור שלהם מאוחסן בתיקיית המשנה הרלוונטית. כך אפשר לייעל את הניהול של תפקידים מותאמים אישית ב-Airflow ואת הגישה שלהם ל-DAG.

איך פועל רישום תפקידים לכל תיקייה

רישום תפקידים לכל תיקייה הוא דרך אוטומטית להגדיר תפקידים והרשאות ברמת DAG. לכן, יכול להיות שהיא תגרום לקונפליקטים עם מנגנונים אחרים של Airflow שנותנים הרשאות ברמת ה-DAG:

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

ב-Airflow 1, האפשרות להשתמש במנגנונים האלה מושבתת כשהאפשרות Per-folder Roles Registration (רישום תפקידים לכל תיקייה) מופעלת. כל ניהול ההרשאות ברמת DAG מתבצע רק דרך רישום תפקידים לכל תיקייה.

ב-Airflow 2 ו-3:

  • אפשר להעניק תפקידים גישה ל-DAG דרך המאפיין access_control שמוגדר בקוד המקור של ה-DAG.
  • הקצאה ידנית של הרשאות ל-DAG (דרך ממשק המשתמש של Airflow או דרך ה-CLI של gcloud) עלולה לגרום לקונפליקטים. לדוגמה, אם אתם מקצים באופן ידני הרשאות ברמת ה-DAG לתפקיד ברמת התיקייה, יכול להיות שההרשאות האלה יוסרו או יידרסו כשהמעבד של ה-DAG יסנכרן DAG. מומלץ לא להעניק הרשאות ל-DAG באופן ידני.
  • לתפקידים יש איחוד של הרשאות גישה ל-DAG שרשומות דרך Per-folder Roles Registration (רישום תפקידים לכל תיקייה) ומוגדרות במאפיין access_control של ה-DAG.

מערכות DAG שנמצאות ישירות בתיקייה ברמה העליונה /dags לא מוקצות אוטומטית לאף תפקיד ברמת התיקייה. אי אפשר לגשת אליהם באמצעות תפקיד ברמת התיקייה. תפקידים אחרים כמו אדמין, אופרטור, משתמש או כל תפקיד מותאם אישית שמוענקות לו הרשאות יכולים לגשת אליהם דרך ממשק המשתמש של Airflow וממשק המשתמש של DAG.

אם מעלים קובצי DAG לתיקיות משנה עם שמות שתואמים לתפקידים מובנים ב-Airflow ולתפקידים שנוצרו על ידי Managed Airflow, ההרשאות לקובצי DAG בתיקיות המשנה האלה עדיין מוקצות לתפקידים האלה. לדוגמה, העלאה של DAG לתיקייה /dags/Admin מעניקה הרשאות ל-DAG הזה לתפקיד Admin. תפקידים מובנים ב-Airflow כוללים את התפקידים Admin,‏ Op,‏ User,‏ Viewer ו-Public. ‫Managed Airflow יוצר UserNoDags אחרי שמפעילים את התכונה 'הרשמה של תפקידים לכל תיקייה'.

מערכת Airflow מבצעת רישום של תפקידים לכל תיקייה כשהיא מעבדת DAGs בתזמן של Airflow. אם יש יותר ממאה DAG בסביבה שלכם, יכול להיות שתהיה עלייה בזמן הניתוח של ה-DAG. אם זה המצב, מומלץ להגדיל את הפרמטר [scheduler]max_threads בסביבת Airflow 1, או את הפרמטר [scheduler]parsing_processes ב-Airflow 2 וב-Airflow 3.

הקצאה אוטומטית של DAG לתפקידים ברמת התיקייה

כדי להקצות באופן אוטומטי DAG לתפקידים ברמת התיקייה:

  1. עוקפים את אפשרות ההגדרה הבאה של Airflow:

    קטע מפתח ערך
    webserver rbac_autoregister_per_folder_roles True

  2. משנים את התפקיד של המשתמש החדש שנרשם לתפקיד ללא גישה ל-DAG. כך, למשתמשים חדשים אין גישה ל-DAGs עד שאדמין מקצה לחשבונות שלהם תפקיד עם הרשאות ל-DAGs ספציפיים.

    ‫UserNoDags ו-NoDags הם תפקידים שנוצרים על ידי Managed Airflow רק כשהתכונה Per-folder Roles Registration (רישום תפקידים לכל תיקייה) מופעלת. הם מקבילים לתפקיד User (משתמש), אבל בלי גישה ל-DAG. התפקיד UserNoDags נוצר ב-Airflow 2 וב-Airflow 3, והתפקיד NoDags נוצר ב-Airflow 1.

    ב-Airflow 2 ו-3, מבטלים את ההגדרה הבאה של Airflow:

    קטע מפתח ערך
    webserver rbac_user_registration_role UserNoDags

    ב-Airflow 1, צריך להגדיר מחדש את אפשרות ההגדרה הבאה של Airflow:

    קטע מפתח ערך
    webserver rbac_user_registration_role NoDags

  3. מוודאים שהמשתמשים רשומים ב-Airflow.

  4. אפשר להקצות תפקידים למשתמשים באחת מהדרכים הבאות:

    • מאפשרים ל-Airflow ליצור באופן אוטומטי תפקידים על סמך תיקיות המשנה של DAG, ואז להקצות משתמשים לתפקידים האלה.
    • יוצרים מראש תפקידים ריקים לתיקיות המשנה של DAG, עם שמות תפקידים שתואמים לשם של תיקיית משנה, ואז מקצים משתמשים לתפקידים האלה. לדוגמה, כדי ליצור תפקיד בשם CustomFolder לתיקייה /dags/CustomFolder.

  5. העלאה של DAG לתיקיות משנה עם שמות שתואמים לתפקידים שהוקצו למשתמשים. תיקיות המשנה האלה צריכות להיות בתוך התיקייה /dags בדלי של הסביבה. ‫Airflow מוסיף הרשאות ל-DAG בתיקיית משנה כזו, כך שרק משתמשים עם התפקיד המתאים יכולים לגשת אליהם דרך ממשק המשתמש של Airflow וממשק המשתמש של DAG.

הגדרה ידנית של הרשאות ברמת ה-DAG

אתם יכולים להגדיר הרשאות ברמת DAG לתפקידים בהתאמה אישית כדי לציין אילו DAG יהיו גלויים לקבוצות משתמשים ספציפיות.

כדי להגדיר הרשאות ברמת ה-DAG בממשק המשתמש של Airflow:

  1. האדמין יוצר תפקידים ריקים לקיבוץ של DAG.
  2. האדמין מקצה למשתמשים תפקידים מתאימים.
  3. האדמין או המשתמשים מקצים DAG לתפקידים.
  4. בממשק המשתמש של Airflow, המשתמשים יכולים לראות רק DAG שהוקצו לקבוצה שלהם.

אפשר להקצות DAG לתפקידים דרך מאפייני ה-DAG או דרך ממשק המשתמש של Airflow.

הקצאת DAG לתפקידים בממשק המשתמש של Airflow

אדמין יכול להקצות את ההרשאות הנדרשות ברמת ה-DAG לתפקידים המתאימים בממשק המשתמש של Airflow.

הפעולה הזו לא נתמכת בממשק המשתמש של DAG.

הקצאת DAG לתפקידים במאפייני DAG

אפשר להגדיר את access_control הפרמטר DAG ב-DAG, ולציין את התפקידים של קיבוץ DAG שאליהם ה-DAG משויך.

Airflow 2 

dag = DAG(
  access_control={
    'DagGroup': {'can_edit', 'can_read'},
  },
  ...
  )

Airflow 1 

dag = DAG(
  access_control={
    'DagGroup': {'can_dag_edit', 'can_dag_read'},
  },
  ...
  )

מיפוי יומני ביקורת בממשק המשתמש של Airflow למשתמשים

יומני הביקורת בממשק המשתמש של Airflow ממופים למזהים מספריים של חשבונות משתמשים ב-Google. לדוגמה, אם משתמש משהה DAG, נוסף רשומה ליומנים.

Airflow 2

ב-Airflow 2, אפשר לראות את יומני הביקורת בדף Browse > Audit Logs בממשק המשתמש של Airflow.

רשומה בדף Audit Logs (יומני ביקורת) ב-Airflow 2
איור 1. רשומה בדף 'יומני ביקורת' ב-Airflow 2

Airflow 1

ב-Airflow 1, אפשר לראות את יומני הביקורת בדף Browse > Logs.

רשומה בדף Logs (יומנים) ב-Airflow 1
איור 1. רשומה בדף Logs ב-Airflow 1

ברשומה טיפוסית מופיע מזהה מספרי בשדה Owner (בעלים): accounts.google.com:NUMERIC_ID. אפשר למפות מזהים מספריים לכתובות אימייל של משתמשים בדף אבטחה > רשימת משתמשים. הדף הזה זמין למשתמשים עם תפקיד Admin.

חשוב לדעת שהקשר בין זהויות ב-Google (כתובות אימייל) לבין חשבונות משתמשים (מזהי משתמשים) לא קבוע.

המאמרים הבאים