הגדרת Config Controller

בדף הזה מוסבר איך להגדיר את Config Controller.

‫Config Controller מספק מישור בקרה מנוהל שמבוסס על Kubernetes. בנוסף, מופעים של Config Controller מגיעים עם Policy Controller,‏ סנכרון תצורות ו-Config Connector שמותקנים מראש. באמצעות הרכיבים האלה, אפשר להשתמש בכלים ובתהליכי העבודה של Kubernetes כדי לנהל משאבים ולהשיג עקביות באמצעות תהליך עבודה של GitOps. Google Cloudסקירה כללית על Config Controller

אם אתם יוצרים מופע של Config Controller בפעם הראשונה, כדאי לעיין במאמר מדריך למתחילים: ניהול משאבים באמצעות Config Controller.

מגבלות

• מכיוון שמכונות Config Controller מנוהלות באופן מלא, אי אפשר לרשום אותן בצי.
• ‫Config Controller לא תומך בארכיטקטורת Arm.

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

לפני שמגדירים את Config Controller, צריך לבצע את השלבים הבאים:

1. מתקינים ומפעילים את Google Cloud CLI, שמספק את Google Cloud CLI שמשמש בהוראות האלה. אם אתם משתמשים ב-Cloud Shell,‏ Google Cloud CLI כבר מותקן.

2. ‫kubectl לא מותקן כברירת מחדל על ידי ה-CLI של Google Cloud, לכן צריך להתקין אותו:

   gcloud components install kubectl
   

3. מגדירים את Google Cloud הפרויקט שבו רוצים לארח את Config Controller:

   gcloud config set project PROJECT_ID
   

   מחליפים את PROJECT_ID ב Google Cloud פרויקט שיארח את Config Controller.

4. מפעילים את ממשקי ה-API הנדרשים:

   gcloud services enable krmapihosting.googleapis.com \
       container.googleapis.com  \
       cloudresourcemanager.googleapis.com \
       serviceusage.googleapis.com
   

יצירת מופע של Config Controller

אפשר ליצור מופע של Config Controller שמגובה על ידי אשכול רגיל או אשכול Autopilot. שני הסוגים של אשכולות הם פרטיים.

אם רוצים אפשרויות התאמה אישית נוספות, בוחרים באפשרות 'אשכול רגיל'. אם רוצים התקנה מהירה יותר, התאמה אוטומטית לעומס (autoscaling) של Pods אופקיים והתאמה אנכית של קבוצות Pod לעומס ותכונות אבטחה משופרות כמו מערכת הפעלה שמותאמת לקונטיינרים, צומתי GKE מוגנים, איחוד זהויות של עומסי עבודה ל-GKE ואתחול מאובטח, בוחרים באשכול Autopilot.

יצירת אשכול חדש יכולה להימשך עד 15 דקות. כדי לראות מה קורה במהלך היצירה, אפשר להציג את Logs Explorer במסוףGoogle Cloud .

כניסה לדף Logs Explorer

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

יצירת אשכול Autopilot

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

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION \
    --full-management

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

• ‫CONFIG_CONTROLLER_NAME: השם שרוצים לתת למופע של Config Controller.
• ‫LOCATION: המיקום שבו רוצים ליצור את מופע Config Controller, לדוגמה us-central1. רשימת המיקומים הנתמכים מופיעה במאמר מיקומים.

יצירת אשכול רגיל

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

gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
    --location=LOCATION

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

• ‫CONFIG_CONTROLLER_NAME: השם שרוצים לתת למופע של Config Controller.
• ‫LOCATION: המיקום שבו רוצים ליצור את מופע Config Controller, לדוגמה us-central1. רשימת המיקומים הנתמכים מופיעה במאמר מיקומים.

כשיוצרים מכונה רגילה של Config Controller, אפשר להגדיר כמה פרמטרים אופציונליים. הרשימה המלאה של האפשרויות זמינה במאמרי העזרה בנושא gcloud anthos config controller create.

אישור מופע Config Controller

כדי לוודא שמופע Config Controller מוגדר, מבצעים את השלבים הבאים:

1. כדי לוודא שמופעים של Config Controller נוצרו, מציגים את רשימת המופעים של Config Controller:

   gcloud anthos config controller list --location=LOCATION
   

   בעמודת הסטטוס אמור להופיע הערך RUNNING. אם הסטטוס הוא CREATING, המשמעות היא שעדיין מתבצעת יצירה של מופע Config Controller, וצריך להמשיך להמתין. אם מופיע הסמל ERROR, נתקלתם בבעיה שאי אפשר לפתור לבד. לקבלת עזרה, אפשר לפנות לתמיכה של Google Cloud.

