יצירת משאבים ב-Google Cloud שתואמים למדיניות

במדריך הזה נסביר איך אדמינים של פלטפורמות יכולים להשתמש במדיניות של Policy Controller כדי לקבוע איך ליצור משאבי Google Cloud באמצעות Config Connector.

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

ההוראות במדריך הזה מניחות שיש לכם ידע בסיסי ב-Kubernetes או ב-Google Kubernetes Engine‏ (GKE). במדריך הזה מגדירים מדיניות שמגבילה את המיקומים המותרים לקטגוריות של Cloud Storage.

הכלי Policy Controller בודק את התאימות של משאבי אשכול Kubernetes למדיניות שקשורה לאבטחה, לתקנות או לכללים עסקיים, מבצע ביקורות ומחיל את המדיניות. ‫Policy Controller מבוסס על פרויקט הקוד הפתוח OPA Gatekeeper.

‫Config Connector יוצר ומנהל את מחזור החיים של Google Cloud משאבים, על ידי תיאור שלהם כמשאבים מותאמים אישית של Kubernetes. כדי ליצור Google Cloud משאב, יוצרים משאב Kubernetes במרחב שמות שמנוהל על ידי Config Connector. בדוגמה הבאה מוצג תיאור של קטגוריה של Cloud Storage באמצעות Config Connector:

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-bucket
spec:
  location: us-east1

אם מנהלים את Google Cloud המשאבים באמצעות Config Connector, אפשר להחיל על המשאבים את כללי המדיניות של Policy Controller בזמן שיוצרים אותם באשכול Google Kubernetes Engine. כללי המדיניות האלה מאפשרים לכם למנוע פעולות שיוצרות או משנות משאבים באופן שמפר את כללי המדיניות שלכם, או לדווח על פעולות כאלה. לדוגמה, אפשר לאכוף מדיניות שמגבילה את המיקומים של קטגוריות ב-Cloud Storage.

הגישה הזו, שמבוססת על Kubernetes resource model ‏ (KRM), מאפשרת לכם להשתמש באוסף עקבי של כלים ותהליכי עבודה כדי לנהל גם משאבי Kubernetes וגם משאבי Google Cloud . במדריך הזה מוסבר איך לבצע את הפעולות הבאות:

הגדרת כללי מדיניות שחלים על Google Cloud המשאבים.
הטמעת אמצעי בקרה שמונעים ממפתחים ומאדמינים ליצור משאבי Google Cloud שמפירים את המדיניות שלכם.
הטמעת אמצעי בקרה שמבצעים ביקורת על המשאבים הקיימים ב- Google Cloud בהתאם למדיניות שלכם, גם אם יצרתם את המשאבים האלה מחוץ ל-Config Connector.
לספק משוב מהיר למפתחים ולמנהלי מערכת כשהם יוצרים ומעדכנים הגדרות של משאבים.
מאמתים Google Cloud הגדרות של משאבים מול כללי המדיניות לפני שמנסים להחיל את ההגדרות על אשכול Kubernetes.

מטרות

יוצרים אשכול GKE שכולל את תוסף Config Connector.
מתקינים את Policy Controller.
יוצרים מדיניות להגבלת המיקומים המותרים של קטגוריות של Cloud Storage.
מוודאים שהמדיניות מונעת יצירה של דליים ב-Cloud Storage במיקומים שלא אושרו.
הערכת התאימות למדיניות של הגדרת קטגוריית Cloud Storage במהלך הפיתוח.
ביצוע ביקורת על קטגוריות קיימות של Cloud Storage כדי לוודא שהן עומדות בדרישות המדיניות.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

יכול להיות שמשתמשים חדשים ב- Google Cloud זכאים לתקופת ניסיון בחינם.

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

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Verify that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
ב-Cloud Shell, מגדירים את הפרויקט שבו רוצים להשתמש במדריך הזה: Google Cloud
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID בGoogle Cloud מזהה הפרויקט של הפרויקט. כשמריצים את הפקודה הזו, Cloud Shell יוצר משתנה סביבה מיוצא בשם GOOGLE_CLOUD_PROJECT שמכיל את מזהה הפרויקט. אם אתם לא משתמשים ב-Cloud Shell, אתם יכולים ליצור את משתנה הסביבה באמצעות הפקודה הבאה:
```
export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value core/project)
```

