המוצר שמתואר במסמכי התיעוד האלה, אשכולות Anthos ב-AWS (דור קודם), נמצא עכשיו במצב תחזוקה. כל ההתקנות החדשות צריכות להתבצע באמצעות המוצר מהדור הנוכחי, אשכולות Anthos ב-AWS.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שימוש בזהות של עומס עבודה עם AWS

בנושא הזה נסביר איך להפעיל את התכונה 'זהויות של עומסי עבודה' בעומסי העבודה של GKE on AWS כדי לשלוט בגישה שלהם למשאבי AWS.

למידע על שימוש ב-Workload Identity עם חשבונות לניהול זהויות והרשאות גישה (IAM) כדי לשלוט בגישה למשאבי GCP, אפשר לעיין במאמר שימוש ב-Workload Identity עם Google Cloud. Google Cloud

סקירה כללית

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

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

אדמין של אשכול

יוצרים קטגוריה של Cloud Storage לאחסון נתוני גילוי של OIDC.
יוצרים תפקיד לניהול זהויות והרשאות גישה (IAM) כדי לקרוא מהקטגוריה הזו.
יוצרים אשכול משתמשים עם זהויות של עומסי עבודה.
יוצרים webhook באשכול שמחיל פרטי כניסה של Workload Identity על קובצי Pod בזמן היצירה. אם לא רוצים להשתמש בתגובה לפעולה מאתר אחר (webhook), אפשר להגדיר ידנית משתני סביבה ב-pods.
מגדירים את ספק ה-OIDC של AWS.
ליצור תפקידים וכללי מדיניות של AWS IAM.

מנהל אשכול או מפתח

יצירה של חשבונות שירות של Kubernetes וקישור של מדיניות AWS לחשבונות האלה.

מפתחים

החלת פרטי כניסה על הפודים

דרישות מוקדמות

כדי לבצע את השלבים במאמר הזה, צריך להגדיר את הדברים הבאים:

שירות ניהול של GKE ב-AWS.
אשכולות משתמשים שמופעלת בהם גרסת Kubernetes שגבוהה מ-1.17.9.

הערה: אם יצרתם אשכול Kubernetes 1.17 או 1.18, אתם צריכים לשדרג את ה-webhook לפני השדרוג ל-Kubernetes 1.19.
ההרשאות והכלים הבאים.

הרשאות

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

Google Cloud

יוצרים קטגוריה של Cloud Storage עם הרשאת קריאה ציבורית וגישה אחידה ברמת הקטגוריה.
נותנים הרשאות קריאה/כתיבה לקטגוריה.management-sa@PROJECT_NAME.iam.gserviceaccount.com

AWS

יצירת ספק OIDC של AWS
יצירת תפקידים ב-AWS IAM

כלים

במחשב המקומי, מומלץ להתקין את הכלי jq.

יצירת קטגוריית גילוי OIDC

הקטע הזה מיועד לאדמינים של אשכולות.

צריך לאחסן את נתוני הגילוי של OIDC בקטגוריה של Cloud Storage שנגישה לכולם. הקטגוריה כוללת את הגדרת הגילוי של OIDC ואת המפתחות הציבוריים. מערכת AWS משתמשת בתוכן כדי לאמת בקשות מאשכולות המשתמשים שלכם.

הקטגוריה צריכה לכלול את המאפיינים הבאים:

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

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

BUCKET=BUCKET_NAME
gcloud storage buckets create gs://${BUCKET} --uniform-bucket-level-access
gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \
    --member=allUsers --role=roles/storage.objectViewer

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

מתן הרשאות לחשבון השירות לניהול

לחשבון השירות לניהול זהויות והרשאות גישה (IAM) של שירות הניהול GKE on AWS צריכות להיות הרשאות לקריאה ולכתיבה של אובייקטים בקטגוריה הזו.

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

MANAGEMENT_SA=management-sa@PROJECT_NAME.iam.gserviceaccount.com
gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \
    --member=serviceAccount:${MANAGEMENT_SA} \
    --role=roles/storage.admin

מחליפים את PROJECT_NAME בפרויקט ב- Google Cloud .

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

כדי להשלים את השלבים האלה, מריצים את הפקודות הבאות:
```
cat << EOF >  anthos-oidc-role.yaml
title: anthosAwsOidcStorageAdmin
description: permissions to manage the OIDC buckets
stage: GA
includedPermissions:
- storage.buckets.get
EOF

gcloud iam roles create anthosAwsOidcStorageAdmin --project=PROJECT_NAME \
  --file=anthos-oidc-role.yaml

gcloud projects add-iam-policy-binding \
  PROJECT_NAME \
  --member=serviceAccount:${MANAGEMENT_SA} \
  --role=projects/PROJECT_NAME/roles/anthosAwsOidcStorageAdmin
```
מחליפים את PROJECT_NAME בפרויקט ב- Google Cloud .

מערכת Google Cloud CLI מאשרת שנוצרת מדיניות מחייבת.

יצירת אשכול משתמשים

הקטע הזה מיועד לאדמינים של אשכולות.

יצירת אשכול משתמשים עם זהות עומס עבודה מופעלת

יוצרים אשכול משתמשים שמכיל פרטים על קטגוריית הגילוי של OIDC. מגדירים את הפרטים האלה בשדה AWSClusterspec.controlPlane.workloadIdentity.oidcDiscoveryGCSBucket.

בדוגמה הזו, יוצרים אשכול באופן ידני מ-CRD של AWSCluster ו-AWSNodePool.

