הענקת גישה ל-Config Sync למאגר Git

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

בחירה של שיטת אימות

שיטת האימות שבה משתמשים תלויה במה שנתמך בסוג המקור שלכם.

בטבלה הבאה מפורטות שיטות האימות שאפשר להשתמש בהן עם סנכרון תצורות:

‏Method	מקורות נתמכים	תיאור	מגבלות
ללא אימות	‫Git, ‏ OCI, ‏ Helm	לא נדרשת הגדרה נוספת.	האפשרות הזו פועלת רק אם מקור האמת שלכם הוא ציבורי.
זוג מפתחות SSH	Git	רוב ספקי Git תומכים בשיטה הזו.	נדרש ניהול מפתחות. אין תמיכה ב-OCI או ב-Helm.
token	‫Git, ‏ Helm	רוב ספקי Git תומכים בשיטה הזו. אפשרות חלופית טובה אם הארגון שלכם לא מאפשר שימוש במפתחות SSH. תמיכה בשם משתמש ובסיסמה ל-Helm.	נדרש ניהול טוקנים. יכול להיות שתוקף הטוקנים יפוג. לא אפשרי ב-OCI.
חשבון שירות של Kubernetes	OCI, ‏ Helm	משתמש ב-IAM כדי להעניק ל-Artifact Registry גישה ישירה לחשבון שירות של Kubernetes. נדרשת הפעלה של איחוד זהויות של עומסי עבודה ל-GKE באשכול.	אין תמיכה ב-Git.
חשבון שירות של Google	Git	השימוש ב-IAM מאפשר להימנע מאחסון פרטי כניסה בסודות של Kubernetes. מומלץ ל-Secure Source Manager ול-Cloud Source Repositories. נדרשת הפעלה של איחוד זהויות של עומסי עבודה ל-GKE באשכול.	נדרשת הגדרה לפני ואחרי התקנת סנכרון תצורות באשכולות. אין תמיכה במאגרי מידע שמתארחים מחוץ ל-Secure Source Manager או ל-Cloud Source Repositories.
GitHub App	Git	שילוב ישיר עם GitHub. מאפשר הרשאות פרטניות.	האפשרות הזו נתמכת רק במאגרים שמארחים ב-GitHub.

‫סנכרון תצורות תומך גם בשיטות האימות הבאות, אבל מומלץ להשתמש בהן רק אם אי אפשר להשתמש באחת מהאפשרויות שמפורטות בטבלה הקודמת:

יכול להיות שלא תהיה תמיכה ב-cookiefile: אצל כל ספקי Git. אין תמיכה ב-OCI או ב-Helm.
חשבון השירות של Compute Engine שמוגדר כברירת מחדל (gcenode): לא מומלץ כי השיטה הזו פועלת רק אם איחוד זהויות של עומסי עבודה ל-GKE מושבת. נתמך ב-Git, ב-OCI וב-Helm.
חשבון שירות של Google ל-Helm ול-OCI: נתמך, אבל לא מומלץ כי שיטת חשבון השירות של Kubernetes דורשת פחות הגדרות.

אימות באמצעות חבילות של צי רכבים

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

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

לפני שנותנים ל-סנכרון תצורות גישת קריאה בלבד למאגר Git, צריך לבצע את המשימות הבאות:

מכינים מאגר Git או מקבלים גישה למאגר Git שבו מאחסנים את קובצי ההגדרות שרוצים לסנכרן באמצעות Config Sync. מידע נוסף זמין במקורות המידע הבאים:
- הוספת הגדרות למקור האמת: מידע תיאורטי על הגדרות.
- שיטות מומלצות ל-GitOps: טיפים ושיטות מומלצות כלליות לארגון ולניהול של המאגר.
- שימוש במאגר לא מובנה: המלצות לשימוש במאגר לא מובנה ולארגון שלו.
ליצור אשכול GKE או לקבל גישה לאשכול כזה. לפני שיוצרים אשכול, כדאי לעיין בדרישות ובהמלצות להגדרת אשכול ל-סנכרון תצורות.

שימוש בזוג מפתחות SSH

זוג מפתחות SSH מורכב משני קבצים: מפתח ציבורי ומפתח פרטי. ‫סנכרון תצורות לא תומך ביצירת ביטויי סיסמה. בהתאם לדרישות האבטחה והתאימות שלכם, אתם יכולים להשתמש בצמד מפתחות יחיד לכל האשכולות, או בצמד מפתחות לכל אשכול.