מפעילים את GKE API:

gcloud services enable container.googleapis.com

מפעילים את Policy Controller API:

gcloud services enable anthospolicycontroller.googleapis.com

יוצרים ספרייה לאחסון הקבצים שנוצרו במדריך הזה:
```
mkdir -p ~/cnrm-gatekeeper-tutorial
```
עוברים לספרייה שיצרתם:
```
cd ~/cnrm-gatekeeper-tutorial
```

יצירת אשכול GKE

ב-Cloud Shell, יוצרים אשכול GKE עם התוסף Config Connector ועם איחוד זהויות של עומסי עבודה ל-GKE:
```
gcloud container clusters create CLUSTER_NAME \
  --addons ConfigConnector \
  --enable-ip-alias \
  --num-nodes 4 \
  --release-channel regular \
  --scopes cloud-platform \
  --workload-pool $GOOGLE_CLOUD_PROJECT.svc.id.goog \
  --zone ZONE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול שרוצים להשתמש בו בפרויקט הזה, לדוגמה, cnrm-gatekeeper-tutorial.
- ‫ZONE: אזור Compute Engine שקרוב למיקום שלכם, לדוגמה, asia-southeast1-b.
התוסף Config Connector מתקין הגדרות מותאמות אישית של משאבים (CRD) עבור Google Cloud משאבים באשכול GKE.
אופציונלי: אם אתם משתמשים באשכול פרטי בסביבה שלכם, מוסיפים כלל לחומת האש שמאפשר למישור הבקרה של אשכול GKE להתחבר לתגובה לפעולה מאתר אחר (webhook) של Policy Controller:
```
gcloud compute firewall-rules create allow-cluster-control-plane-tcp-8443 \
  --allow tcp:8443 \
  --network default \
  --source-ranges CONTROL_PLANE_CIDR \
  --target-tags NODE_TAG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CONTROL_PLANE_CIDR: טווח כתובות ה-IP של מישור הבקרה של אשכול GKE, לדוגמה, 172.16.0.16/28.
- ‫NODE_TAG: תג שמוחל על כל הצמתים באשכול GKE.
כלל חומת האש האופציונלי הזה נדרש כדי שה-webhook של Policy Controller יפעל כשהאשכול משתמש בצמתים פרטיים.

הגדרה של Config Connector

הפרויקט שבו מתקינים את Config Connector נקרא פרויקט המארח. Google Cloud הפרויקטים שבהם משתמשים ב-Config Connector כדי לנהל משאבים נקראים פרויקטים מנוהלים. במדריך הזה, אתם משתמשים ב-Config Connector כדי ליצור משאביGoogle Cloud באותו פרויקט שבו נמצא אשכול GKE, כך שהפרויקט המארח והפרויקט המנוהל הם אותו פרויקט.