עוברים לספרייה עם ההגדרה של GKE ב-AWS. יצרתם את הספרייה הזו כשהתקנתם את שירות הניהול.
```
cd anthos-aws
```
בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות הגישה שציינתם כשביצעתם את הפקודה aws configure.
פותחים כלי לעריכת טקסט ומעתיקים את ההגדרה הבאה AWSCluster לקובץ בשם custom-cluster.yaml.
```
apiVersion: multicloud.cluster.gke.io/v1
kind: AWSCluster
metadata:
  name: CLUSTER_NAME
spec:
  region: AWS_REGION
  networking:
    vpcID: VPC_ID
    podAddressCIDRBlocks: POD_ADDRESS_CIDR_BLOCKS
    serviceAddressCIDRBlocks: SERVICE_ADDRESS_CIDR_BLOCKS
    ServiceLoadBalancerSubnetIDs: SERVICE_LOAD_BALANCER_SUBNETS
  controlPlane:
    version:  CLUSTER_VERSION # Latest version is 1.25.5-gke.2100
    instanceType: AWS_INSTANCE_TYPE
    keyName: SSH_KEY_NAME
    subnetIDs:
    - CONTROL_PLANE_SUBNET_IDS
    securityGroupIDs:
    - CONTROL_PLANE_SECURITY_GROUPS
    iamInstanceProfile: CONTROL_PLANE_IAM_ROLE
    rootVolume:
      sizeGiB: ROOT_VOLUME_SIZE
      volumeType: ROOT_VOLUME_TYPE # Optional
      iops: ROOT_VOLUME_IOPS # Optional
      kmsKeyARN: ROOT_VOLUME_KEY # Optional
    etcd:
      mainVolume:
        sizeGiB: ETCD_VOLUME_SIZE
        volumeType: ETCD_VOLUME_TYPE # Optional
        iops: ETCD_VOLUME_IOPS # Optional
        kmsKeyARN: ETCD_VOLUME_KEY # Optional
    databaseEncryption:
      kmsKeyARN: ARN_OF_KMS_KEY
    hub: # Optional
      membershipName: ANTHOS_CONNECT_NAME
    cloudOperations: # Optional
      projectID: YOUR_PROJECT
      location: GCP_REGION
      enableLogging: ENABLE_LOGGING
      enableMonitoring: ENABLE_MONITORING
    workloadIdentity: # Optional
      oidcDiscoveryGCSBucket: WORKLOAD_IDENTITY_BUCKET
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫AWS_REGION: האזור ב-AWS שבו האשכול פועל.
  
  הערה: חובה ליצור את אשכול המשתמשים באותו אזור שבו נמצא שירות הניהול.
- ‫VPC_ID: המזהה של ה-VPC שבו האשכול פועל.
- ‫POD_ADDRESS_CIDR_BLOCKS: טווח כתובות ה-IPv4 שמשמשות את הפודים של האשכול. בשלב הזה יש תמיכה רק בטווח אחד. הטווח לא יכול לחפוף לרשתות משנה שאפשר להגיע אליהן מהרשת שלכם. אפשר להשתמש באותו טווח בכמה אובייקטים שונים של AWSCluster. לדוגמה, 10.2.0.0/16.
- ‫SERVICE_ADDRESS_CIDR_BLOCKS: טווח כתובות ה-IPv4 שמשמשות את השירותים של האשכול. בשלב הזה יש תמיכה רק בטווח אחד. הטווח לא יכול לחפוף לרשתות משנה שאפשר להגיע אליהן מהרשת שלכם. בטוח להשתמש באותו טווח בכמה אובייקטים שונים של AWSCluster. לדוגמה, 10.1.0.0/16.
- ‫SERVICE_LOAD_BALANCER_SUBNETS: מזהי רשתות המשנה שבהן GKE ב-AWS יכול ליצור מאזני עומסים ציבוריים או פרטיים.
- ‫CLUSTER_VERSION: גרסת Kubernetes שנתמכת על ידי GKE ב-AWS. הגרסה העדכנית ביותר היא 1.25.5-gke.2100.
- ‫AWS_INSTANCE_TYPE: סוג נתמך של מופע EC2.
- ‫SSH_KEY_NAME: זוג מפתחות של AWS EC2.
- ‫CONTROL_PLANE_SUBNET_IDS: מזהי תת-הרשת באזורי הזמינות שבהם מופעלים מופעי מישור הבקרה.
- ‫CONTROL_PLANE_SECURITY_GROUPS: מזהה קבוצת אבטחה שנוצר במהלך ההתקנה של שירות הניהול. אפשר להתאים אישית את ההגדרה הזו על ידי הוספה של מזהי קבוצות אבטחה שנדרשים כדי להתחבר למישור הבקרה.
- ‫CONTROL_PLANE_IAM_PROFILE: שם הפרופיל של מכונת AWS EC2 שהוקצה לשכפול של מישור הבקרה.
- ‫ROOT_VOLUME_SIZE: הגודל, בגיביבייט (GiB), של נפחי הבסיס של מישור הבקרה.
- ‫ROOT_VOLUME_TYPE עם סוג הנפח EBS. לדוגמה, gp3.
- ‫ROOT_VOLUME_IOPS עם כמות פעולות הקלט/פלט שהוקצו לשנייה (IOPS) עבור נפח האחסון. ההגדרה תקפה רק אם volumeType הוא GP3. מידע נוסף זמין במאמר בנושא כרכים של SSD לשימוש כללי (gp3).
- ‫ROOT_VOLUME_KEY עם שם משאב Amazon של מפתח AWS KMS שמצפין את נפחי הבסיס של מופע מישור הבקרה.
- ‫ETCD_VOLUME_SIZE: גודל הכרכים שמשמשים את etcd.
- ‫ETCD_VOLUME_TYPE עם סוג הנפח EBS. לדוגמה, gp3.
- ‫ETCD_VOLUME_IOPS עם כמות פעולות הקלט/פלט שהוקצו לשנייה (IOPS) עבור נפח האחסון. ההגדרה תקפה רק אם volumeType הוא gp3. מידע נוסף זמין במאמר בנושא כרכים של SSD לשימוש כללי (gp3).
- ‫ETCD_VOLUME_KEY עם שם משאב Amazon של מפתח AWS KMS שמצפין את אמצעי האחסון של נתוני etcd במישור הבקרה.
- ‫ARN_OF_KMS_KEY: מפתח AWS KMS שמשמש להצפנת סודות של אשכול.
- ‫ANTHOS_CONNECT_NAME: השם של חברות Connect שמשמש לרישום האשכול. השם של המועדון חייב להיות ייחודי. לדוגמה, projects/YOUR_PROJECT/locations/global/memberships/CLUSTER_NAME, כאשר YOUR_PROJECT הוא הפרויקט שלכם ב- Google Cloud ו-CLUSTER_NAME הוא שם ייחודי בפרויקט. השדה הזה הוא אופציונלי.
- YOUR_PROJECT: מזהה הפרויקט.
- ‫GCP_REGION: Google Cloud האזור שבו רוצים לאחסן את היומנים. בוחרים אזור שקרוב לאזור AWS. מידע נוסף זמין במאמר מיקומים גלובליים – אזורים ותחומים, למשל us-central1.
- ‫ENABLE_LOGGING: true או false, אם Cloud Logging מופעל בצמתים של מישור הבקרה.
- ‫ENABLE_MONITORING: true או false, אם Cloud Monitoring מופעל בצמתים של מישור הבקרה.
- ‫WORKLOAD_IDENTITY_BUCKET: שם הקטגוריה של Cloud Storage שמכילה את פרטי הגילוי של זהות עומס העבודה. השדה הזה הוא אופציונלי.
יוצרים לפחות AWSNodePool אחד לאשכול. פותחים עורך טקסט ומעתיקים את הגדרת ה-AWSCluster הבאה לקובץ בשם custom-nodepools.yaml.
```
apiVersion: multicloud.cluster.gke.io/v1
kind: AWSNodePool
metadata:
  name: NODE_POOL_NAME
