אימות באמצעות אסימון 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 דומה לשימוש בסיסמה, ולכן לכל משתמש צריך להיות חשבון משלו. התחברות באמצעות טוקן ה-bearer של ה-KSA גורמת לביצוע כל הפעולות בתור ה-KSA, בהתאם לתפקידי ה-RBAC שמוגדרים ל-KSA.

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

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

משתמשים מאומתים שרוצים לגשת למשאבים של אשכול במסוף 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 .