אימות באמצעות אסימון Bearer

בדף הזה מוסבר איך להגדיר אימות באמצעות אסימון bearer כדי להיכנס לאשכולות רשומים מחוץ ל- Google Cloud. אחרי ההגדרה, אדמינים של אשכולות יוכלו להתחבר לאשכולות ממסוףGoogle Cloud . יש תמיכה בסוגים רבים של אסימוני Bearer, כמו שמפורט באימות Kubernetes. השיטה הכי קלה היא ליצור חשבון שירות של Kubernetes ‏ (KSA) באשכול, ולהשתמש באסימון ה-bearer שלו כדי להיכנס.

שיטות אימות אחרות

במקום להגדיר אימות באמצעות טוקן Bearer, אפשר להגדיר אחת משיטות האימות הבאות, בהתאם לצרכים של הארגון:

  • Google Identity, שמאפשרת למשתמשים להיכנס באמצעות הזהות שלהם ב- Google Cloud . משתמשים באפשרות הזו אם למשתמשים שלכם כבר יש גישה ל- Google Cloud עם זהות Google.

  • אם האשכול שלכם מוגדר לשימוש בספק זהויות OIDC, אתם יכולים להשתמש בו כדי לבצע אימות לאשכול ממסוף Google Cloud . במדריכים הבאים מוסבר איך מגדירים OIDC לאשכולות GKE:

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

הענקת תפקידי IAM לגישה דרך Google Cloud המסוף

משתמשים שרוצים לראות אשכולות מקושרים באמצעות מסוף Google Cloud צריכים לפחות את תפקידי ה-IAM הבאים:

  • ‫roles/container.viewer. התפקיד הזה מאפשר למשתמשים לצפות במשאבי מאגר התגים במסוף Google Cloud , כולל בדף GKE Clusters. פרטים על ההרשאות שכלולות בתפקיד הזה זמינים במאמר תפקידים ב-Kubernetes Engine במסמכי ה-IAM.

  • roles/gkehub.viewer. התפקיד הזה מאפשר למשתמשים לראות את האשכולות מחוץ ל-Google Cloud ב Google Cloud מסוף. המשתמשים לא צריכים את התפקיד הזה אם הצי לא כולל אשכולות מחוץ ל- Google Cloud. במאמר תפקידים ב-GKE Hub במסמכי ה-IAM מוסבר בהרחבה אילו הרשאות כלולות בתפקיד הזה.

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

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/gkehub.viewer

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

  • ‫PROJECT_ID: מזהה הפרויקט של פרויקט המארח של ה-Fleet.

  • ‫EMAIL_ADDRESS: כתובת האימייל שמשויכת לחשבון של המשתמש ב- Google Cloud .

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

הגדרת בקרת גישה מבוססת-תפקידים

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

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

כדי לקבל גישה לאשכול דרך המסוף, לחשבון KSA צריכות להיות לפחות ההרשאות הבאות ב-RBAC באשכול:

יצירה והחלה של תפקיד RBAC‏ cloud-console-reader

משתמשים מאומתים שרוצים לגשת למשאבים של אשכול במסוף Google Cloud צריכים לקבל את ההרשאות הרלוונטיות ב-Kubernetes כדי לעשות זאת. אם אתם לא רוצים להעניק למשתמשים האלה הרשאות נרחבות יותר, כמו הרשאות של אדמין באשכול, אתם יכולים ליצור תפקיד RBAC בהתאמה אישית שכולל את ההרשאות המינימליות לצפייה בצמתים, בכרכים מתמשכים, בתרמילים ובסוגי האחסון של האשכול. כדי להגדיר את קבוצת ההרשאות הזו, צריך ליצור משאב ClusterRole RBAC,‏ cloud-console-reader, באשכול.

‫cloud-console-reader מעניק למשתמשים שלו את ההרשאות get, list ו-watch בצמתים של האשכול, בכרכים מתמשכים, בתרמילים ובסוגי האחסון, מה שמאפשר להם לראות פרטים על המשאבים האלה.

kubectl

כדי ליצור את cloud-console-reader ClusterRole ולהחיל אותו על האשכול, מריצים את הפקודה הבאה:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

