אימות לשרת Kubernetes API

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

למידע על אימות עומסי עבודה של Kubernetes ל-Cloud de Confiance by S3NS APIs, אפשר לעיין במאמר איחוד זהויות של עומסי עבודה ל-GKE.

הדף הזה מיועד למומחי אבטחה ולאופרטורים שצריכים לבצע אימות מאובטח לשרת Kubernetes API מאשכולות GKE. בדף הזה מפורטות שיטות האימות הזמינות ומוסבר איך להטמיע אותן. כדי לקבל מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Cloud de Confiance by S3NS תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשים ב-GKE ומשימות.

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את המושגים הבאים:

• סקירה כללית על אימות ב- Cloud de Confiance
• סקירה כללית על IAM ובקרת גישה מבוססת-תפקידים (RBAC) ב-GKE
• סקירה כללית של שיטות אימות ב-Kubernetes

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

אימות משתמשים

‫GKE מנהל את אימות משתמשי הקצה בשבילכם באמצעות Google Cloud CLI. ה-CLI של gcloud מאמת את המשתמשים ב-Cloud de Confiance, מגדיר את התצורה של Kubernetes, מקבל אסימון גישה מסוג OAuth לאשכול ומעדכן את אסימון הגישה.

כל אשכולות GKE מוגדרים לקבל זהויות של משתמשים וחשבונות שירות, על ידי אימות פרטי הכניסה שמוצגים על ידי kubectl ואחזור כתובת האימייל שמשויכת לזהות של המשתמש או חשבון השירות. Cloud de Confianceלכן, פרטי הכניסה של החשבונות האלה צריכים לכלול את userinfo.email היקף ההרשאות של OAuth כדי שהאימות יצליח.

כשמשתמשים ב-gcloud כדי להגדיר את kubeconfig בסביבה עבור אשכול חדש או קיים, gcloud מעניק ל-kubectl את אותם פרטי כניסה שבהם משתמש gcloud עצמו. לדוגמה, אם אתם משתמשים ב-gcloud auth login, הפרטים האישיים שלכם מועברים ל-kubectl, כולל היקף ההרשאות userinfo.email. כך אפשר לאמת את לקוח kubectl באשכול GKE.

לחלופין, אתם יכולים להגדיר את kubectl כך שישתמש בפרטי הכניסה שלCloud de Confiance חשבון שירות, בזמן שהוא פועל במכונה של Compute Engine. עם זאת, כברירת מחדל, ההיקף userinfo.email לא נכלל בפרטי הכניסה שנוצרו על ידי מופעים של Compute Engine. לכן, חובה להוסיף את היקף ההרשאות הזה באופן מפורש, למשל באמצעות הדגל --scopes כשיוצרים את המכונה ב-Compute Engine.

אתם יכולים לאשר פעולות באשכול באמצעות ניהול זהויות והרשאות גישה (IAM) או בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes.

אימות באמצעות OAuth

כדי לבצע אימות לאשכול באמצעות שיטת OAuth, מבצעים את הפעולות הבאות:

1. נכנסים ל-CLI של gcloud באמצעות פרטי הכניסה. ייפתח דפדפן אינטרנט כדי להשלים את תהליך האימות ב- Cloud de Confiance:

   gcloud auth login
   

2. מאחזרים את פרטי הכניסה של Kubernetes לאשכול ספציפי:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

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

   • ‫CLUSTER_NAME: שם האשכול.
   • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

3. מוודאים שהאימות הושלם:

   kubectl cluster-info
   

אחרי שמשתמשים או Cloud de Confiance חשבונות שירות מאומתים, הם צריכים גם לקבל הרשאה כדי לבצע פעולה כלשהי באשכול GKE. מידע נוסף על הגדרת הרשאות זמין במאמר בנושא בקרת גישה מבוססת-תפקידים.

אימות אפליקציות

אפשר גם לבצע אימות לשרת ה-API מאפליקציה ב-Pod ללא אינטראקציה עם המשתמש, למשל מסקריפט בצינור CI/CD. הדרך להשיג את זה משתנה בהתאם לסביבה שבה האפליקציה פועלת.

אפליקציה באותו אשכול

