הגדרה של אשכולות מקומיים

במסמך הזה מוסבר איך להגדיר Binary Authorization לאשכולות מקומיים שנוצרו כחלק מ-Google Distributed Cloud. בהמשך נסביר איך להגדיר מדיניות לדוגמה של Binary Authorization.

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

  1. מוודאים שהאשכולות שלכם הם בגרסה נתמכת של Google Distributed Cloud. Binary Authorization תומך בסביבות הבאות.

  2. שירות Binary Authorization משתמש בכתובת IP חיצונית שאפשר לגשת אליה דרך חיבור אינטרנט רגיל. מגדירים את כללי חומת האש עבור HTTPS כדי לאפשר לאשכול המשתמשים גישה לנקודת הקצה binaryauthorization.googleapis.com.

  3. אם רוצים להשתמש ביומני ביקורת של Cloud כדי להציג רשומות ביומן הביקורת, כולל רשומות מ-Binary Authorization עבור אשכולות מחוץ ל- Google Cloud, צריך להגדיר את יומני הביקורת של Cloud בהגדרות האשכול.

    Bare metal

    מגדירים יומני ביקורת בענן ב-Google Distributed Cloud.

    VMware

    מגדירים יומני ביקורת בענן ב-Google Distributed Cloud.

  4. צריך להפעיל את Binary Authorization API באופן הבא:

    1. עוברים אל Google Cloud המסוף.

      הפעלת ממשקי API

    2. ברשימה הנפתחת של הפרויקטים, בוחרים את פרויקט המארח של ה-Fleet. אפשר למצוא את זה בקטע gkeConnect בקובץ ההגדרות של אשכול המשתמשים. זהו Google Cloud הפרויקט שמקשר את אשכול המשתמשים אל Google Cloud.

הגדרת Binary Authorization

בקטע הזה מוסבר איך להגדיר Binary Authorization באשכול המקומי.

ציון משתני סביבה להתקנה

כדי לציין את משתני הסביבה:

שימוש ב-Workload Identity

  1. מציינים את פרויקט המארח של ה-Fleet:

    export PROJECT_ID=PROJECT_ID

  2. מגדירים את מזהה החברות ב-Fleet למזהה האשכול:

    מזהה החברות מופיע בעמודה NAME כשמריצים את הפקודה gcloud container fleet memberships list.

    export MEMBERSHIP_ID=CLUSTER_NAME

שימוש במפתח של חשבון שירות

  1. מציינים את פרויקט המארח של ה-Fleet:

    export PROJECT_ID=PROJECT_ID

    מחליפים את PROJECT_ID ב Google Cloud project בקטע gkeConnect בקובץ התצורה של אשכול המשתמשים.

  2. מציינים את הנתיב של קובץ ה-kubeconfig של אשכול המשתמשים:

    export KUBECONFIG=PATH

    מחליפים את PATH בנתיב של קובץ ה-kubeconfig של אשכול המשתמשים.

  3. בוחרים שם לחשבון השירות של ה-API לגישה ל-Binary Authorization:

    export SA_NAME=SERVICE_ACCOUNT_NAME

    מחליפים את SERVICE_ACCOUNT_NAME בשם של חשבון השירות שרוצים. מודול Binary Authorization משתמש בחשבון השירות הזה כדי לגשת אל Binary Authorization API.

  4. מציינים את הנתיב לקובץ המפתח של חשבון השירות שהורדתם בהמשך המדריך הזה:

    export SA_JSON_PATH=SA_KEY_FILE_PATH

    מחליפים את SA_KEY_FILE_PATH בנתיב של קובץ מפתח ה-JSON של חשבון השירות.

התקנת מודול Binary Authorization באשכול המשתמשים

כדי להתקין את מודול Binary Authorization:

שימוש ב-Workload Identity

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

  1. מקצים את התפקיד binaryauthorization.policyEvaluator לחשבון השירות של Kubernetes בפרויקט המארח של הצי:

    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[binauthz-system/binauthz-admin]" \
    --role="roles/binaryauthorization.policyEvaluator"

  2. יוצרים ספריית עבודה:

    1. יוצרים ספרייה בשם binauthz.

    2. עוברים לספרייה.

  3. מורידים את הקובץ manifest-wi-0.2.6.yaml.tmpl, שמשמש להתקנת מודול Binary Authorization באשכול המשתמשים:

    Bare metal 

    gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .

    VMware 

    gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .

  4. מחליפים את משתני הסביבה בתבנית:

    envsubst < manifest-wi-0.2.6.yaml.tmpl > manifest-0.2.6.yaml

  5. מתקינים את מודול Binary Authorization באשכול המשתמשים:

    kubectl apply -f manifest-0.2.6.yaml

  6. מוודאים שהפריסה נוצרה:

    kubectl get pod --namespace binauthz-system

    ה-Pod binauthz-module-deployment-* מופיע ברשימה עם Status מתוך Running ו-1/1 Pods ready, כמו בדוגמה הבאה:

    NAME                                          READY   STATUS    RESTARTS   AGE
binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s

שימוש במפתח של חשבון שירות

  1. מגדירים את פרויקט ברירת המחדל ל-Google Cloud CLI:

    gcloud config set project ${PROJECT_ID}

  2. יוצרים חשבון שירות לגישה ל-Binary Authorization API:

    gcloud iam service-accounts create ${SA_NAME}

  3. מקצים את התפקיד binaryauthorization.policyEvaluator לחשבון השירות של ממשק Binary Authorization API בפרויקט המארח של הצי:

    gcloud projects add-iam-policy-binding ${PROJECT_ID}\
    --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/binaryauthorization.policyEvaluator"

  4. יוצרים ספריית עבודה:

    1. יוצרים ספרייה בשם binauthz.

    2. עוברים לספרייה.

  5. מורידים את הקובץ manifest-0.2.6.yaml, שמשמש להתקנת מודול Binary Authorization באשכול המשתמשים:

    Bare metal 

    gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .

    VMware 

    gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-0.2.6.yaml .

  6. יוצרים קובץ YAML למרחב השמותbinauthz-system.

    מעתיקים את הקוד הבא לקובץ שנקרא namespace.yaml:

    apiVersion: v1
kind: Namespace
metadata:
  labels:
    control-plane: binauthz-controller
  name: binauthz-system

  7. יוצרים את מרחב השמות באשכול המשתמשים:

    kubectl apply -f namespace.yaml

    הפלט אמור להיראות כך:

    namespace/binauthz-system created

  8. מורידים קובץ מפתח בפורמט JSON לחשבון השירות:

    gcloud iam service-accounts keys create ${SA_JSON_PATH} --iam-account ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

  9. שומרים את המפתח של חשבון השירות כסוד של Kubernetes באשכול המשתמשים:

    kubectl --namespace binauthz-system create secret generic binauthz-sa --from-file=key.json=${SA_JSON_PATH}

  10. מתקינים את מודול Binary Authorization באשכול המשתמשים:

    kubectl apply -f manifest-0.2.6.yaml

  11. מוודאים שהפריסה נוצרה:

    kubectl get pod --namespace binauthz-system

    ה-Pod binauthz-module-deployment-* מופיע ברשימה עם Status מתוך Running ו-1/1 Pods ready, כמו בדוגמה הבאה:

    NAME                                          READY   STATUS    RESTARTS   AGE
binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s

הגדרה ושימוש במדיניות של Binary Authorization

בקטע הזה נסביר איך להגדיר מדיניות של Binary Authorization לשימוש באשכולות מקומיים.

בכל דוגמה, מגדירים את המדיניות ואז מנסים לפרוס קובץ אימג' של קונטיינר באשכול כדי לבדוק אותה.

אישור גישה לכולן

בקטע הזה מוצג מקרה של הצלחה. אתם מגדירים את מדיניות Binary Authorization כך שקובץ אימג' של קונטיינר יעמוד בדרישות המדיניות וייפרס.

ב- Google Cloud, מבצעים את הפעולות הבאות:

המסוף

  1. במסוף Google Cloud , עוברים לדף Binary Authorization.

    מעבר אל Binary Authorization

  2. חשוב לבחור את מזהה הפרויקט של מארח הצי.

  3. לוחצים על עריכת המדיניות.

  4. בקטע Project default rule, בוחרים באפשרות Allow all images.

  5. לוחצים על שמירת המדיניות.

gcloud

  1. מגדירים את PROJECT_ID לפרויקט של מארח ה-Fleet. מזהה הפרויקט מופיע בשדה gkeConnect בקובץ ההגדרה של אשכול המשתמשים.

    export PROJECT_ID=PROJECT_ID

    מגדירים את פרויקט ברירת המחדל Google Cloud .

    gcloud config set project ${PROJECT_ID}

  2. מייצאים את קובץ ה-YAML של המדיניות למערכת המקומית:

    gcloud container binauthz policy export  > policy.yaml

    קובץ ה-YAML אמור להיראות כך:

    defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/<var>PROJECT_ID</var>/policy

  3. עריכה של policy.yaml.

  4. מגדירים את evaluationMode להיות ALWAYS_ALLOW.

  5. אם יש requireAttestationsBy block בקובץ, מוחקים את ה-block הזה.

  6. שומרים את הקובץ.

  7. כדי לייבא את policy.yaml:

    gcloud container binauthz policy import policy.yaml

כדי להוסיף תמונה שפטורה מהכללים לרשימת ההיתרים, מוסיפים את השורה הבאה לקובץ המדיניות: 

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

מחליפים את EXEMPT_IMAGE_PATH בנתיב לתמונה שרוצים להחריג. כדי להחריג תמונות נוספות, מוסיפים עוד רשומות של - namePattern. מידע נוסף על admissionWhitelistPatterns

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

  1. יוצרים קובץ מניפסט בשביל Pod.

    שומרים את הטקסט הבא בקובץ בשם pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: us-docker.pkg.dev/google-samples/containers/gke/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

  2. יוצרים את הפוד:

    kubectl apply -f pod.yaml

    רואים שה-Pod נפרס בהצלחה.

  3. מוחקים את ה-Pod:

    kubectl delete -f pod.yaml

השבתה של הכול

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

ב Google Cloud מבצעים את הפעולות הבאות:

המסוף

  1. במסוף Google Cloud , עוברים לדף Binary Authorization.

    מעבר אל Binary Authorization

  2. מוודאים שבחרתם את פרויקט המארח של ה-Fleet.

  3. לוחצים על עריכת המדיניות.

  4. בקטע Project default rule, בוחרים באפשרות Disallow all images.

  5. לוחצים על שמירת המדיניות.

gcloud

  1. מגדירים את PROJECT_ID למזהה פרויקט המארח של הצי.

    export PROJECT_ID=PROJECT_ID

  2. מגדירים את פרויקט ברירת המחדל Google Cloud .

    gcloud config set project ${PROJECT_ID}

  3. מייצאים את קובץ ה-YAML של המדיניות:

    gcloud container binauthz policy export  > policy.yaml

  4. עריכה של policy.yaml.

  5. מגדירים את evaluationMode להיות ALWAYS_DENY.

  6. אם יש requireAttestationsBy block בקובץ, מוחקים את ה-block הזה.

  7. שומרים את הקובץ.

  8. כדי לייבא את policy.yaml:

    gcloud container binauthz policy import policy.yaml

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

  1. יוצרים קובץ מניפסט בשביל Pod.

    שומרים את הטקסט הבא בקובץ בשם pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: us-docker.pkg.dev/google-samples/containers/gke/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

  2. יוצרים את הפוד:

    kubectl apply -f pod.yaml

    אתם רואים שהפריסה של ה-Pod נחסמה. הפלט אמור להיראות כך:

    Error from server (VIOLATES_POLICY): error when creating "pod.yaml": admission webhook "binaryauthorization.googleapis.com" denied the request: Denied by default admission rule. Overridden by evaluation mode

קבלת מזהה המשאב של אשכול המשתמשים