אחר כך תוכלו להקצות את התפקיד הזה ל-KSA, כמו שמתואר בקטע הבא.

יצירה ואישור של KSA

kubectl

כדי ליצור KSA ולקשר אליו הרשאות, מבצעים את השלבים הבאים:

  1. יוצרים את המשאבים KSA ו-ClusterRoleBinding כדי לקשר את view ואת cloud-console-reader Kubernetes RBAC ClusterRoles אל ה-KSA:

    KSA_NAME=KSA_NAME
kubectl create serviceaccount ${KSA_NAME}
kubectl create clusterrolebinding VIEW_BINDING_NAME \
   --clusterrole view --serviceaccount default:${KSA_NAME}
kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
   --clusterrole cloud-console-reader --serviceaccount default:${KSA_NAME}

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

    • KSA_NAME: השם שבחרתם ל-KSA
    • ‫VIEW_BINDING_NAME: השם שבוחרים למשאב view ClusterRoleBinding. אפשר לתת לו כל שם שרוצים, אבל הכי קל לתת לו את השם של ה-KSA
    • ‫CLOUD_CONSOLE_READER_BINDING_NAME: השם שבוחרים למשאב cloud-console-reader ClusterRoleBinding. אפשר גם לבחור כל שם אחר.

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

    לדוגמה, אם רוצים לפרוס אפליקציית Kubernetes מ-Cloud Marketplace, צריך לקשר את התפקיד cluster-admin ל-KSA:

    kubectl create clusterrolebinding BINDING_NAME \
   --clusterrole cluster-admin --serviceaccount default:KSA_NAME

    מחליפים את BINDING_NAME בשם של קישור תפקיד באשכול לחשבון השירות.

אישור חשבונות אחרים

kubectl

לכל משתמש או חשבון שירות אחר שמקבל גישה לאשכול, צריך ליצור משאבי ClusterRoleBinding כדי לקשר את התפקידים view ו-cloud-console-reader לחשבון שלו:

  1. שיוך של view ושל cloud-console-reader ClusterRoles:

    ACCOUNT_NAME=ACCOUNT_NAME
kubectl create clusterrolebinding VIEW_BINDING_NAME \
   --clusterrole view --serviceaccount default:${ACCOUNT_NAME}
kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
   --clusterrole cloud-console-reader --serviceaccount default:${ACCOUNT_NAME}

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

    • ‫ACCOUNT_NAME: חשבון השירות של Kubernetes
    • ‫VIEW_BINDING_NAME: השם שבוחרים למשאב view ClusterRoleBinding. אפשר לבחור כל שם שרוצים, אבל הכי קל לתת לו את השם של חשבון המשתמש או חשבון השירות
    • ‫CLOUD_CONSOLE_READER_BINDING_NAME: השם שבוחרים למשאב view ClusterRoleBinding. אפשר גם לתת לו כל שם שרוצים.

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

    לדוגמה, כדי לקשר את התפקיד cluster-admin, מריצים את הפקודה הבאה:

    kubectl create clusterrolebinding BINDING_NAME \
   --clusterrole cluster-admin --serviceaccount default:ACCOUNT_NAME

    מחליפים את BINDING_NAME בשם של קישור תפקיד באשכול לחשבון השירות.

קבלת טוקן למוכ"ז של KSA

kubectl

כדי לקבל את אסימון ה-bearer של ה-KSA, מריצים את הפקודה הבאה:

SECRET_NAME=KSA_NAME-token

kubectl apply -f - << __EOF__
apiVersion: v1
kind: Secret
metadata:
  name: "${SECRET_NAME}"
  annotations:
    kubernetes.io/service-account.name: "${KSA_NAME}"
type: kubernetes.io/service-account-token
__EOF__

until [[ $(kubectl get -o=jsonpath="{.data.token}" "secret/${SECRET_NAME}") ]]; do
  echo "waiting for token..." >&2;
  sleep 1;
done

kubectl get secret ${SECRET_NAME} -o jsonpath='{$.data.token}' | base64 --decode

מחליפים את KSA_NAME בשם שבוחרים ל-KSA.

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