ב-Cloud Shell, יוצרים חשבון שירות של Google עבור Config Connector:
```
gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
  --display-name "Config Connector Gatekeeper tutorial"
```
מחליפים את SERVICE_ACCOUNT_NAME בשם שרוצים לתת לחשבון השירות, לדוגמה, cnrm-gatekeeper-tutorial. ‫Config Connector משתמש בחשבון השירות הזה ב-Google כדי ליצור משאבים בפרויקט המנוהל.
מקצים לחשבון השירות של Google את התפקיד Storage Admin:
```
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
  --member "serviceAccount:SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com" \
  --role roles/storage.admin
```
במדריך הזה משתמשים בתפקיד Storage Admin (אדמין אחסון) כי משתמשים ב-Config Connector כדי ליצור קטגוריות של Cloud Storage. בסביבה שלכם, צריך להעניק את התפקידים שנדרשים כדי לנהל את משאבי Google Cloud שרוצים ליצור עבור Config Connector. מידע נוסף על תפקידים מוגדרים מראש זמין במאמר הסבר על התפקידים במאמרי העזרה של IAM.
יוצרים מרחב שמות ב-Kubernetes למשאבי Config Connector שיוצרים במדריך הזה:
```
kubectl create namespace NAMESPACE
```
מחליפים את NAMESPACE במרחב השמות של Kubernetes שרוצים להשתמש בו במדריך, לדוגמה, tutorial.
מוסיפים הערה למרחב השמות כדי לציין באיזה פרויקט Config Connector צריך להשתמש כדי ליצור משאבים (הפרויקט המנוהל): Google Cloud
```
kubectl annotate namespace NAMESPACE \
    cnrm.cloud.google.com/project-id=$GOOGLE_CLOUD_PROJECT
```
יוצרים משאב ConfigConnectorContext שמאפשר ל-Config Connector לפעול במרחב השמות של Kubernetes, ומשייכים אותו לחשבון השירות של Google שיצרתם:
```
cat << EOF | kubectl apply -f -
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: NAMESPACE
spec:
  googleServiceAccount: SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com
EOF
```
כשיוצרים את המשאב ConfigConnectorContext, ‏ Config Connector יוצר חשבון שירות של Kubernetes ו-StatefulSet במרחב השמות cnrm-system כדי לנהל את משאבי Config Connector במרחב השמות.
מחכים עד ש-Pod של בקר Config Connector יהיה זמין במרחב השמות:
```
kubectl wait --namespace cnrm-system --for=condition=Ready pod \
  -l cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE
```
כשה-Pod מוכן, מופיעה ההנחיה של Cloud Shell. אם מופיעה ההודעה error: no matching resources found, צריך לחכות דקה ולנסות שוב.
כדי לקשור את חשבון השירות של Kubernetes ב-Config Connector לחשבון השירות של Google, צריך ליצור קשירת מדיניות IAM:
```
gcloud iam service-accounts add-iam-policy-binding \
  SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com \
  --member "serviceAccount:$GOOGLE_CLOUD_PROJECT.svc.id.goog[cnrm-system/cnrm-controller-manager-NAMESPACE]" \
  --role roles/iam.workloadIdentityUser
```
הקישור הזה מאפשר לחשבון השירות של cnrm-controller-manager-NAMESPACE Kubernetes במרחב השמות cnrm-system לפעול בתור חשבון השירות של Google שיצרתם.

התקנה של Policy Controller

פועלים לפי הוראות ההתקנה כדי להתקין את Policy Controller.

השתמשו במרווח ביקורת של 60 שניות.

יצירת Google Cloud משאב באמצעות Config Connector

ב-Cloud Shell, יוצרים מניפסט של Config Connector שמייצג קטגוריה של Cloud Storage באזור us-central1:

cat << EOF > tutorial-storagebucket-us-central1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-us-central1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: us-central1
  uniformBucketLevelAccess: true
EOF

כדי ליצור את הקטגוריה של Cloud Storage, מפעילים את המניפסט:
```
kubectl apply -f tutorial-storagebucket-us-central1.yaml
```
מוודאים ש-Config Connector יצר את הקטגוריה של Cloud Storage:
```
gcloud storage ls | grep tutorial
```
הפלט אמור להיראות כך:
```
gs://tutorial-us-central1-PROJECT_ID/
```
הפלט כולל את PROJECT_ID, שהוא מזהה הפרויקט. Google Cloud

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

הוספה של כלל מדיניות

מדיניות ב-Policy Controller מורכבת מתבנית אילוצים ומאילוץ. תבנית האילוצים מכילה את לוגיקת המדיניות. המגבלה מציינת איפה המדיניות חלה ואת פרמטרי הקלט ללוגיקה של המדיניות.

ב-Cloud Shell, יוצרים תבנית אילוצים שמגבילה את המיקומים של קטגוריות Cloud Storage:

cat << EOF > tutorial-storagebucket-location-template.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: gcpstoragelocationconstraintv1
spec:
  crd:
    spec:
      names:
        kind: GCPStorageLocationConstraintV1
      validation:
        openAPIV3Schema:
          properties:
            locations:
              type: array
              items:
                type: string
            exemptions:
              type: array
              items:
                type: string
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package gcpstoragelocationconstraintv1

      allowedLocation(reviewLocation) {
          locations := input.parameters.locations
          satisfied := [ good | location = locations[_]
                                good = lower(location) == lower(reviewLocation)]
          any(satisfied)
      }

      exempt(reviewName) {
          input.parameters.exemptions[_] == reviewName
      }

      violation[{"msg": msg}] {
          bucketName := input.review.object.metadata.name
          bucketLocation := input.review.object.spec.location
          not allowedLocation(bucketLocation)
          not exempt(bucketName)
          msg := sprintf("Cloud Storage bucket <%v> uses a disallowed location <%v>, allowed locations are %v", [bucketName, bucketLocation, input.parameters.locations])
      }

      violation[{"msg": msg}] {
          not input.parameters.locations
          bucketName := input.review.object.metadata.name
          msg := sprintf("No permitted locations provided in constraint for Cloud Storage bucket <%v>", [bucketName])
      }
EOF

מחילים את התבנית כדי ליצור את הקטגוריה של Cloud Storage:
```
kubectl apply -f tutorial-storagebucket-location-template.yaml
```

יוצרים אילוץ שמאפשר רק קטגוריות באזורים סינגפור וג'קרטה (asia-southeast1 ו-asia-southeast2). האילוץ חל על מרחב השמות שיצרתם קודם. הוא לא חל על קטגוריית Cloud Storage שמוגדרת כברירת מחדל עבור Cloud Build.

cat << EOF > tutorial-storagebucket-location-constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GCPStorageLocationConstraintV1
metadata:
  name: singapore-and-jakarta-only
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - storage.cnrm.cloud.google.com
      kinds:
      - StorageBucket
    namespaces:
    - NAMESPACE
  parameters:
    locations:
    - asia-southeast1
    - asia-southeast2
    exemptions:
    - ${GOOGLE_CLOUD_PROJECT}_cloudbuild
EOF

כדי להגביל את האזורים שבהם יכולים להתקיים מאגרי מידע, צריך להחיל את האילוץ:
```
kubectl apply -f tutorial-storagebucket-location-constraint.yaml
```

אימות המדיניות

יוצרים מניפסט שמייצג קטגוריה של Cloud Storage במיקום שאסור (us-west1):

cat << EOF > tutorial-storagebucket-us-west1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-us-west1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: us-west1
  uniformBucketLevelAccess: true
EOF

כדי ליצור את הקטגוריה של Cloud Storage, מפעילים את המניפסט:

kubectl apply -f tutorial-storagebucket-us-west1.yaml

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

Error from server ([singapore-and-jakarta-only] Cloud Storage bucket
<tutorial-us-west1-PROJECT_ID> uses a disallowed location
<us-west1>, allowed locations are ["asia-southeast1",
"asia-southeast2"]): error when creating
"tutorial-storagebucket-us-west1.yaml": admission webhook
"validation.gatekeeper.sh" denied the request: [singapore-and-jakarta-only]
Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a
disallowed location <us-west1>, allowed locations are
["asia-southeast1", "asia-southeast2"]

אופציונלי: אפשר לראות תיעוד של ההחלטה לדחות את הבקשה ביומני הביקורת של Cloud. שליחת שאילתה ליומני Admin Activity בפרויקט:

gcloud logging read --limit=1 \
    "logName=\"projects/$GOOGLE_CLOUD_PROJECT/logs/cloudaudit.googleapis.com%2Factivity\""'
    resource.type="k8s_cluster"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.location="ZONE"
    protoPayload.authenticationInfo.principalEmail!~"system:serviceaccount:cnrm-system:.*"
    protoPayload.methodName:"com.google.cloud.cnrm."
    protoPayload.status.code=7'

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

insertId: 3c6940bb-de14-4d18-ac4d-9a6becc70828
labels:
  authorization.k8s.io/decision: allow
  authorization.k8s.io/reason: ''
  mutation.webhook.admission.k8s.io/round_0_index_0: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"container-annotation-handler.cnrm.cloud.google.com","mutated":true}'
  mutation.webhook.admission.k8s.io/round_0_index_1: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"management-conflict-annotation-defaulter.cnrm.cloud.google.com","mutated":true}'