כדי להעניק ל-סנכרון תצורות גישת קריאה בלבד למאגר Git באמצעות זוג מפתחות SSH, מבצעים את השלבים הבאים:

יוצרים זוג מפתחות SSH או מבקשים מאדמין האבטחה לספק לכם זוג מפתחות. אם אתם צריכים ליצור זוג מפתחות SSH, אתם יכולים ליצור מפתח RSA של 4096 ביט על ידי הרצת הפקודה הבאה:
```
ssh-keygen -t rsa -b 4096 \
  -C "GIT_REPOSITORY_USERNAME" \
  -N '' \
  -f /path/to/KEYPAIR_FILENAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫GIT_REPOSITORY_USERNAME: שם המשתמש שרוצים שסנכרון תצורות ישתמש בו כדי לבצע אימות למאגר. אם אתם משתמשים במארח מאגרי Git של צד שלישי כמו GitHub, או שאתם רוצים להשתמש בחשבון שירות עם Secure Source Manager, מומלץ להשתמש בחשבון נפרד לאימות.
- ‫/path/to/KEYPAIR_FILENAME: הנתיב לקובץ של זוג המפתחות.
מגדירים את המאגר כך שיזהה את המפתח הציבורי החדש שנוצר. אפשר לעיין בתיעוד של ספק האירוח של Git. ברשימה הבאה מופיעות הוראות לכמה ספקי אירוח נפוצים של Git:
יוצרים את הסוד git-creds עם המפתח הפרטי:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
```
הערה: אם אתם צריכים להשתמש בשרת proxy, צריך להעביר את הדגל --from-literal=https_proxy=HTTPS_PROXY_URL.

מחליפים את /path/to/KEYPAIR_PRIVATE_KEY_FILENAME בשם של המפתח הפרטי.
אופציונלי, אבל מומלץ: כדי להגדיר בדיקה של מארחים מוכרים כשמשתמשים באימות SSH, מוסיפים את מפתח המארחים המוכרים לשדה data.known_hosts ב-Secret‏ git_creds.
1. כדי להוסיף את המפתח של המארחים המוכרים, מריצים את הפקודה הבאה:
```
kubectl edit secret git-creds --namespace=config-management-system
```
2. כדי להוסיף את הרשומה known_hosts מתחת ל-data, מריצים את הפקודה הבאה:
```
  known_hosts: KNOWN_HOSTS_KEY
```
  מחליפים את KNOWN_HOSTS_KEY במפתח של המארחים המוכרים.
כדי להשבית את הבדיקה של known_hosts, מסירים את השדה known_hosts מהסוד.

כשמתקינים את סנכרון תצורות, משתמשים בזוג מפתחות SSH ‏ (ssh) כסוג האימות.

כשמזינים את כתובת ה-URL של מאגר Git, היא צריכה להיות בפורמט של פרוטוקול SSH. הפורמט של כתובת ה-URL משתנה בהתאם לספק של Git.

שימוש בקובץ cookie

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

כדי להעניק ל-סנכרון תצורות גישת קריאה בלבד למאגר Git באמצעות cookiefile, מבצעים את השלבים הבאים:

אחרי שיוצרים את cookiefile או מקבלים אותו, מוסיפים אותו לסוד חדש באשכול. מומלץ להשתמש ב-HTTPS מטעמי אבטחה:

kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-file=cookie_file=/path/to/COOKIEFILE

מחליפים את /path/to/COOKIEFILE בנתיב ובשם הקובץ.

כשמתקינים את סנכרון תצורות, צריך להשתמש ב-cookiefile ‏ (cookiefile) כסוג האימות.

שימוש בטוקן

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

כדי להעניק ל-סנכרון תצורות גישת קריאה בלבד למאגר Git באמצעות אסימון, מבצעים את השלבים הבאים:

יוצרים טוקן מספק Git. לקבלת הוראות, יש לעיין בתיעוד של ספק האירוח של Git. ברשימה הבאה מופיעות הוראות לכמה ספקי אירוח נפוצים של Git:
- ‫GitHub: יצירת PAT. נותנים לטוקן את ההיקף repo כדי שהוא יוכל לקרוא ממאגרים פרטיים. מכיוון שמקשרים PAT לחשבון GitHub, מומלץ גם ליצור משתמש מכונה ולקשר את ה-PAT למשתמש המכונה.
- ‫GitLab: יצירת PAT או יצירת טוקן פריסה.
- ‫Bitbucket: יצירת סיסמה לאפליקציה
אחרי שיוצרים או מקבלים טוקן, מוסיפים אותו ל-Secret חדש באשכול. מומלץ להשתמש ב-HTTPS מטעמי אבטחה:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=username=USERNAME \
  --from-literal=token=TOKEN