spec:
  clusterName: AWSCLUSTER_NAME
  version:  CLUSTER_VERSION # latest version is 1.25.5-gke.2100
  region: AWS_REGION
  subnetID: AWS_SUBNET_ID
  minNodeCount: MINIMUM_NODE_COUNT
  maxNodeCount: MAXIMUM_NODE_COUNT
  maxPodsPerNode: MAXIMUM_PODS_PER_NODE_COUNT
  instanceType: AWS_NODE_TYPE
  keyName: KMS_KEY_PAIR_NAME
  iamInstanceProfile: NODE_IAM_PROFILE
  proxySecretName: PROXY_SECRET_NAME
  rootVolume:
    sizeGiB: ROOT_VOLUME_SIZE
    volumeType: VOLUME_TYPE # Optional
    iops: IOPS # Optional
    kmsKeyARN: NODE_VOLUME_KEY # Optional 
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NODE_POOL_NAME: שם ייחודי ל-AWSNodePool.
- ‫AWSCLUSTER_NAME: השם של AWSCluster. לדוגמה, staging-cluster.
- ‫CLUSTER_VERSION: גרסה נתמכת של GKE ב-AWS Kubernetes.
- ‫AWS_REGION: אותו אזור AWS כמו AWSCluster.
- ‫AWS_SUBNET_ID: רשת משנה ב-AWS באותו אזור כמו AWSCluster.
- ‫MINIMUM_NODE_COUNT: מספר הצמתים המינימלי במאגר הצמתים. מידע נוסף מופיע במאמר בנושא שינוי הגודל של אשכולות משתמשים.
- ‫MAXIMUM_NODE_COUNT: המספר המקסימלי של הצמתים במאגר הצמתים.
- ‫MAXIMUM_PODS_PER_NODE_COUNT: המספר המקסימלי של פודים ש-GKE ב-AWS יכול להקצות לצומת.
- ‫AWS_NODE_TYPE: סוג מכונה של AWS EC2.
- ‫KMS_KEY_PAIR_NAME: זוג המפתחות של AWS KMS שמוקצה לכל עובד במאגר הצמתים.
- ‫NODE_IAM_PROFILE: השם של פרופיל מכונת AWS EC2 שהוקצה לצמתים במאגר.
- ‫ROOT_VOLUME_SIZE: הגודל, בגיביבייט (GiB), של נפחי הבסיס של מישור הבקרה.
- ‫VOLUME_TYPE: סוג נפח האחסון ב-EBS של AWS של הצומת. לדוגמה, gp3.
- ‫IOPS: מספר פעולות הקלט/פלט (IOPS) שהוקצו לנפחי אחסון לשנייה. ההגדרה תקפה רק אם volumeType הוא gp3.
- ‫NODE_VOLUME_KEY: ה-ARN של מפתח AWS KMS ששימש להצפנת אמצעי האחסון. מידע נוסף מופיע במאמר בנושא שימוש במפתח CMK בניהול הלקוח להצפנת אמצעי אחסון.

מחילים את המניפסטים על שירות הניהול.

‫

env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f custom-cluster.yaml
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f custom-nodepools.yaml

יצירת קובץ kubeconfig

בזמן שה-user cluster מתחיל, אתם יכולים ליצור kubeconfigקונטקסט ל-user cluster החדש. ההקשר משמש לאימות למשתמש או לאשכול ניהול.

משתמשים ב-anthos-gke aws clusters get-credentials כדי ליצור kubeconfig לאשכול המשתמשים ב-~/.kube/config.
```
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם האשכול. לדוגמה, cluster-0.
משתמשים ב-kubectl כדי לבצע אימות לאשכול המשתמשים החדש.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl cluster-info
```
אם האשכול מוכן, הפלט כולל את כתובות ה-URL של רכיבי Kubernetes באשכול.

צפייה בסטטוס של האשכול

שירות הניהול מקצה משאבי AWS כשמחילים את AWSCluster או את AWSNodePool.

בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות הגישה שציינתם כשביצעתם את הפקודה aws configure.
כדי להציג את האשכולות, משתמשים בפקודה kubectl get AWSClusters.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl get AWSClusters
```
הפלט כולל את השם, המצב, הגיל, הגרסה ונקודת הקצה של כל אשכול.

לדוגמה, הפלט הבא כולל רק AWSCluster אחד בשם cluster-0:
```
NAME        STATE          AGE     VERSION         ENDPOINT
cluster-0   Provisioning   2m41s   1.25.5-gke.2100   gke-xyz.elb.us-east-1.amazonaws.com
```

הצגת האירועים של האשכול

כדי לראות אירועי Kubernetes מהזמן האחרון באשכול המשתמשים, משתמשים ב-kubectl get events.

בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות הגישה שציינתם כשביצעתם את הפקודה aws configure.

מריצים את kubectl get events.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get events

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

יצירת webhook של זהויות של עומסי עבודה

הקטע הזה מיועד לאדמינים של אשכולות.

כדי לספק לעומסי העבודה שלכם אישורים של Workload Identity ללא הגדרה נוספת, אתם יכולים ליצור webhook באשכולות המשתמשים. ה-webhook הזה מיירט בקשות ליצירת Pod ואז מעביר את פרטי AWS IAM הבאים כמשתני סביבה ל-Pod:

‫AWS_ROLE_ARN: שם המשאב ב-Amazon‏ (ARN) של תפקיד ה-IAM
‫aws-iam-token: הטוקן שהוחלף בפרטי הכניסה של AWS IAM
‫AWS_WEB_IDENTITY_TOKEN_FILE: הנתיב שבו שמור האסימון

באמצעות המשתנים האלה, עומסי העבודה יכולים להפעיל את כלי שורת הפקודה של AWS או שערכת ה-SDK יכולה לגשת למשאבים שהוקצו לתפקיד ב-AWS.

יצירת ה-webhook היא אופציונלית. אם תחליטו לא ליצור את ה-webhook, תצטרכו להגדיר את משתני הסביבה שצוינו קודם ב-Pod. למידע על אי-שימוש ב-webhook, ראו החלת פרטי כניסה בלי webhook.

יצירת קובצי YAML עבור ה-webhook

כדי לפרוס את ה-webhook, מבצעים את השלבים הבאים:

בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות הגישה שציינתם כשביצעתם את הפקודה aws configure.
מקבלים את שם אשכול המשתמש באמצעות kubectl:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl get awscluster
```
kubectl מציג את כל אשכולות המשתמשים. בוחרים את אשכול המשתמשים שיצרתם עם זהויות של עומסי עבודה.
מגדירים את שם האשכול במשתנה סביבה.
```
CLUSTER_NAME=CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם האשכול. לדוגמה, cluster-0.
מגדירים משתני סביבה עבור תמונת ה-Pod ומרחב השמות של זהות עומס העבודה.
```
IDENTITY_IMAGE=amazon/amazon-eks-pod-identity-webhook:ed8c41f

WEBHOOK_NAMESPACE=workload-identity-webhook
```

כדי ליצור את מניפסט ה-YAML של ה-webhook בקובץ בשם aws-webhook.yaml, פועלים לפי השלבים הבאים:

env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials ${CLUSTER_NAME}

CLUSTER_CA=$(env HTTPS_PROXY=http://localhost:8118 \
  kubectl config view --raw -o json  | jq -r '.clusters[] | select(.name == "'$(kubectl config current-context)'") | .cluster."certificate-authority-data"')

cat << EOF > aws-webhook.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: ${WEBHOOK_NAMESPACE}
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-identity-webhook
  namespace: ${WEBHOOK_NAMESPACE}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-identity-webhook
  namespace: ${WEBHOOK_NAMESPACE}
rules:
  - apiGroups: ['']
    resources: ['secrets']
    verbs: ['create']
  - apiGroups: ['']
    resources: ['secrets']
    verbs: ['get', 'update', 'patch']
    resourceNames:
      - pod-identity-webhook
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-identity-webhook
  namespace: ${WEBHOOK_NAMESPACE}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-identity-webhook
subjects:
  - kind: ServiceAccount
    name: pod-identity-webhook
    namespace: ${WEBHOOK_NAMESPACE}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-identity-webhook
rules:
  - apiGroups: ['']
    resources: ['serviceaccounts']
    verbs: ['get', 'watch',  'list']
  - apiGroups:  ['certificates.k8s.io']
    resources: ['certificatesigningrequests']
    verbs:  ['create', 'get', 'list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-identity-webhook
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pod-identity-webhook
subjects:
  - kind: ServiceAccount
    name: pod-identity-webhook
    namespace: ${WEBHOOK_NAMESPACE}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-identity-webhook
  namespace: ${WEBHOOK_NAMESPACE}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pod-identity-webhook
  template:
    metadata:
      labels:
        app: pod-identity-webhook
    spec:
      serviceAccountName: pod-identity-webhook
      containers:
        - name: pod-identity-webhook
          image: ${IDENTITY_IMAGE}
          imagePullPolicy: Always
          command:
            - /webhook
            - --in-cluster
            - --namespace=${WEBHOOK_NAMESPACE}
            - --service-name=pod-identity-webhook
            - --tls-secret=pod-identity-webhook
            - --annotation-prefix=eks.amazonaws.com
            - --token-audience=sts.amazonaws.com
            - --logtostderr
          volumeMounts:
            - name: webhook-certs
              mountPath: /var/run/app/certs
              readOnly: false
      volumes:
        - name: webhook-certs
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: pod-identity-webhook
  namespace: ${WEBHOOK_NAMESPACE}
  annotations:
    prometheus.io/port: '443'
    prometheus.io/scheme: https
    prometheus.io/scrape: 'true'
spec:
  ports:
    - port: 443
      targetPort: 443
  selector:
    app: pod-identity-webhook
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: pod-identity-webhook
  namespace: ${WEBHOOK_NAMESPACE}
webhooks:
  - name: pod-identity-webhook.amazonaws.com
    failurePolicy: Ignore
    sideEffects: 'None'
    admissionReviewVersions: ['v1beta1']
    clientConfig:
      service:
        name: pod-identity-webhook
        namespace: ${WEBHOOK_NAMESPACE}
        path: /mutate
      caBundle: ${CLUSTER_CA}
    rules:
      - operations: ['CREATE']
        apiGroups: ['']
        apiVersions: ['v1']
        resources: ['pods']
EOF

התוכן של aws-webhook.yaml מוכן להחלה על האשכול.

החלת ה-webhook על אשכול המשתמשים

כדי להחיל את ה-webhook על אשכול המשתמשים, מבצעים את השלבים הבאים.

מחילים את הקובץ aws-webhook.yaml על אשכול המשתמשים.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f aws-webhook.yaml

כשמחילים את המניפסט, ה-Pod של ה-webhook יוצר בקשות לחתימה על אישורים (CSR) של Kubernetes. אישור כל הבקשות מsystem:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook עם kubectl certificate approve.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl certificate approve $(env HTTPS_PROXY=http://localhost:8118 \ &&\
  kubectl get csr -o \
    jsonpath="{.items[?(@.spec.username==\"system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook\")].metadata.name}")

מוודאים שלא נשארו בקשות CSR שלא אושרו.

משתמשים באופרטור kubectl get csr כדי לבדוק שכל בקשות ה-CSR מהמבקש system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook אושרו:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl get csr
```
תשובה:
```
NAME        AGE   REQUESTOR                                            CONDITION
csr-mxrt8   10s   system:serviceaccount:default:pod-identity-webhook   Approved,Issued
```

