אימות לשרת Kubernetes API

טייס אוטומטי רגילה

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

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

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

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

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

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

מפעילים את ממשק Google Kubernetes Engine API.

הפעלת Google Kubernetes Engine API

אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

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

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

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

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

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

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

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

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

נכנסים ל-CLI של gcloud באמצעות פרטי הכניסה. ייפתח דפדפן אינטרנט כדי להשלים את תהליך האימות ב- Google Cloud:
```
gcloud auth login
```
זהירות: אל תבצעו את הפעולה הזו במכונה וירטואלית של Compute Engine שבה לכל המשתמשים יש גישה ל-root. שימוש בחשבון שירות לצורך אימות. פרטים נוספים מופיעים בקטע אפליקציות בתוך Google Cloud.
מאחזרים את פרטי הכניסה של Kubernetes לאשכול ספציפי:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול.
- ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
מוודאים שהאימות הושלם:
```
kubectl cluster-info
```

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

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

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

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

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

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

בדוגמה הבאה מוענקות הרשאות view למשאבים במרחב השמות prod לחשבון שירות בשם cicd במרחב השמות cicd-ns:
```
kubectl create rolebinding cicd-secret-viewer \
    --namespace=prod \
    --clusterrole=view \
    --serviceaccount=cicd-ns:cicd
```
בזמן הריצה, כשהאפליקציה שולחת בקשה ל-Kubernetes API, שרת ה-API מאמת את פרטי הכניסה של חשבון השירות.

אפליקציות בתוך Google Cloud

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

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

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

בדוגמה הבאה מוקצה תפקיד ה-IAM‏ roles/container.developer, שנותן גישה לאובייקטים של Kubernetes API בתוך אשכולות:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
אפשר גם להשתמש ב-RBAC כדי להעניק לחשבון השירות של IAM גישה לאשכול. מריצים את הפקודה kubectl create rolebinding מApplications in the same cluster ומשתמשים ב---user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com במקום בדגל --service-account.
מאחזרים את פרטי הכניסה לאשכול:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
האימות של האפליקציה מתבצע באופן אוטומטי באמצעות חשבון השירות של IAM שהוגדר בסביבה.

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

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

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

הפקודה הבאה יוצרת חשבון שירות ב-IAM בשם ci-cd-pipeline:
```
gcloud iam service-accounts create ci-cd-pipeline
```
נותנים לחשבון השירות ב-IAM גישה לאשכול.

הפקודה הבאה מקצה את תפקיד ה-IAM‏ roles/container.developer לחשבון השירות של IAM‏ ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
אפשר גם להשתמש ב-RBAC כדי להעניק לחשבון השירות של IAM גישה לאשכול. מריצים את הפקודה kubectl create rolebinding מApplications באותו אשכול ומשתמשים ב---user=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com במקום בדגל --service-account.
יוצרים ומורידים מפתח לחשבון שירות IAM. כדי להפוך אותו לזמין לאפליקציה בזמן הריצה:
```
gcloud iam service-accounts keys create gsa-key.json \
    --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
```
בזמן הריצה, בסביבה שבה האפליקציה פועלת, מאמתים את ה-CLI של gcloud באמצעות מפתח חשבון השירות של IAM:
```
gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --key-file=gsa-key.json
```

משתמשים ב-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 סטטי כדי לבצע אימות לאשכול:

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

הפקודה הבאה יוצרת חשבון שירות ב-IAM בשם ci-cd-pipeline:
```
gcloud iam service-accounts create ci-cd-pipeline
```
נותנים לחשבון השירות ב-IAM גישה לאשכול.

הפקודה הבאה מקצה את תפקיד ה-IAM‏ roles/container.developer לחשבון השירות של IAM‏ ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/container.developer
```
אפשר גם ליצור תפקיד IAM בהתאמה אישית כדי לקבל שליטה מדויקת בהרשאות שאתם מעניקים.

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

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

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

אם אתם משתמשים בנקודת הקצה מבוססת ה-DNS לגישה למישור הבקרה, צריך לקבל את הערך endpoint של האשכול:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(endpoint)"
```
אם אתם משתמשים בנקודת הקצה מבוססת ה-IP לגישה למישור הבקרה, צריך לקבל את הערך endpoint מהפקודה הקודמת, ואת הערך clusterCaCertificate עבור האשכול:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(masterAuth.clusterCaCertificate)"
```

יוצרים קובץ 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://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 בשלב הקודם.

אם אתם משתמשים בנקודות קצה מבוססות-IP לגישה למישור הבקרה, מוסיפים את הערך שקיבלתם עבור clusterCaCertificate מהשלב הקודם בפרמטר cluster של הקובץ kubeconfig.yaml:

apiVersion: v1
kind: Config
clusters:
- name: CLUSTER_NAME
  cluster:
    server: https://endpoint
    certificate-authority-data: masterAuth.clusterCaCertificate
users:
...

אין צורך לפענח את האישור בקידוד base64.

פורסים את kubeconfig.yaml ואת gsa-key.json לצד האפליקציה בסביבה. בזמן הריצה, בסביבה שבה האפליקציה פועלת, מגדירים את משתני הסביבה הבאים:
```
export KUBECONFIG=path/to/kubeconfig.yaml
export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
```
האפליקציה יכולה עכשיו לשלוח בקשות ל-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,‏ רשות אישורי הבסיס (CA) של האשכול חותמת על אישורי לקוח.

לאימות באמצעות אישור לקוח יש השלכות על ההרשאה לשרת Kubernetes API. אם מופעלת בקרת הרשאות מדור קודם של 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 מופעל באשכול, ושלאישור הלקוח אין הרשאה באשכול.