```
הערה: אם אתם צריכים להשתמש בשרת proxy, צריך להעביר את הדגל --from-literal=https_proxy=HTTPS_PROXY_URL.

מחליפים את מה שכתוב בשדות הבאים:
- ‫USERNAME: שם המשתמש שרוצים להשתמש בו.
- ‫TOKEN: האסימון שיצרתם בשלב הקודם.

כשמתקינים את סנכרון תצורות, צריך להשתמש בטוקן (token) כסוג האימות.

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

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

המאגר נמצא ב-Secure Source Manager או ב-Cloud Source Repositories.
באשכול מופעל איחוד זהויות של עומסי עבודה ל-GKE או איחוד זהויות של עומסי עבודה ל-GKE בצי.

כדי לתת ל-Config Sync גישת קריאה בלבד למאגר Git באמצעות חשבון שירות של Google, מבצעים את השלבים הבאים:

כדי לקבל את ההרשאות שנדרשות ליצירת קשירת מדיניות, צריך לבקש מהאדמין להקצות לכם ב-IAM את התפקיד אדמין של חשבון שירות (roles/iam.serviceAccountAdmin) בחשבון השירות. להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
אם עדיין אין לכם חשבון שירות, יוצרים חשבון שירות.
מקצים את תפקיד ה-IAM לחשבון השירות של Google, בהתאם לסוג המאגר שבו אתם משתמשים:
Secure Source Manager
מקצים לחשבון השירות של Google את תפקידי ה-IAM הבאים: Secure Source Manager Instance Accessor (roles/securesourcemanager.instanceAccessor) ו-Secure Source Manager Repo Reader (roles/securesourcemanager.repoReader):
- אם אותן הרשאות חלות על כל המאגרים בפרויקט, מעניקים הרשאה לכל הפרויקט:
  gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/securesourcemanager.instanceAccessor \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
  gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/securesourcemanager.repoReader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
  מחליפים את מה שכתוב בשדות הבאים:
  - PROJECT_ID: מזהה הפרויקט.
  - ‫GSA_NAME: השם של חשבון השירות של Google שרוצים לקשר ל-Secure Source Manager.
- כדי להעניק הרשאה ספציפית למאגר, אפשר לעיין במסמכי Secure Source Manager בנושא הענקת תפקידים למשתמשים ברמת המאגר.
כשמתקינים את סנכרון תצורות, משתמשים בWorkload Identity (gcpserviceaccount) כסוג האימות. צריך גם להוסיף את כתובת האימייל של חשבון השירות.

ב-Secure Source Manager נדרש פורמט ספציפי לכתובת ה-URL של המאגר: https://SSM_INSTANCE_ID-PROJECT_NUMBER-git.INSTANCE_LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git.
Cloud Source Repositories
מקצים לחשבון השירות של Google את תפקיד ה-IAM 'קורא Cloud Source Repositories' (roles/source.reader):
- אם אותן הרשאות חלות על כל המאגרים בפרויקט, מעניקים הרשאה לכל הפרויקט:
  gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/source.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
  מחליפים את מה שכתוב בשדות הבאים:
  - PROJECT_ID: מזהה הפרויקט.
  - ‫GSA_NAME: השם של חשבון השירות של Google שרוצים לקשר ל-Cloud Source Repositories.
- כדאי להעניק הרשאה ספציפית למאגר כשרוצים שלחשבונות שירות יהיו רמות גישה שונות לכל מאגר בפרויקט:
  gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
  מחליפים את מה שכתוב בשדות הבאים:
  - PROJECT_ID: מזהה הפרויקט.
  - ‫REPOSITORY: שם המאגר.
  - ‫POLICY_FILE: קובץ ה-JSON או ה-YAML שמכיל את מדיניות ניהול הזהויות והרשאות הגישה.
כשמתקינים את סנכרון תצורות, משתמשים בWorkload Identity ‏ (gcpserviceaccount) כסוג האימות. צריך גם להוסיף את כתובת האימייל של חשבון השירות.

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

gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID

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

‫FLEET_HOST_PROJECT_ID: אם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך זהה לערך של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE ב-Fleet, צריך להשתמש במזהה הפרויקט של ה-Fleet שהאשכול רשום בו כערך.
‫GSA_NAME: חשבון השירות המותאם אישית של Google שבו רוצים להשתמש כדי להתחבר ל-Secure Source Manager או ל-Cloud Source Repositories.
‫KSA_NAME: חשבון השירות של Kubernetes עבור ה-reconciler. ברוב המקרים, הערך הוא root-sync כי סנכרון תצורות יוצר באופן אוטומטי אובייקט RootSync בשם root-sync כשהוא מותקן באמצעות המסוף או ה-CLI של Google Cloud. Google Cloud אחרת, משתמשים בערך root-reconciler-ROOT_SYNC_NAME.

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

שימוש בחשבון שירות שמוגדר כברירת מחדל ב-Compute Engine

אם לא הפעלתם איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, תוכלו להשתמש בחשבון שירות של Compute Engine כדי לבצע אימות במקום להשתמש בחשבון שירות של Google. השיטה הזו נתמכת רק במאגרים ב-Secure Source Manager וב-Cloud Source Repositories.

כדי לתת ל-סנכרון תצורות הרשאת קריאה בלבד למאגר שלכם באמצעות חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine, צריך לתת לחשבון השירות שמוגדר כברירת מחדל את התפקיד roles/source.reader:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

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

‫PROJECT_ID: מזהה הפרויקט
‫PROJECT_NUMBER: עם מספר הפרויקט.

כשמתקינים את סנכרון תצורות, צריך להשתמש ב-Google Cloud Repository‏ (gcenode) כסוג האימות.

שימוש באפליקציית GitHub

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

פועלים לפי ההוראות ב-GitHub כדי להקצות אפליקציית GitHub ולהעניק לה הרשאה לקרוא מהמאגר.
מוסיפים את ההגדרה של אפליקציית GitHub לסוד חדש באשכול באמצעות מזהה הלקוח או מזהה האפליקציה:
מזהה לקוח
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=github-app-client-id=CLIENT_ID \
  --from-literal=github-app-installation-id=INSTALLATION_ID \
  --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
  --from-literal=github-app-base-url=BASE_URL
```
- מחליפים את CLIENT_ID במזהה הלקוח של אפליקציית GitHub.
- מחליפים את INSTALLATION_ID במזהה ההתקנה של אפליקציית GitHub.
- מחליפים את /path/to/GITHUB_PRIVATE_KEY בשם הקובץ שמכיל את המפתח הפרטי.
- מחליפים את הערך BASE_URL בכתובת ה-URL הבסיסית של נקודת קצה ל-API של GitHub. הערך הזה נדרש רק אם המאגר לא מתארח בכתובת www.github.com. אחרת, אפשר להשמיט את הארגומנט, והערך שיוגדר כברירת מחדל יהיה https://api.github.com/.
מזהה האפליקציה
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=github-app-application-id=APPLICATION_ID \
    --from-literal=github-app-installation-id=INSTALLATION_ID \
    --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
    --from-literal=github-app-base-url=BASE_URL