2. כדי לתקשר עם נקודת הקצה של Config Controller, צריך לקבל את פרטי הכניסה המתאימים ואת פרטי נקודת הקצה:

   gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
       --location LOCATION
   

שימוש במופע Config Controller

אחרי שיצרתם מכונה של Config Controller, אתם יכולים להתחיל להשתמש ברכיבים המותקנים ולבצע את המשימות הבאות:

• שימוש ב-Config Connector כדי ליצור Google Cloud משאבים. אם יש לכם Google Cloud משאבים קיימים שאתם רוצים להשתמש בהם עם Config Controller, כדאי לקרוא על הוספת משאב קיים.

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

• אחרי הגדרת סנכרון תצורות, בסעיף הבא, מסנכרנים את מופע Config Controller עם ההגדרות (כולל אילוצי Policy Controller ומשאבי Config Connector) שמאוחסנות במקור האמת.

דוגמה מודרכת להשלמת המשימות האלה באמצעות Config Controller מופיעה במאמר מדריך למתחילים: ניהול משאבים באמצעות Config Controller.

הגדרת מופע Config Controller

בקטעים הבאים מוסבר איך להגדיר את הרכיבים של מופע Config Controller.

אזהרה: אל תערכו, תעדכנו או תמחקו את אשכול Google Kubernetes Engine שתומך במופע של Config Controller, כי אתם עלולים לגרום נזק למופע של Config Controller. מידע נוסף זמין במאמר בנושא שינויים ב-Config Controller שלא נתמכים.

הגדרת Config Connector

לא צריך לנהל הגדרות כלשהן להתקנה של Config Connector. עם זאת, צריך להעניק ל-Config Controller הרשאות לניהול משאביGoogle Cloud :

1. מגדירים משתנה סביבה לכתובת האימייל של חשבון השירות:

   export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
       -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
   

2. יוצרים את הקישור של המדיניות:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:${SA_EMAIL}" \
       --role "ROLE" \
       --project PROJECT_ID
   

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

   • ‫PROJECT_ID: מזהה הפרויקט
   • ROLE: קבוצה של תפקידים מוגדרים מראש או תפקידים בהתאמה אישית שעונים על הצרכים שלכם. לחלופין, אפשר להשתמש ב-roles/owner בסביבות שאינן סביבות ייצור. במאמר הרשאות IAM ל-Config Controller אפשר לקרוא מידע נוסף על הרשאות IAM ל-Config Controller.

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

   kubectl wait pod --all --all-namespaces --for=condition=Ready
   

אחרי שמעניקים את ההרשאות האלה, אפשר להתחיל ליצור Google Cloudמשאבים.

הגדרת Policy Controller

יכול להיות שתצטרכו להוסיף או לעדכן את מדיניות IAM כדי לאפשר ל-Policy Controller לשלוח מדדים.

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

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[gatekeeper-system/gatekeeper-admin]" \
  --role=roles/monitoring.metricWriter

מחליפים את PROJECT_ID במזהה הפרויקט של האשכול. Google Cloud

הגדרת סנכרון תצורות

אם רוצים שמופע Config Controller יסנכרן הגדרות שמאוחסנות במקור אמת, צריך להגדיר את Config Sync.

אם אתם רוצים להשתמש ב-Config Sync כדי ליצור משאבים של Config Connector, אתם צריכים לוודא שהענקתם ל-Config Controller הרשאה לנהל משאבים.

כדי להגדיר את סנכרון תצורות, יוצרים ועורכים אובייקט RootSync:

1. כדי לבצע סנכרון ממאגר חיצוני (לדוגמה, GitHub), צריך להגדיר Cloud NAT עם GKE. צריך לעשות את זה כי לצמתים של אשכול פרטי אין גישה לאינטרנט היוצא.