אם האפליקציה פועלת באותו אשכול GKE, צריך להשתמש בחשבון שירות של Kubernetes כדי לבצע אימות.

1. יוצרים חשבון שירות ב-Kubernetes ומקשרים אותו לקבוצת ה-Pod. אם לקבוצת ה-Pod כבר יש חשבון שירות של Kubernetes, או אם רוצים להשתמש בחשבון השירות שמוגדר כברירת מחדל במרחב השמות, אפשר לדלג על השלב הזה.

2. משתמשים ב-Kubernetes RBAC כדי להעניק לחשבון השירות של Kubernetes את ההרשאות שנדרשות לאפליקציה.

   בדוגמה הבאה מוענקות הרשאות view למשאבים במרחב השמות prod לחשבון שירות בשם cicd במרחב השמות cicd-ns:

   kubectl create rolebinding cicd-secret-viewer \
       --namespace=prod \
       --clusterrole=view \
       --serviceaccount=cicd-ns:cicd
   

3. בזמן הריצה, כשהאפליקציה שולחת בקשה ל-Kubernetes API, שרת ה-API מאמת את פרטי הכניסה של חשבון השירות.

אפליקציות בתוך Cloud de Confiance

אם האפליקציה פועלת בתוך אשכול היעד אבל מחוצה לו (לדוגמה, מכונה וירטואלית ב-Compute Engine או אשכול GKE אחר), צריך לבצע אימות לשרת ה-API באמצעות פרטי הכניסה של חשבון השירות של IAM שזמינים בסביבה. Cloud de Confiance

1. מקצים לחשבון שירות ב-IAM לסביבה. אם האפליקציה פועלת במכונה וירטואלית של Compute Engine, צריך להקצות חשבון שירות של IAM למופע. אם האפליקציה פועלת באשכול GKE אחר, צריך להשתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי להגדיר את ה-Pod כך שיפעל כחשבון שירות של IAM.

   בדוגמאות הבאות נעשה שימוש ב-ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com בתור חשבון השירות של IAM.

2. מעניקים לחשבון השירות של IAM גישה לאשכול.

   בדוגמה הבאה מוקצה תפקיד ה-IAM‏ roles/container.developer, שנותן גישה לאובייקטים של Kubernetes API בתוך אשכולות:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com \
       --role=roles/container.developer
   

   אפשר גם להשתמש ב-RBAC כדי להעניק לחשבון השירות של IAM גישה לאשכול. מריצים את הפקודה kubectl create rolebinding מApplications in the same cluster ומשתמשים ב---user=ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com במקום בדגל --service-account.

3. מאחזרים את פרטי הכניסה לאשכול:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

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

אפליקציות בסביבות אחרות

אם האפליקציה עוברת אימות מסביבה מחוץ ל-Cloud de Confiance, היא לא יכולה לגשת לפרטי כניסה מנוהלים של חשבון שירות ב-IAM. כדי לאחזר את פרטי הכניסה של האשכול, אפשר ליצור חשבון שירות ב-IAM, להוריד את המפתח שלו ולהשתמש במפתח בזמן הריצה מהשירות כדי לאחזר את פרטי הכניסה של האשכול באמצעות ה-CLI של gcloud.

1. יוצרים חשבון שירות ב-IAM בשביל האפליקציה. אם כבר יש לכם חשבון שירות ב-IAM, אתם יכולים לדלג על השלב הזה.

   הפקודה הבאה יוצרת חשבון שירות ב-IAM בשם ci-cd-pipeline:

   gcloud iam service-accounts create ci-cd-pipeline
   

2. נותנים לחשבון השירות ב-IAM גישה לאשכול.

   הפקודה הבאה מקצה את תפקיד ה-IAM‏ roles/container.developer לחשבון השירות של IAM‏ ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com \
       --role=roles/container.developer
   

   אפשר גם להשתמש ב-RBAC כדי להעניק לחשבון השירות של IAM גישה לאשכול. מריצים את הפקודה kubectl create rolebinding מApplications in the same cluster ומשתמשים ב---user=ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com במקום בדגל --service-account.

3. יוצרים ומורידים מפתח לחשבון שירות IAM. כדי להפוך אותו לזמין לאפליקציה בזמן הריצה:

   gcloud iam service-accounts keys create gsa-key.json \
       --iam-account=ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com
   