```
- מחליפים את APPLICATION_ID במזהה האפליקציה של אפליקציית GitHub.
- מחליפים את INSTALLATION_ID במזהה ההתקנה של אפליקציית GitHub.
- מחליפים את /path/to/GITHUB_PRIVATE_KEY בשם הקובץ שמכיל את המפתח הפרטי.
- מחליפים את הערך BASE_URL בכתובת ה-URL הבסיסית של נקודת קצה ל-API של GitHub. הערך הזה נדרש רק אם המאגר לא מתארח בכתובת www.github.com. אחרת, אפשר להשמיט את הארגומנט, וערך ברירת המחדל שלו הוא https://api.github.com/.

כשמתקינים את סנכרון תצורות, משתמשים באפליקציית GitHub ‏ (githubapp) כסוג האימות.

פתרון בעיות

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

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

בחירה של שיטת אימות

אימות באמצעות חבילות של צי רכבים

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

שימוש בזוג מפתחות SSH

שימוש בקובץ cookie

שימוש בטוקן

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

Secure Source Manager

Cloud Source Repositories

שימוש בחשבון שירות שמוגדר כברירת מחדל ב-Compute Engine

שימוש באפליקציית GitHub

מזהה לקוח

מזהה האפליקציה

פתרון בעיות

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

הענקת גישה ל-Config Sync למאגר Git