logName: projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
operation:
  first: true
  id: 3c6940bb-de14-4d18-ac4d-9a6becc70828
  last: true
  producer: k8s.io
protoPayload:
  '@type': type.googleapis.com/google.cloud.audit.AuditLog
  authenticationInfo:
    principalEmail: user@example.com
  authorizationInfo:
  - permission: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
    resource: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
  methodName: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
  requestMetadata:
    callerIp: 203.0.113.1
    callerSuppliedUserAgent: kubectl/v1.21.1 (linux/amd64) kubernetes/5e58841
  resourceName: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
  serviceName: k8s.io
  status:
    code: 7
    message: Forbidden
receiveTimestamp: '2021-05-21T06:56:24.940264678Z'
resource:
  labels:
    cluster_name: CLUSTER_NAME
    location: CLUSTER_ZONE
    project_id: PROJECT_ID
  type: k8s_cluster
timestamp: '2021-05-21T06:56:09.060635Z'

בשדה methodName מוצגת הפעולה שניסיתם לבצע, בשדה resourceName מוצג השם המלא של משאב Config Connector, ובקטע status מוצג שהבקשה נכשלה, עם קוד השגיאה 7 וההודעה Forbidden.

יוצרים קובץ מניפסט שמייצג קטגוריה של Cloud Storage במיקום מותר (asia-southeast1):

cat << EOF > tutorial-storagebucket-asia-southeast1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-asia-southeast1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: asia-southeast1
  uniformBucketLevelAccess: true
EOF

כדי ליצור את הקטגוריה של Cloud Storage, מפעילים את המניפסט:
```
kubectl apply -f tutorial-storagebucket-asia-southeast1.yaml
```
הפלט אמור להיראות כך:
```
storagebucket.storage.cnrm.cloud.google.com/tutorial-asia-southeast1-PROJECT_ID created
```
הפלט כולל את PROJECT_ID, שהוא מזהה הפרויקט. Google Cloud
בודקים ש-Config Connector יצר את הקטגוריה של Cloud Storage:
```
gcloud storage ls | grep tutorial
```
הפלט אמור להיראות כך:
```
gs://tutorial-asia-southeast1-PROJECT_ID/
gs://tutorial-us-central1-PROJECT_ID/
```
אם הפלט הזה לא מופיע, מחכים דקה ומבצעים את השלב הזה שוב.

מגבלות ביקורת

ב-Policy Controller, בקרת הביקורת מעריכה מעת לעת את המשאבים בהשוואה למגבלות שלהם. הבקר מזהה הפרות מדיניות במשאבים שנוצרו לפני ההגבלה, ובמשאבים שנוצרו מחוץ ל-Config Connector.

ב-Cloud Shell, מציגים את ההפרות של כל האילוצים שמשתמשים בתבנית האילוץ GCPStorageLocationConstraintV1:
```
kubectl get gcpstoragelocationconstraintv1 -o json \
  | jq '.items[].status.violations'
```
הפלט אמור להיראות כך:
```
[
  {
    "enforcementAction": "deny",
    "kind": "StorageBucket",
    "message": "Cloud Storage bucket <tutorial-us-central1-PROJECT_ID>
    uses a disallowed location <us-central1>, allowed locations are
    \"asia-southeast1\", \"asia-southeast2\"",
    "name": "tutorial-us-central1-PROJECT_ID",
    "namespace": "NAMESPACE"
  }
]
```
אתם רואים את הקטגוריה של Cloud Storage שיצרתם ב-us-central1 לפני שיצרתם את האילוץ.

הערה: מאפיין ברירת המחדל status.violations מציג עד 20 הפרות לכל אילוץ. אם בבקרת הביקורת נמצאו יותר מ-20 הפרות של אילוצים, השאר לא יוצגו. אם אתם נתקלים במגבלה הזו בסביבה שלכם, אתם יכולים ליצור כמה אילוצים.
מגדירים לכל אילוץ היקף שונה של מרחב שמות.

אימות משאבים במהלך הפיתוח