הגדרת ספק OIDC של AWS

הקטע הזה מיועד לאדמינים של אשכולות.

כדי ליצור ספק OIDC ב-AWS,‏ AWS דורשת רשות אישורים (CA) ברמת ביניים או טביעת אצבע של אישור שרת. פרטי הכניסה של OIDC discovery מאוחסנים ב-storage.googleapis.com, עם אישור שחתום על ידי רשות אישורים (CA) ביניים בשם GTS CA 1C3. טביעת האצבע של רשות האישורים (CA) ברמת הביניים GTS CA 1C3 היא 08745487E891C19E3078C1F2A07E452950EF36F6.

כדי לרשום את דלי הגילוי של OIDC כספק OIDC ב-AWS:

בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות הגישה שציינתם כשביצעתם את הפקודה aws configure.

שומרים את כתובת ה-URL של מנפיק OIDC, את נתיב המארח של המנפיק ואת טביעת האצבע של Cloud Storage במשתני סביבה.

ISSUER_URL=$(env HTTPS_PROXY=http://localhost:8118 \
  kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.workloadIdentityInfo.issuerURL}')
ISSUER_HOSTPATH=${ISSUER_URL#"https://"}
CA_THUMBPRINT=08745487E891C19E3078C1F2A07E452950EF36F6

משתמשים בכלי aws של שורת הפקודה כדי ליצור ספק OIDC ב-AWS.

aws iam create-open-id-connect-provider \
  --url ${ISSUER_URL} \
  --thumbprint-list ${CA_THUMBPRINT} \
  --client-id-list sts.amazonaws.com

עדכון טביעת האצבע

אם Google מבצעת רוטציה של ה-CA עבור storage.googleapis.com, מריצים את הפקודות הבאות:

מעתיקים את טביעת האצבע של האישור המעודכן, 08745487E891C19E3078C1F2A07E452950EF36F6.
פועלים לפי ההוראות של הפקודה aws iam update-open-id-connect-provider-thumbprint. משתמשים ב-storage.googleapis.com בתור שם המארח של היעד וב-08745487E891C19E3078C1F2A07E452950EF36F6 בתור טביעת האצבע.

יצירה של תפקידים וכללי מדיניות ב-AWS IAM

הקטע הזה מיועד לאדמינים של אשכולות.

יוצרים תפקיד AWS IAM לקישור לחשבון שירות של Kubernetes. לתפקיד ב-IAM יש הרשאות ל-sts:AssumeRoleWithWebIdentity.

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

מחפשים או יוצרים מדיניות AWS IAM שמעניקה את ההרשאות הנדרשות לעומסי העבודה.

צריך את שם משאב Amazon‏ (ARN) של המדיניות AWS IAM policy. לדוגמה, arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.
מגדירים משתני סביבה עם פרטי האימות.
```
KSA_NAME=KUBERNETES_SERVICE_ACCOUNT
WORKLOAD_NAMESPACE=WORKLOAD_IDENTITY_NAMESPACE

AWS_ROLE_NAME=AWS_ROLE_NAME
AWS_POLICY=EXISTING_AWS_POLICY
```
מחליפים את מה שכתוב בשדות הבאים:
- KUBERNETES_SERVICE_ACCOUNT: השם של חשבון השירות החדש ב-Kubernetes
- ‫WORKLOAD_IDENTITY_NAMESPACE: השם של מרחב השמות שבו פועלים עומסי העבודה
- ‫AWS_ROLE_NAME: השם של תפקיד חדש ב-AWS לעומסי העבודה
- ‫EXISTING_AWS_POLICY: שם המשאב ב-Amazon‏ (ARN) של מדיניות AWS IAM קיימת. לדוגמה, arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.
בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות הגישה שציינתם כשביצעתם את הפקודה aws configure.

יוצרים מדיניות AWS IAM שמאפשרת לאשכול המשתמשים לקבל פרטי כניסה מאובטחים זמניים באמצעות AWS Security Token Service:

CLUSTER_ID=$(env HTTPS_PROXY=http://localhost:8118 \
  kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}')

# Get the ID Provider ARN
PROVIDER_ARN=$(aws iam list-open-id-connect-providers  \
| jq '.OpenIDConnectProviderList' \
| jq ".[] | select(.Arn |  contains(\"${CLUSTER_ID}\"))"   \
| jq  '.Arn' | tr -d '"')

# Create AWS role and policy
cat > irp-trust-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "${PROVIDER_ARN}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${ISSUER_HOSTPATH}:sub": "system:serviceaccount:${WORKLOAD_NAMESPACE}:${KSA_NAME}"
        }
      }
    }
  ]
}
EOF