4. בזמן הריצה, בסביבה שבה האפליקציה פועלת, מאמתים את ה-CLI של gcloud באמצעות המפתח של חשבון השירות ב-IAM:

   gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com \
       --key-file=gsa-key.json
   

5. משתמשים ב-CLI של gcloud כדי לאחזר את פרטי הכניסה של האשכול:

   gcloud config set project PROJECT_ID
   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

סביבות בלי gcloud

מומלץ להשתמש ב-CLI של gcloud כדי לאחזר את פרטי הכניסה של האשכול, כי השיטה הזו עמידה בפני אירועים באשכול כמו החלפת כתובות IP במישור הבקרה או החלפת פרטי כניסה. עם זאת, אם אין לכם אפשרות להתקין את ה-CLI של gcloud בסביבה שלכם, עדיין תוכלו ליצור קובץ kubeconfig סטטי כדי לבצע אימות לאשכול:

1. יוצרים חשבון שירות ב-IAM בשביל האפליקציה. אם כבר יש לכם חשבון שירות ב-IAM, אתם יכולים לדלג על השלב הזה.

   הפקודה הבאה יוצרת חשבון שירות ב-IAM בשם ci-cd-pipeline:

   gcloud iam service-accounts create ci-cd-pipeline
   

2. נותנים לחשבון השירות ב-IAM גישה לאשכול.

   הפקודה הבאה מקצה את תפקיד ה-IAM‏ roles/container.developer לחשבון השירות של IAM‏ ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com \
       --role=roles/container.developer
   

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

3. יוצרים ומורידים מפתח לחשבון שירות IAM.

   בדוגמה הבאה, שם קובץ המפתח הוא gsa-key.json:

   gcloud iam service-accounts keys create gsa-key.json \
       --iam-account=ci-cd-pipeline@PROJECT_ID.s3ns.iam.gserviceaccount.com
   

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

   gcloud container clusters describe CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --format="value(endpoint)"
   

5. אם משתמשים בנקודת הקצה מבוססת ה-IP לגישה למישור הבקרה, צריך לקבל את האישור הציבורי המקודד ב-base64 של רשות אישורי הבסיס (CA) של האשכול. אם משתמשים בנקודת קצה מבוססת DNS, אפשר לדלג על השלב הזה.

   gcloud container clusters describe CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --format="value(masterAuth.clusterCaCertificate)"
   

6. יוצרים קובץ kubeconfig.yaml. אפשר להשתמש באחד מהפורמטים הבאים, בהתאם לאופן שבו האפליקציה ניגשת למישור הבקרה:

   • נקודת קצה מבוססת DNS:

     apiVersion: v1
     kind: Config
     clusters:
     - name: CLUSTER_NAME
       cluster:
         server: https://ENDPOINT
     users:
     - name: ci-cd-pipeline-gsa
       user:
         exec:
           apiVersion: client.authentication.k8s.io/v1beta1
           args:
           - --use_application_default_credentials
           command: gke-gcloud-auth-plugin
           installHint: Install gke-gcloud-auth-plugin for kubectl by following
             https://docs.cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin
           provideClusterInfo: true
     contexts:
     - context:
         cluster: CLUSTER_NAME
         user: ci-cd-pipeline-gsa
       name: CLUSTER_NAME-ci-cd
     current-context: CLUSTER_NAME-ci-cd
     

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

     • ‫CLUSTER_NAME: השם של האשכול.
     • ‫ENDPOINT: הערך שקיבלתם עבור endpoint מהשלב הקודם.

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

   • נקודת קצה מבוססת-IP:

     apiVersion: v1
     kind: Config
     clusters:
     - name: CLUSTER_NAME
       cluster:
         server: https://ENDPOINT
         certificate-authority-data: CLUSTER_CA_CERTIFICATE
     users:
         - name: ci-cd-pipeline-gsa
           user:
             exec:
               apiVersion: client.authentication.k8s.io/v1beta1
               args:
               - --use_application_default_credentials
               command: gke-gcloud-auth-plugin
               installHint: Install gke-gcloud-auth-plugin for kubectl by following
                 https://docs.cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin
               provideClusterInfo: true
         contexts:
         - context:
             cluster: CLUSTER_NAME
             user: ci-cd-pipeline-gsa
           name: CLUSTER_NAME-ci-cd
         current-context: CLUSTER_NAME-ci-cd
     

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

     • ‫CLUSTER_NAME: השם של האשכול.
     • ‫ENDPOINT: הערך בשדה endpoint, מהפלט של השלב הקודם.
     • ‫CLUSTER_CA_CERTICATE: האישור הציבורי של האשכול בקידוד base64.

     כשמשתמשים בנקודות קצה מבוססות-IP, שרת ה-API מציג אישור שחתום על ידי CA בסיסי של האשכול. הלקוח משתמש באישור ה-CA הציבורי בשדה certificate-authority-data כדי לאמת את אישור שרת ה-API. מידע נוסף זמין במאמר בנושא אבטחת תעבורה לחיבורים של מישור הבקרה.