2. שומרים אחד מהקובצי המניפסט הבאים בשם root-sync.yaml. משתמשים בגרסת המניפסט שמתאימה לסוג המקור של ההגדרות.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: unstructured
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

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

   • ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
   • ROOT_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git לשימוש כמאגר הבסיסי. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
   • ‫ROOT_REVISION: מוסיפים את הגרסה של Git (תג או גיבוב) או את ההסתעפות שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
   • ‫ROOT_BRANCH: מוסיפים את ההסתעפות של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. מומלץ להשתמש בשדה revision כדי לציין שם של ענף, כדי לפשט את התהליך. אם מציינים גם את השדה revision וגם את השדה branch, השדה revision מקבל עדיפות על פני השדה branch.
   • ROOT_DIRECTORY: מוסיפים את הנתיב במאגר Git לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.

   • ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:

     • ‫none: לא להשתמש באימות
     • ‫ssh: שימוש בזוג מפתחות SSH
     • cookiefile: שימוש ב-cookiefile
     • ‫token: שימוש בטוקן
     • ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת ל-Cloud Source Repositories.
     • ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת אל Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.

     מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישת קריאה בלבד ל-Git ב-סנכרון תצורות.

     חובה למלא את השדה הזה.

   • ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, צריך להוסיף את המפתח הציבורי של הסוד לספק Git. השדה הזה הוא אופציונלי.

   • ‫ROOT_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.

   • ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.

     מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

   הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

   קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Git כמקור.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: unstructured
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

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

   • ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
   • ‫ROOT_IMAGE: כתובת ה-URL של תמונת OCI שבה רוצים להשתמש כמאגר הבסיס, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נמשכת מהתג latest, אבל אפשר למשוך תמונות באמצעות התגים TAG או DIGEST. מציינים TAG או DIGEST במאפיין PACKAGE_NAME:
     • כדי למשוך לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • כדי למשוך לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   זהירות: סנכרון תצורות דורש ששכבת ה-OCI תידחס בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר מ-REPO תקין לתמונת OCI עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.

   • ‫ROOT_DIRECTORY: מוסיפים את הנתיב במאגר לספריית הרמה הבסיסית (root) שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.

   • ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:

     • ‫none: לא להשתמש באימות
     • ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
     • ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.

     חובה למלא את השדה הזה.

   • ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.

   מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

   הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

   קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש בתמונה של OCI כמקור.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: unstructured
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

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

   • ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
   • ‫ROOT_HELM_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
   • ‫HELM_CHART_NAME: מוסיפים את השם של תרשים Helm. חובה למלא את השדה הזה.
   • ‫HELM_CHART_VERSION: הגרסה של התרשים. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש בגרסה האחרונה.
   • ‫HELM_RELEASE_NAME: השם של מהדורת Helm. השדה הזה הוא אופציונלי.
   • ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. היא מגדירה מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש במרחב השמות שמוגדר כברירת מחדל config-management-system.
   • ‫HELM_INCLUDE_CRDS: צריך להגדיר את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא תציינו ערך, ברירת המחדל היא false ולא ייווצר CRD.
   • ‫VALUE: ערכים לשימוש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. הפורמט של השדה הזה צריך להיות זהה לפורמט של קובץ values.yaml של תרשים helm. השדה הזה הוא אופציונלי.

   • ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:

     • ‫none: לא להשתמש באימות
     • ‫token: משתמשים בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
     • ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
     • ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.

     חובה למלא את השדה הזה.

   • ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.

   • ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Helm שלכם חייב להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.

   מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

   הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

   קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Helm כמקור.

3. כדי ליצור את התצורה של סנכרון תצורות, יוצרים אובייקט RootSync על ידי החלת המניפסט:

   kubectl apply -f root-sync.yaml
   

4. כדי לוודא שהשינויים שלכם הוחלו, צופים באובייקט RootSync:

   kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system
   

שדרוג Config Controller

‫Config Controller הוא שירות מנוהל, ולכן Google משדרגת אותו באופן אוטומטי. פרטים על התכונות החדשות ומידע על הגרסאות של סנכרון תצורות, Policy Controller ו-Config Connector שבהן משתמש Config Controller זמינים בהערות הגרסה של Config Controller.

מחיקת מופע של Config Controller

אם מחליטים להפסיק להשתמש במופע של Config Controller, צריך לנקות את כל המשאבים של Config Connector שנוצרו לפני שמוחקים את אשכול Config Controller עצמו.

אם מוחקים את מופע Config Controller בלי למחוק קודם את המשאבים שהוקצו, המשאבים נשארים במצב נטוש. המשאבים עדיין קיימים ב- Google Cloud (ויחויבו), אבל לא מנוהלים מהגדרת הצהרה.

אחרי שמוחקים את כל המשאבים, מוחקים את אשכול Config Controller:

gcloud anthos config controller delete \
    --location=LOCATION CONFIG_CONTROLLER_NAME

שיקולים בהפקה

כשעוברים לסביבת ייצור, כדאי קודם לעיין בשיקולים לגבי זמינות גבוהה של Config Controller.

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

• שיטות מומלצות למדרגיות של Config Controller
• פריסת עומסי עבודה בהתאמה אישית באשכולות Config Controller
• פתרון בעיות ב-Config Controller
• פנייה לתמיכה
• מידע נוסף על סנכרון הגדרות ומדיניות באמצעות Config Sync
• מידע נוסף על אכיפת מדיניות באמצעות Policy Controller
• מידע נוסף על משאבי Config Connector