כדי ליצור תפקיד AWS IAM עם המדיניות הזו ולצרף את המדיניות הקיימת לתפקיד, מריצים את הפקודות הבאות:

aws iam create-role \
  --role-name ${AWS_ROLE_NAME} \
  --assume-role-policy-document file://irp-trust-policy.json
aws iam update-assume-role-policy \
  --role-name ${AWS_ROLE_NAME} \
  --policy-document file://irp-trust-policy.json
aws iam attach-role-policy \
  --role-name ${AWS_ROLE_NAME} \
  --policy-arn ${AWS_POLICY}

כלי שורת הפקודה aws מאשר שהמדיניות מצורפת לתפקיד.

יצירת חשבונות שירות ב-Kubernetes לעומסי עבודה

הקטע הזה מיועד למפתחים או לאדמינים של אשכולות.

כדי ליצור חשבונות שירות ב-Kubernetes שמקושרים לתפקיד IAM ב-AWS שצוין קודם, מבצעים את השלבים הבאים:

בספריית anthos-aws, משתמשים ב-anthos-gke כדי להחליף הקשר לאשכול המשתמשים.
‫
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם אשכול המשתמש.

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

S3_ROLE_ARN=$(aws iam get-role \
  --role-name AWS_ROLE_NAME \
  --query Role.Arn --output text)

cat << EOF  > k8s-service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${KSA_NAME}
  namespace: WORKLOAD_IDENTITY_NAMESPACE
EOF

env HTTPS_PROXY=http://localhost:8118 \
kubectl apply -f k8s-service-account.yaml

env HTTPS_PROXY=http://localhost:8118 \
kubectl annotate sa --namespace ${WORKLOAD_NAMESPACE} ${KSA_NAME} eks.amazonaws.com/role-arn=${S3_ROLE_ARN}

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

‫AWS_ROLE_NAME: השם של תפקיד AWS IAM שרוצים להחיל על עומסי העבודה
‫WORKLOAD_IDENTITY_NAMESPACE: השם של מרחב השמות שבו פועלים עומסי העבודה

החלת פרטי כניסה על פודים

הקטע הזה מיועד למפתחים.

בקטע הזה מניחים שהטמעתם את ה-webhook של איחוד שירותי אימות הזהות של עומסי עבודה. אם לא פרסתם את ה-webhook, דלגו אל החלת פרטי כניסה ללא ה-webhook.

החלת פרטי כניסה באמצעות ה-webhook

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

הוספת חשבון השירות ל-Pod

כדי להשתמש ב-Workload Identity עם עומס עבודה, מוסיפים את חשבון השירות של Kubernetes לשדות הבאים:

לפריסה: spec.template.spec.serviceAccountName
ל-Pod: spec.serviceAccount

קובץ המניפסט של ה-Pod הבא מפעיל תמונה בסיסית של CentOS ומכיל את השדה spec.serviceAccount.

apiVersion: v1
kind: Pod
metadata:
  name: sample-centos-pod
  namespace: WORKLOAD_IDENTITY_NAMESPACE
spec:
  containers:
  - command:
    - /bin/bash
    - -ec
    - while :; do echo '.'; sleep 500 ; done
    image: amazon/aws-cli
    name: centos
  serviceAccount: KUBERNETES_SERVICE_ACCOUNT

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

‫WORKLOAD_IDENTITY_NAMESPACE: השם של מרחב השמות שבו פועלים עומסי העבודה
‫KUBERNETES_SERVICE_ACCOUNT: השם של חשבון השירות של Kubernetes שיצרתם קודם

בדיקה אם משתני הסביבה מוגדרים ב-Pods

כדי לבדוק אם משתני הסביבה מוגדרים ב-Pods, מריצים את הפקודה הבאה כדי לקבל את פרטי ה-Pod:

kubectl get pod --namespace WORKLOAD_IDENTITY_NAMESPACE POD_NAME -o yaml

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

‫WORKLOAD_IDENTITY_NAMESPACE: השם של מרחב השמות שבו פועלים עומסי העבודה
‫POD_NAME: השם של ה-Pod שרוצים לבדוק

הפלט מכיל את ערכי משתני הסביבה ב-spec.containers.command.env ואת נקודת הטעינה של אסימון AWS IAM. בהמשך מופיעה דוגמה למניפסט של Pod.

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  containers:
  - command:
    - /bin/bash
    - -ec
    - while :; do echo '.'; sleep 500 ; done
    env:
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::1234567890:role/my-example-workload-role-1
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    image: amazon/aws-cli
    imagePullPolicy: IfNotPresent
    name: centos
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: my-k8s-serviceaccount-token-d4nz4
      readOnly: true
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  serviceAccount: my-k8s-serviceaccount
  serviceAccountName: my-k8s-serviceaccount
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
  - name: my-k8s-serviceaccount-token-d4nz4
    secret:
      defaultMode: 420
      secretName: my-k8s-serviceaccount-token-d4nz4
   ...
status:
  ...

החלת פרטי כניסה ללא webhook

אם לא פורסים את ה-webhook של זהויות עומסי העבודה, צריך לבצע את הפעולות הבאות:

בודקים אם משתני הסביבה הבאים מוגדרים:
- ‫AWS_ROLE_ARN: שם המשאב ב-Amazon‏ (ARN) של תפקיד ה-IAM
- ‫AWS_WEB_IDENTITY_TOKEN_FILE: הנתיב שבו שמור האסימון
יוצרים נקודת טעינה לאסימון IAM ‏ (aws-iam-token) ולחשבון השירות שמשויך לתפקיד AWS IAM

יצירת Pod עם פרטי כניסה לזהות של עומס עבודה

כדי ליצור Pod שכולל את פרטי הכניסה הנדרשים לזהות עומס עבודה, מבצעים את השלבים הבאים:

מעתיקים את מניפסט ה-Pod הבא לקובץ בשם sample-pod-no-webhook.yaml. ההגדרה מפעילה תמונת CentOS בסיסית עם פרטי הכניסה הנדרשים.

apiVersion: v1
kind: Pod
metadata:
  name: sample-centos-pod-no-webhook
  namespace: WORKLOAD_IDENTITY_NAMESPACE
spec:
  containers:
  - command:
    - /bin/bash
    - -ec
    - while :; do echo '.'; sleep 500 ; done
    image: centos:7
    name: centos
    env:
    - name: AWS_ROLE_ARN
      value: IAM_ROLE_ARN
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    volumeMounts:
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
  serviceAccount: KUBERNETES_SERVICE_ACCOUNT

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

‫WORKLOAD_IDENTITY_NAMESPACE: השם של מרחב השמות שבו פועלים עומסי העבודה.
‫IAM_ROLE_ARN: ה-ARN של תפקיד ה-IAM שניתן ל-Pod. לדוגמה, arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess.
‫KUBERNETES_SERVICE_ACCOUNT: השם של חשבון השירות של Kubernetes שיצרתם קודם.

מחילים את מניפסט ה-Pod על האשכול באמצעות הפקודה kubectl:

env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f sample-pod-no-webhook.yaml

איך בודקים אם ל-Pods יש גישה למשאבי AWS

בקטע הבא מוסבר איך בודקים אם ה-Pod קיבל את פרטי הכניסה שדרושים כדי שהתכונה 'זהויות של עומסי עבודה' תפעל.

כדי להשלים את השלבים, אתם צריכים:

bash גישת shell לקונטיינר. ברוב תמונות הייצור אין shell זמין. בדוגמה הבאה אפשר לראות איך משתמשים ב-Pod שצוין בקטע הקודם כדי לגשת ל-AWS S3.
ל-Pod צריך להיות גישה יוצאת לאינטרנט כדי להוריד את ממשק שורת הפקודה של AWS.

כדי לבדוק אם ל-Pod יש גישה לקטגוריית S3, מבצעים את השלבים הבאים:

משתמשים בפקודה kubectl exec כדי להפעיל מעטפת bash אינטראקטיבית ב-Pod sample-centos-pod-no-webhook:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl exec -it --namespace ${WORKLOAD_NAMESPACE} sample-centos-pod-no-webhook -- bash
```
הטרמינל פותח את מעטפת ה-bash ב-Pod.

בודקים את ההרשאות ופרטי הכניסה של AWS IAM באמצעות הכלי aws:

aws sts assume-role-with-web-identity \
 --role-arn ${AWS_ROLE_ARN} \
 --role-session-name mh9test \
 --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token \
 --duration-seconds 1000

הכלי aws מדפיס פרטי כניסה שדומים לפרטים הבאים:

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAR2ZZZLEXVSDCDJ37N:mh9test",
        "Arn": "arn:aws:sts::126285863215:assumed-role/my-example-workload-role-1/mh9test"
    },
    "Audience": "sts.amazonaws.com",
    "Provider": "arn:aws:iam::126285863215:oidc-provider/storage.googleapis.com/gke-issuer-cec6c353",
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:my-s3-reader-ksa",
    "Credentials": {
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "MY_TOKEN",
        "Expiration": "2020-08-14T22:46:36Z",
        "AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
    }
}

אם מופיעה ההודעה הבאה, צריך לוודא שלמאגר יש גישה ציבורית: An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements

שדרוג ה-webhook

אם יצרתם אשכול Kubernetes בגרסה 1.18 או בגרסה ישנה יותר עם Workload Identity מופעל, וגרסת ה-webhook של Workload Identity היא release-0.2.2-gke.0, אתם צריכים לשדרג את ה-webhook לפני השדרוג ל-Kubernetes 1.19.

כדי לשדרג את ה-webhook, פועלים לפי השלבים הבאים:

מריצים את הפקודות הבאות כדי לוודא שה-webhook מותקן:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl get MutatingWebhookConfiguration
```
אם ה-webhook נפרס באשכול, הפלט כולל את הפרטים הבאים:
```
NAME                   WEBHOOKS   AGE
pod-identity-webhook   1          11m
```
אם ה-webhook לא נפרס באשכול, אפשר לדלג על השלבים הבאים.
אם שמרתם את קובץ aws-webhook.yaml, אתם יכולים למחוק את המניפסט. אם הקובץ הזה לא זמין, אפשר למחוק את הרכיבים של ה-webhook באופן ידני. בוחרים מתוך קובץ או רכיבים שבהמשך.
קובץ
אם עדיין יש לכם את קובץ aws-webhook.yaml, מריצים את הפקודה הבאה כדי למחוק את ה-webhook:
env HTTPS_PROXY=http://localhost:8118 \ kubectl delete -f aws-webhook.yaml
רכיבים
כדי למחוק את רכיבי ה-webhook באופן ידני, מריצים את הפקודות הבאות:
env HTTPS_PROXY=http://localhost:8118 \ kubectl delete namespace WEBHOOK_NAMESPACE env HTTPS_PROXY=http://localhost:8118 \ kubectl delete clusterrole pod-identity-webhook env HTTPS_PROXY=http://localhost:8118 \ kubectl delete clusterrolebinding pod-identity-webhook env HTTPS_PROXY=http://localhost:8118 \ kubectl delete mutatingwebhookconfiguration pod-identity-webhook
מחליפים את WEBHOOK_NAMESPACE במרחב השמות שבו התקנתם את ה-webhook של זהויות עומסי העבודה. לדוגמה – workload-identity-webhook.
כדי לבדוק אם יש לכם בקשות חתימה על אישורים (CSR) שנותרו, מריצים את הפקודה הבאה:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl get csr |grep pod-identity-webhook
```
אם הפלט ריק, דלגו לשלב הבא. אם יש בקשות CSR שנותרו, הפקודה kubectl תציג רשימה של בקשות CSR קיימות. כדי להסיר את בקשות ה-CSR, מריצים את הפקודה הבאה:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl delete csr $(kubectl get csr -o \
  jsonpath="{.items[?(@.spec.username==\"system:serviceaccount:WEBHOOK_NAMESPACE:pod-identity-webhook\")].metadata.name}")
```
מחליפים את WEBHOOK_NAMESPACE במרחב השמות שבו התקנתם את ה-webhook של זהויות עומסי העבודה. לדוגמה – workload-identity-webhook.
פועלים לפי השלבים במאמר יצירת webhook כדי לפרוס את הגרסה החדשה של ה-webhook.