7. פורסים את kubeconfig.yaml ואת gsa-key.json לצד האפליקציה בסביבה. בזמן הריצה, בסביבה שבה האפליקציה פועלת, מגדירים את משתני הסביבה הבאים:

   export KUBECONFIG=path/to/kubeconfig.yaml
   export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
   

8. האפליקציה יכולה עכשיו לשלוח בקשות ל-Kubernetes API והיא תאומת כחשבון שירות של IAM.

עדכון שיטות אימות מדור קודם

לפני השילוב של OAuth עם GKE, השיטות היחידות לאימות שהיו זמינות היו אישור X.509 שהוקצה מראש או סיסמה סטטית, אבל כבר לא מומלץ להשתמש בהן וצריך להשבית אותן. השיטות האלה יוצרות משטח תקיפה רחב יותר שמאפשר פריצה לאשכול, והן מושבתות כברירת מחדל באשכולות שמריצים את GKE בגרסה 1.12 ואילך. אם אתם משתמשים בשיטות אימות מדור קודם, מומלץ להשבית אותן.

אם ההגדרה הזו מופעלת, משתמש עם ההרשאהcontainer.clusters.getCredentials יכול לאחזר את אישור הלקוח ואת הסיסמה הקבועה. ההרשאה הזו ניתנת בתפקידים roles/container.admin,‏ roles/owner ו-roles/editor, לכן חשוב להשתמש בתפקידים האלה בחוכמה. מידע נוסף על תפקידי IAM ב-GKE

השבתת אימות באמצעות סיסמה סטטית

סיסמה סטטית היא שילוב של שם משתמש וסיסמה ששרת ה-API מאמת. ב-GKE, שיטת האימות הזו נקראת אימות בסיסי.

כדי לעדכן אשכול קיים ולהסיר את הסיסמה הסטטית:

gcloud container clusters update CLUSTER_NAME \
     --location=CONTROL_PLANE_LOCATION \
     --no-enable-basic-auth

השבתת אימות באמצעות אישור לקוח

באימות באמצעות אישור, הלקוח מציג אישור ששרת ה-API מאמת באמצעות רשות האישורים שצוינה. ב-GKE,‏ רשות אישורי הבסיס של האשכול חותמת על אישורי לקוחות.

לאימות באמצעות אישור לקוח יש השלכות על ההרשאה לשרת ה-API של Kubernetes. אם מופעלת בקרת הרשאות מדור קודם של Attribute Based Access Control (ABAC) באשכול, כברירת מחדל, אישורי לקוח יכולים לבצע אימות ולבצע כל פעולה בשרת ה-API. מצד שני, אם מופעלת בקרת גישה מבוססת-תפקידים (RBAC), צריך להעניק לאישורי הלקוח הרשאה ספציפית למשאבי Kubernetes.

כדי ליצור אשכול בלי ליצור אישור לקוח, משתמשים בדגל --no-issue-client-certificate:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
    --no-issue-client-certificate

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

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

• מידע עלCloud de Confiance אימות
• מידע נוסף על בקרת גישה ב-GKE
• מידע נוסף על חשבונות שירות של Google
• מידע נוסף על איחוד זהויות של עומסי עבודה ל-GKE
• מידע על הקשחת האבטחה באשכול