מודל הרשאות מבוסס טוקנים/ססמאות לעומת OIDC

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

כאשר אנחנו לוקחים את הקוד שרץ אצלנו לוקלית וגורמים לו לרוץ בכל העולם, אנחנו לא מעט פעמים משתמשים בהליכים שדוחפים את הקוד שלנו ממקום מסוים לשרתים מסוימים. ההליך הזה נקרא בעגת המתכנתים Deployment (בעברית:דיפלוימנט) וזה שם כללי לתהליך ארוך ומקיף שלוקח את הקוד ושולח אותו לשרתים בעולם. אבל איך, כשאני מבקש מהשרת בעולם לקחת את הקוד שלי, הוא יודע שאני זה אני?

אחת השיטות היא שימוש בססמה. כשאני אומר לשרת ״שמע נא מר חבוב, קח את הקוד הזה ותשים אותו במקום הקוד הנוכחי״, כדי לדעת מי אני הוא מבקש סיסמה או טוקן. פריט מידע סודי שאפשר להשתמש בו. למשל, אם אני בונה הליך דיפלוימנט בגיטהאב, כך שכל פעם שאני מבצע מרג׳ עם הmain\master יש לנו דיפלוימנט, אני נדרש להכניס טוקן קבוע לגיטהאב, כ״סוד״ ואז גיטהאב, כאשר הוא צריך לעשות דיפלוימנט לוקח אותו ממשתנה הסביבה ויוכל לדחוף את הקוד. ייפי קא יאי

הבעיה היא שזה לא בטוח כל כך. למה? כי אם בטעות הסוד הזה יתגלה, תוקף יוכל לחגוג עליו. איך הוא יתגלה? למשל להכניס אותו לגיטהאב בטעות. נכון, יש כל מיני סורקים כמו git leaks וחבריהם אבל… זה לא בטוח. מדי פעם גם צריך לשנות את הסוד הזה כי להשאיר אותו סטטי זה לא טוב. מצד שני, זו דרך נפוצה לאבטח קוד ותקשורת בין שרתים ואם תשאלו LLM ותבקשו ממנו לבנות לכם הליך דיפלוימנט, הוא ימליץ על השיטה הזו.

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

מה זה בכלל OIDC במקרה הזה? OpenID Connect. פרוטוקול שמאפשר לצד אחד להגיד לצד שני: "הנה הוכחה חתומה מי אני", בלי לשלוח סיסמה קבועה. איך זה עובד במקרה שלנו? גיטהאב (או גיטלאב, או כל מערכת CI אחרת) מנפיק רק כשצריך ויש דיפלוימנט ודרישה טוקן לזמן קצר (JWT). בתוך הטוקן הזה כתוב מידע על מי ייצר אותו ולמה: מאיזה ריפו זה הגיע, מאיזה בראנץ', מאיזה workflow, לפעמים גם מאיזו סביבה. ואז קורה משהו מדהים: חתימה קריפטוגרפית (כאן יש הסבר שלי על מה זה). הטוקן נחתם דיגיטלית על ידי גיטהאב. הוא נולד עם הריצה ומת בסופה, בדרך כלל אחרי כמה דקות עד שעה.

עכשיו מגיע החלק החשוב: המקום שאנחנו שולחים את הקוד אליו (AWS, GCP, Azure, Vault, אפילו Docker Hub) לא מקבל סיסמה ששמרתם ב-Secrets. הוא מקבל את ה-JWT הזה, בודק את החתימה מול המפתחות הציבוריים של גיטהאב, בודק שכל הטענות והמידע (שחתום ולא ניתו לשינוי) תואמים למה שאתם הגדרתם מראש. למשל שהריפו יהיה אותו ריפו, שהבראנץ׳ יהיה מאסטר ושה-workflow יהיה דיפלוי. רק אם הכל תואם, יש הנפקה של טוקן שנשלח חזרה. טוקן זמני במיוחד. אין מפתח קבוע בגיט. אין סוד שמסתובב במשתני סביבה לנצח. אין "נשנה את הטוקן כל רבעון כי ככה צריך".

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

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