אחרי שמפעילים את הגרסה החדשה של ה-webhook, צריך להפעיל מחדש את ה-Pods שמשתמשים ב-webhook. אפשר להפעיל מחדש את ה-Pods על ידי שדרוג אשכול משתמשים.

סידור וארגון

בקטע הזה מוסבר איך להסיר משאבים שיצרתם קודם במסמך הזה.

מנקים את חשבון השירות ואת תפקיד ה-IAM שמשויך אליו

כדי למחוק את חשבון השירות ואת תפקיד ה-IAM שמשויך אליו, מבצעים את השלבים הבאים:

מנקים את חשבון השירות:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl delete sa KUBERNETES_SERVICE_ACCOUNT --namespace WORKLOAD_IDENTITY_NAMESPACE
```
מחליפים את מה שכתוב בשדות הבאים:
- KUBERNETES_SERVICE_ACCOUNT: השם של חשבון השירות החדש ב-Kubernetes
- ‫WORKLOAD_IDENTITY_NAMESPACE: השם של מרחב השמות שבו פועלים עומסי העבודה
מנקים את התפקיד ב-AWS IAM. צריך לבחור אחת מהאפשרויות הבאות:
- מוחקים את תפקיד ה-IAM ב-AWS באמצעות מסוף AWS.
- מוחקים את התפקיד באמצעות כלי שורת הפקודה של AWS בעזרת הפקודות הבאות:
```
aws iam  detach-role-policy \
  --role-name=${AWS_ROLE_NAME} \
  --policy-arn=${AWS_POLICY}
aws iam delete-role --role-name=${AWS_ROLE_NAME}
```

מחיקת אשכול המשתמשים

כדי למחוק את אשכול המשתמשים, מבצעים את השלבים שמפורטים במאמר בנושא הסרת GKE on AWS.

ניקוי ספק OIDC של AWS

אחרי שמוחקים את אשכול המשתמשים, מבטלים את הרישום של ספק ה-OIDC ב-AWS ומוחקים אותו באמצעות פקודת המעטפת bash הבאה או מסוף AWS.

בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות הגישה שציינתם כשביצעתם את הפקודה aws configure.

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

CLUSTER_ID=$(env HTTPS_PROXY=http://localhost:8118 \
  kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}')

PROVIDER_ARN=$(aws iam list-open-id-connect-providers  \
| jq '.OpenIDConnectProviderList' \
| jq ".[] | select(.Arn |  contains(\"${CLUSTER_ID}\"))"   \
| jq  '.Arn' | tr -d '"')

aws iam delete-open-id-connect-provider \
  --open-id-connect-provider-arn=${PROVIDER_ARN}

יופיע אישור שספק ה-OIDC של AWS נמחק.

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

תפקידי IAM לחשבונות שירות (IRSA) ב-AWS משמשים את GKE ב-AWS לניהול זהויות של עומסי עבודה.
מידע נוסף על שימוש ב-Workload Identity עם Google Cloud

שימוש בזהות של עומס עבודה עם AWS קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

סקירה כללית

דרישות מוקדמות

הרשאות

כלים

יצירת קטגוריית גילוי OIDC

מתן הרשאות לחשבון השירות לניהול

יצירת אשכול משתמשים

יצירת אשכול משתמשים עם זהות עומס עבודה מופעלת

יצירת קובץ kubeconfig

צפייה בסטטוס של האשכול

הצגת האירועים של האשכול

יצירת webhook של זהויות של עומסי עבודה

יצירת קובצי YAML עבור ה-webhook

החלת ה-webhook על אשכול המשתמשים

הגדרת ספק OIDC של AWS

עדכון טביעת האצבע

יצירה של תפקידים וכללי מדיניות ב-AWS IAM

יצירת חשבונות שירות ב-Kubernetes לעומסי עבודה

החלת פרטי כניסה על פודים

החלת פרטי כניסה באמצעות ה-webhook

הוספת חשבון השירות ל-Pod

בדיקה אם משתני הסביבה מוגדרים ב-Pods

החלת פרטי כניסה ללא webhook

יצירת Pod עם פרטי כניסה לזהות של עומס עבודה

איך בודקים אם ל-Pods יש גישה למשאבי AWS

שדרוג ה-webhook

קובץ

רכיבים

סידור וארגון

מנקים את חשבון השירות ואת תפקיד ה-IAM שמשויך אליו

מחיקת אשכול המשתמשים

ניקוי ספק OIDC של AWS

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

שימוש בזהות של עומס עבודה עם AWS