בקטע הזה מוסבר איך להרכיב את מזהה משאב האשכול עבור אשכול המשתמשים. במדיניות של Binary Authorization, אפשר ליצור כללים ספציפיים לאשכול. אתם משייכים את הכללים האלה למזהה משאב ספציפי לאשכול, שמבוסס על מזהה האשכול.

כך מקבלים את מזהה המשאב:

המסוף

  1. במסוףGoogle Cloud , עוברים לדף Clusters של GKE.

    מעבר אל Clusters

  2. בוחרים את מזהה פרויקט המארח של ה-Fleet עבור האשכולות. מזהה הפרויקט מופיע בקטע gkeConnect בקובץ ההגדרות של אשכול המשתמשים.

  3. ברשימת האשכולות, מחפשים את מזהה האשכול בעמודה שם.

  4. כדי ליצור את מזהה המשאב, מוסיפים את הקידומת global. למזהה האשכול, כך שמזהה המשאב יהיה בפורמט הבא: global.CLUSTER_ID.

gcloud

  1. משתמשים ב-SSH כדי להתחבר לתחנת העבודה של האדמין.

  2. בתחנת העבודה של האדמין, מריצים את הפקודה הבאה:

    kubectl get membership -o yaml

  3. מקבלים את מזהה האשכול מהשדה spec.owner.id של הפלט. פלט לדוגמה:

    apiVersion: v1
items:
- apiVersion: hub.gke.io/v1
  kind: Membership
  ...
  spec:
    owner:
      id: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/my-cluster-id

    בדוגמת הפלט, מזהה האשכול הוא my-cluster-id.

  4. כדי ליצור את מזהה המשאב, מוסיפים את הקידומת global. למזהה האשכול. בדוגמה, מזהה המשאב הוא global.my-cluster-id.

משתמשים במזהה המשאב הזה כשמגדירים כללים ספציפיים לאשכול. איך מגדירים כללים ספציפיים לאשכול באמצעות מסוףGoogle Cloud או ה-CLI של gcloud

עדכון מדיניות הכשל

אפשר להגדיר את ה-webhook של Binary Authorization ל-fail open או ל-fail close.

Fail close

כדי לעדכן את מדיניות הכשל כך שהיא תהיה 'כשל בסגירה':

  1. עורכים את הקובץ manifest-0.2.6.yaml ומגדירים את failurePolicy ל-Fail

  2. מפעילים מחדש את ה-webhook:

    kubectl apply -f manifest-0.2.6.yaml

    הפלט אמור להיראות כך:

    serviceaccount/binauthz-admin unchanged
role.rbac.authorization.k8s.io/binauthz-role configured
clusterrole.rbac.authorization.k8s.io/binauthz-role configured
rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
secret/binauthz-tls unchanged
service/binauthz unchanged
deployment.apps/binauthz-module-deployment unchanged
validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured

שגיאת Fail Open

כדי לעדכן את מדיניות הכשל כך שתאפשר גישה:

  1. עורכים את הקובץ manifest-0.2.6.yaml ומגדירים את failurePolicy ל-Ignore

  2. מפעילים מחדש את ה-webhook:

    kubectl apply -f manifest-0.2.6.yaml

    הפלט אמור להיראות כך:

    serviceaccount/binauthz-admin unchanged
role.rbac.authorization.k8s.io/binauthz-role configured
clusterrole.rbac.authorization.k8s.io/binauthz-role configured
rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
secret/binauthz-tls unchanged
service/binauthz unchanged
deployment.apps/binauthz-module-deployment unchanged
validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured

מידע נוסף על מדיניות בנושא כשלים ב-webhook

הסרת המשאבים

  1. בדוגמת הקוד הבאה אפשר לראות איך משביתים את ה-webhook:

    kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration

  2. בדוגמת הקוד הבאה אפשר לראות איך מפעילים מחדש את ה-webhook:

    kubectl apply -f manifest-0.2.6.yaml

  3. בדוגמת הקוד הבאה אפשר לראות איך מוחקים את כל המשאבים שקשורים ל-Binary Authorization:

    kubectl delete -f manifest-0.2.6.yaml
kubectl delete namespace binauthz-system

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