בוא ונראה עם קוד. אני מאמין שכולכם יודעים מה זה git workflows. מי שלא? יש פוסט שבו אני מסביר על זה. בגדול זה הדיפלוי שלנו. אותו תהליך שרץ כאשר אנחנו עושים מרג׳. בעבר, היינו כותבים ידנית. כיום אנחנו כותבים עם ה-LLM. אם תבקשו מ-LLM "תבנה לי דיפלוימנט ל-AWS מגיטהאב", ברירת המחדל שלו עדיין תהיה AWS_ACCESS_KEY_ID ו-AWS_SECRET_ACCESS_KEY ב-Secrets. (מדובר בשני טוקנים הנדרשים לחיבור לסביבה של AWS)/ למה? כי ככה נראים אלף פוסטים ישנים. זה גם לא אסון אבטחה, חשוב לומר ויותר חשוב: זה עובד מיד. הוא ייצר לכם משהו כזה:

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-1

      - name: Deploy
        run: aws s3 sync ./dist s3://my-bucket/

הוא גם יסביר לכם מאיפה להוציא את AWS_ACCESS_KEY_ID ואת AWS_SECRET_ACCESS_KEY. אם תתנו לאייג׳נט גישה ל-GH CLI ול-AWS CLI, הוא גם יעשה את זה עבורכם ובממשק של גיטהאב. תוכלו לראות שיש טוקנים (לא תוכלו לראות את הערך שלהם). זה גם יעבוד והכל יהיה מעולה, אבל זה לא מספיק טוב.

הכוח שלנו הוא לא לתת לו לרוץ על ברירת המחדל. להגיד במפורש: אנחנו רוצים OIDC. ראשית, נצטרך להגדיר role בשרת. למשל ב-AWS זה עם IAM. זה אומר להגדיר את הזהות (תפקיד) שהטוקן נותן. למשל משהו כזה – יש פה שורה אחת רלוונטית מאד:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

שימו לב לשורה המודגשת token.actions.githubusercontent.com:sub – אני מאפשר אך ורק לריפו שלי ול-main לבצע את הפעולה הזו. זה חשוב לזכור שלא מספיק להורות לאייג׳נט לעשות שזה OIDC אלא לוודא בעין למי בדיוק זה ניתן. אם למשל הייתי שם כוכבית, זה היה נותן גישה באופן תיאורטי למקומות אחרים.

אחרי שיצרנו role, בדוגמה הזו ל AWS אבל לא רק, אנחנו מבקשים מהאייג׳נט ליצור את החיבור מהצד שלו בגיט workflows.

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

permissions:
  id-token: write 
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # pin ל-SHA, לא לטאג

      - name: Configure AWS via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: eu-west-1

      - name: Deploy
        run: aws s3 sync ./dist s3://my-bucket/

במקרה הזה ה-workflow מתאים ל-AWS אז נראה שהוא משתמש ב-aws-actions/configure-aws-credentials@v4 ובסינטקסט של AWS. אבל כל ספק יהיה לו את הactions שלו. מי יודע מה? האייג׳נט כמובן. ופה באמת צריך לבחון.

אבל מה מרוויחים? לא עובדים יותר בשיטות של שנות התשעים אלא בשיטות מתקדמות יותר ומאובטחות יותר. בלי טוקנים שנשמרים במקומות אחרים ויכולים להגנב. אנחנו עובדים ככה גם מקומית. מה שאני עושה זה במקרה של AWS זה לא לשים טוקנים אצלי אלא לבצע הזדהות מול AWS CLI ורק אז אני יכול לבצע דיפלוי מקומי או לתקשר עם הסביבה שלי. מה שקורה מאחורי הקלעים: aws sso login פותח דפדפן, אני מתחבר ל-AWS עם סיסמה ו-MFA כרגיל (עדיף לא כ-root), ה-CLI שומר פרטים זמניים ואין צורך ב AWS_ACCESS_KEY_ID בקובץ. כשהסשן פג הדיפלוי נכשל, וזה מעולה. גם אם מישהו יחדור למחשב שלי, אז בעסה לו.

ב-CI אנחנו נותנים לפלטפורמה להוכיח מי הריצה. מקומית אנחנו נותנים לזהות האנושית (או לזהות המכונה) להוכיח מי היושב מול המקלדת. בשני המקרים לא שומרים סיסמה ארוכת-חיים ליד הקוד. מה שלא עושים: לקחת את ה-PAT / access key שמיועד לשרת, לשים אותו ב-.env מקומי "רק בינתיים", ואז לגלות שהוא כבר בגיט ובלוגים של חצי שנה.

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