במהלך הפיתוח ובניית אינטגרציה רציפה (CI), מומלץ לאמת את המשאבים מול האילוצים לפני שמחילים את המשאבים האלה על אשכול GKE. האימות מספק משוב מהיר ומאפשר לכם לגלות בעיות במשאבים ובאילוצים בשלב מוקדם. בשלבים הבאים מוסבר איך לאמת משאבים באמצעות kpt. כלי שורת הפקודה kpt מאפשר לכם לנהל וליישם מניפסטים של משאבי Kubernetes.

ב-Cloud Shell, מריצים את gatekeeper הפונקציה של KRM באמצעות kpt:

kpt fn eval . --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false

פונקציית KRM היא תוכנית שיכולה לשנות או לאמת משאבי Kubernetes שמאוחסנים במערכת הקבצים המקומית כקבצי YAML. פונקציית ה-KRM‏ gatekeeper מאמתת את משאבי הקטגוריה של Cloud Storage ב-Config Connector מול מדיניות Gatekeeper. הפונקציה gatekeeper KRM ארוזה כקובץ אימג' של קונטיינר שזמין ב-Artifact Registry.

הפונקציה מדווחת שקובצי המניפסט של קטגוריות Cloud Storage באזורים us-central1 ו-us-west1 מפרים את האילוץ.

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

[RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
[FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
  Results:
    [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-central1.yaml"
    [ERROR] Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a disallowed location <us-west1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-west1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-west1.yaml"
  Stderr:
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-west1-PROJECT_IDT : Cloud Storage bucket <tutorial-us-west1-PROJECT_IDgt; uses a disallowed location <us-west1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
  Exit code: 1

אימות משאבים שנוצרו מחוץ ל-Config Connector

כדי לאמת משאבים שנוצרו מחוץ ל-Config Connector, אפשר לייצא את המשאבים. Google Cloud אחרי שמייצאים את המשאבים, אפשר להשתמש באחת מהאפשרויות הבאות כדי להעריך את מדיניות Policy Controller ביחס למשאבים המיוצאים:

מאמתים את המשאבים באמצעות הפונקציה gatekeeper KRM.
מייבאים את המשאבים אל Config Connector.

כדי לייצא את המשאבים, משתמשים במאגר משאבי ענן.

ב-Cloud Shell, מפעילים את Cloud Asset API:

gcloud services enable cloudasset.googleapis.com

מוחקים את קובצי המניפסט של משאבי Kubernetes עבור דלי Cloud Storage ב-us-central1 וב-us-west1:
```
rm tutorial-storagebucket-us-*.yaml
```

לייצא את כל המשאבים של Cloud Storage בפרויקט הנוכחי ולשמור את הפלט בקובץ בשם export.yaml:

gcloud beta resource-config bulk-export \
  --project $GOOGLE_CLOUD_PROJECT \
  --resource-format krm \
  --resource-types StorageBucket > export.yaml

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

Exporting resource configurations to stdout...

Export complete.

יוצרים פייפליין kpt על ידי שרשור של פונקציות KRM. בצינור הזה מתבצע אימות של המשאבים בספרייה הנוכחית מול מדיניות המיקום של קטגוריית Cloud Storage:

kpt fn source . \
  | kpt fn eval - --image=gcr.io/kpt-fn/set-namespace:v0.1 -- namespace=NAMESPACE \
  | kpt fn eval - --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false

למשאבים שמייצאים אין ערך למאפיין המטא נתונים namespace. בצינור הזה נעשה שימוש בפונקציית KRM שנקראת set-namespace כדי להגדיר את הערך namespace של כל המשאבים.

הפלט אמור להיראות כך, ויוצגו בו הפרות של המדיניות לגבי המשאבים שייצאתם:

[RUNNING] "gcr.io/kpt-fn/set-namespace:v0.1"
[PASS] "gcr.io/kpt-fn/set-namespace:v0.1"
[RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
[FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
  Results:
    [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "export.yaml"
  Stderr:
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
  Exit code: 1

אם Google Cloud בפרויקט יש קטגוריות של Cloud Storage שיצרתם לפני שהתחלתם לעבוד על המדריך הזה, והמיקום שלהן לא עומד בדרישות המגבלה, הקטגוריות שנוצרו קודם יופיעו בפלט.

סיימתם להגדיר מדיניות שקובעת את המיקום המותר של קטגוריות ב-Cloud Storage. המדריך הושלם. עכשיו אפשר להמשיך ולהוסיף מדיניות משלכם למשאבים אחרים. Google Cloud

פתרון בעיות

אם Config Connector לא יוצר את המשאבים Google Cloud הצפויים, אפשר להשתמש בפקודה הבאה ב-Cloud Shell כדי לראות את היומנים של מנהל הבקרה של Config Connector:

kubectl logs --namespace cnrm-system --container manager \
  --selector cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE

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

kubectl logs deployment/gatekeeper-controller-manager \
  --namespace gatekeeper-system

אם Policy Controller לא מדווח על הפרות בשדה status של אובייקטים של אילוצים, אפשר להציג את היומנים של בקר הביקורת באמצעות הפקודה הבאה:

kubectl logs deployment/gatekeeper-audit --namespace gatekeeper-system

אם נתקלתם בבעיות אחרות במדריך הזה, מומלץ לעיין במסמכים הבאים:

הסרת המשאבים

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

מחיקת הפרויקט

זהירות: כשמוחקים פרויקט:

התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
If the project that you plan to delete is attached to an organization, expand the Organization list in the Name column.
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

מחיקת המשאבים

אם רוצים לשמור את Google Cloud הפרויקט שבו השתמשתם במדריך הזה, צריך למחוק את המשאבים הבודדים.

ב-Cloud Shell, מוחקים את אילוץ המיקום של הקטגוריה ב-Cloud Storage:
```
kubectl delete -f tutorial-storagebucket-location-constraint.yaml
```
מוסיפים את ההערה cnrm.cloud.google.com/force-destroy עם ערך מחרוזת של true לכל משאבי storagebucket במרחב השמות שמנוהל על ידי Config Connector:
```
kubectl annotate storagebucket --all --namespace NAMESPACE \
  cnrm.cloud.google.com/force-destroy=true
```
ההערה הזו היא הנחיה שמאפשרת ל-Config Connector למחוק קטגוריה של Cloud Storage כשמוחקים את משאב storagebucket התואם באשכול GKE, גם אם הקטגוריה מכילה אובייקטים.
מוחקים את המשאבים של Config Connector שמייצגים את הקטגוריות של Cloud Storage:
```
kubectl delete --namespace NAMESPACE storagebucket --all
```

מחיקת אשכול GKE:

gcloud container clusters delete CLUSTER_NAME \
  --zone ZONE --async --quiet

מוחקים את הקישור של מדיניות Workload Identity ב-IAM:

gcloud iam service-accounts remove-iam-policy-binding \
  SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com \
  --member "serviceAccount:$GOOGLE_CLOUD_PROJECT.svc.id.goog[cnrm-system/cnrm-controller-manager-NAMESPACE]" \
  --role roles/iam.workloadIdentityUser

מוחקים את קישור התפקיד Cloud Storage Admin לחשבון השירות של Google:

gcloud projects remove-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
  --member "serviceAccount:SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com" \
  --role roles/storage.admin

מוחקים את חשבון השירות של Google שיצרתם עבור Config Connector:

gcloud iam service-accounts delete --quiet \
  SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

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

במאמר הזה מוסבר איך להפעיל אימות של Policy Controller כחלק מצינור עיבוד נתונים של אינטגרציה רציפה ב-Cloud Build.

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

מטרות

עלויות

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

יצירת אשכול GKE

הגדרה של Config Connector

התקנה של Policy Controller

יצירת Google Cloud משאב באמצעות Config Connector

הוספה של כלל מדיניות

אימות המדיניות

מגבלות ביקורת

אימות משאבים במהלך הפיתוח

אימות משאבים שנוצרו מחוץ ל-Config Connector

פתרון בעיות

הסרת המשאבים

מחיקת הפרויקט

מחיקת המשאבים

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

יצירת משאבים ב-Google Cloud שתואמים למדיניות