הפעלת רשויות אישורים ומפתחות משלכם ב-GKE

.

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

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

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

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

רכיבי פרטי הכניסה של מישור הבקרה

באשכולות GKE נעשה שימוש ברשויות אישורים ובמפתחות ספציפיים כדי להנפיק פרטי כניסה באשכול, כמו אישורי X.509 או אסימוני ServiceAccount. אתם יכולים ליצור מפתחות ב-Cloud Key Management Service ‏ (Cloud KMS) ותעודות CA ב-Certificate Authority Service ‏(CA Service) ולהגדיר את האשכולות כך שישתמשו במשאבים האלה במקום בתעודות CA ובמפתחות שמנוהלים על ידי Google Cloud.

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

שימוש בתכונות אחרות של שליטה במישור הבקרה של GKE

השליטה במישור הבקרה של GKE מספקת את התכונות הבאות שקשורות למפתחות בניהול עצמי:

מטרות

  • יצירת מפתחות ב-Cloud KMS
  • יצירת רשויות אישורים בשירות CA
  • הענקת תפקידים של ניהול זהויות והרשאות גישה (IAM) לסוכן השירות של GKE
  • יצירת אשכול GKE שמשתמש ב-CA ובמפתחות שלכם
  • אימות השימוש באישורים ובמפתחות שלכם באשכול

עלויות

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

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

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

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

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

  1. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  2. התקינו את ה-CLI של Google Cloud.

  3. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  4. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה: 

    gcloud init

  5. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

  6. מפעילים את ממשקי ה-API של Kubernetes Engine,‏ Certificate Authority Service ו-Cloud Key Management Service, אם אחד מהם עדיין לא מופעל:

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים 

    gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com

  7. התקינו את ה-CLI של Google Cloud.

  8. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  9. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה: 

    gcloud init

  10. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

  11. מפעילים את ממשקי ה-API של Kubernetes Engine,‏ Certificate Authority Service ו-Cloud Key Management Service, אם אחד מהם עדיין לא מופעל:

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים 

    gcloud services enable container.googleapis.com privateca.googleapis.com cloudkms.googleapis.com
    12.
  12. מוודאים שהסביבה שלכם עומדת בדרישות לשימוש בתכונות של "שליטה במישור הבקרה של GKE". כדי להפעיל את התכונות האלה, צריך לפנות לצוות המכירות Google Cloud .
  13. כדי לעקוב בצורה מהימנה אחרי הנפקת פרטי כניסה והשימוש בהם, חשוב לוודא שיומני הביקורת הבאים של גישה לנתונים מופעלים:
    • Cloud Key Management Service (KMS) API: DATA_READ
    • ‫Certificate Authority Service: ADMIN_READ

    הסבר על הפעלת סוגי היומנים האלה מופיע במאמר הפעלת יומני ביקורת של גישה לנתונים.

תפקידים והרשאות נדרשים

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

להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

דרישות

עליכם לעמוד בדרישות הבאות:

  • באשכול צריך להריץ את גרסה ‎1.31.1-gke.1846000 של GKE או גרסה מתקדמת יותר.

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

    • asia-east1
    • asia-northeast1
    • asia-southeast1
    • europe-west1
    • europe-west4
    • us-central1
    • us-central2
    • us-east1
    • us-east4
    • us-east5
    • us-south1
    • us-west1
    • us-west3
    • us-west4

מגבלות

ההגבלות הבאות חלות:

  • אפשר להשתמש רק במפתחות מ-Cloud KMS. אי אפשר להשתמש בספק KMS אחר או בספק הצפנה אחר.
  • אין תמיכה במפתחות של Cloud External Key Manager ‏ (Cloud EKM).
  • אפשר להשתמש רק ברשויות אישורים משירות רשויות האישורים.

הכנת הסביבה

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

זיהוי פרויקטים

מומלץ להשתמש בפרויקטים נפרדים Google Cloud באופן הבא:

  • פרויקט מפתחות: מכיל את כל המפתחות ורשויות האישורים.
  • פרויקט האשכול: מכיל את אשכולות GKE.

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

יצירת אוסף מפתחות

יוצרים אוסף מפתחות בפרויקט המפתחות כדי להכיל את כל המפתחות של אשכול ספציפי. צריך ליצור את אוסף המפתחות באותו מיקום שבו נמצא אשכול GKE.

מריצים את הפקודה הבאה:

gcloud kms keyrings create KEY_RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

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

  • ‫KEY_RING_NAME: שם לאוסף המפתחות.
  • ‫KEY_PROJECT_ID: מזהה הפרויקט של פרויקט המפתח.
  • ‫LOCATION: Google Cloud האזור שבו רוצים ליצור את אוסף המפתחות. האזור הזה צריך להיות זהה לאזור שבו נמצא אשכול GKE.

יצירת מפתחות

לכל אחת מרשויות פרטי הכניסה, כמו מפתחות של חשבונות שירות ורשויות אישורים, יוצרים מפתח באמצעות Cloud KMS. בקטע הזה מוסבר איך ליצור את המפתחות ש-GKE משתמש בהם כדי לחתום על פרטי הכניסה באשכול ולאמת אותם. אתם יכולים לציין מאפיינים משלכם למפתחות האלה בהתאם לצרכים של הארגון. פרטים נוספים זמינים בדף יצירת מפתח ובמאמרי העזרה של ה-API projects.locations.keyRings.cryptoKeys.

כשיוצרים את המשאבים האלה ב-Cloud KMS, כדאי לקחת בחשבון את הנקודות הבאות:

  • אם יש לכם אוסף מפתחות קיים בפרויקט המפתחות, אתם יכולים להשתמש בו כדי לאחסן את כל המפתחות שאתם יוצרים לשימוש עם האשכול.
  • כדי לצמצם את זמן האחזור, אוסף המפתחות צריך להיות באותו Google Cloud מיקום של האשכול.
  • במפתחות צריך לציין את asymmetric-signing כמטרת המפתח.
  • משתמשים באלגוריתמים הבאים בהתאם לסוג המפתח:
    • מפתחות חתימה של ServiceAccount: אלגוריתם חתימה חזק של RSA PKCS1, כמו rsa-sign-pkcs1-4096-sha256 או rsa-sign-pkcs1-3072-sha256.
    • מפתחות של רשות אישורים: אלגוריתם חזק כמו ec-sign-p256-sha256.
  • מפתחות חומרה של Cloud HSM נתמכים, אבל רמת ההגנה software מספיקה לרוב תרחישי השימוש. למידע נוסף על מפתחות חומרה, ראו Cloud HSM.
  • אל תשנו את משך הזמן שמוגדר כברירת מחדל להשמדת מפתחות.
  • ‫GKE לא מונע מכם למחוק מפתחות Cloud KMS, כולל מפתחות של CA Service, שנמצאים בשימוש באשכול. לפני שמוחקים מפתחות או רשויות אישורים, צריך לוודא שלא נעשה בהם שימוש במשאבים.

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

  1. יוצרים את מפתח החתימה של חשבון השירות ב-Kubernetes, שמוגדר גם כמפתח האימות של חשבון השירות במהלך יצירת האשכול:

    gcloud kms keys create sa-signing-key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --purpose="asymmetric-signing" \
    --protection-level=hsm \
    --default-algorithm=rsa-sign-pkcs1-4096-sha256 \
    --project=KEY_PROJECT_ID

    מחליפים את KEY_PROJECT_ID במזהה הפרויקט של פרויקט המפתח הייעודי.

  2. יוצרים את מפתח ה-CA הבסיסי של האשכול:

    gcloud kms keys create cluster-ca-key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --purpose="asymmetric-signing" \
    --protection-level=hsm \
    --default-algorithm=ec-sign-p256-sha256 \
    --project=KEY_PROJECT_ID

  3. יוצרים את מפתח ה-CA הבסיסי של עמיתי etcd:

    gcloud kms keys create etcd-peer-ca-key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --purpose="asymmetric-signing" \
    --protection-level=hsm \
    --default-algorithm=ec-sign-p256-sha256 \
    --project=KEY_PROJECT_ID

  4. יוצרים את מפתח ה-CA הבסיסי של etcd API:

    gcloud kms keys create etcd-api-ca-key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --purpose="asymmetric-signing" \
    --protection-level=hsm \
    --default-algorithm=ec-sign-p256-sha256 \
    --project=KEY_PROJECT_ID

  5. יוצרים את מפתח ה-CA של שורש הצבירה:

    gcloud kms keys create aggregation-ca-key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --purpose="asymmetric-signing" \
    --protection-level=hsm \
    --default-algorithm=ec-sign-p256-sha256 \
    --project=KEY_PROJECT_ID

יצירת רשויות האישורים

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

  1. יוצרים את מאגר רשויות ה-CA של האשכול:

    gcloud privateca pools create cluster-ca-pool \
    --location=LOCATION \
    --tier=enterprise \
    --project=KEY_PROJECT_ID \
    --no-publish-crl --no-publish-ca-cert

    הדגל --no-publish-crl והדגל --no-publish-ca-cert הם אופציונליים. אם לא מציינים את הדגלים האלה, האישורים מתפרסמים בקטגוריה של Cloud Storage. פרטים נוספים מופיעים במאמר בנושא הפעלה של פרסום אישורי CA ו-CRL עבור רשויות אישורים במאגר אישורים.

  2. יוצרים את רשות האישורים הבסיסית של האשכול:

    gcloud privateca roots create cluster-root-ca \
    --pool=cluster-ca-pool \
    --location=LOCATION \
    --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/cluster-ca-key/cryptoKeyVersions/1 \
    --subject="CN=cluster-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID \
    --auto-enable

    מחליפים את ORGANIZATION בשם הארגון.

  3. יוצרים את מאגר רשות האישורים (CA) של עמיתי etcd:

    gcloud privateca pools create etcd-peer-ca-pool \
    --location=LOCATION \
    --tier=enterprise \
    --project=KEY_PROJECT_ID \
    --no-publish-crl --no-publish-ca-cert

  4. יוצרים את רשות האישורים הבסיסית של עמיתי etcd:

    gcloud privateca roots create etcd-peer-root-ca \
    --pool=etcd-peer-ca-pool \
    --location=LOCATION \
    --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-peer-ca-key/cryptoKeyVersions/1 \
    --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID \
    --auto-enable

  5. יוצרים את מאגר רשויות האישורים של etcd API:

    gcloud privateca pools create etcd-api-ca-pool \
    --location=LOCATION \
    --tier=enterprise \
    --project=KEY_PROJECT_ID \
    --no-publish-crl --no-publish-ca-cert

  6. יוצרים את רשות האישורים הבסיסית של etcd API:

    gcloud privateca roots create etcd-api-root-ca \
    --pool=etcd-api-ca-pool \
    --location=LOCATION \
    --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-api-ca-key/cryptoKeyVersions/1 \
    --subject="CN=etcd-api-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID \
    --auto-enable

  7. יוצרים את מאגר האישורים המצטבר:

    gcloud privateca pools create aggregation-ca-pool \
    --location=LOCATION \
    --tier=enterprise \
    --project=KEY_PROJECT_ID \
    --no-publish-crl --no-publish-ca-cert

  8. יוצרים את רשות האישורים (CA) של שורש הצבירה:

    gcloud privateca roots create aggregation-root-ca \
    --pool=aggregation-ca-pool \
    --location=LOCATION \
    --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/aggregation-ca-key/cryptoKeyVersions/1 \
    --subject="CN=aggregation-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID \
    --auto-enable

הענקת תפקידי IAM לסוכן השירות של GKE

סוכן השירות של GKE צריך גישה למשאבים שיצרתם ב-Cloud KMS וב-CA Service. סוכן השירות משתמש במשאבים האלה כדי לחתום על פרטי הכניסה, לאמת אותם ולהנפיק אותם באשכול. אפשר להשתמש בתפקידי ה-IAM הבאים שהוגדרו מראש:

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

  1. כדי למצוא את מספר הפרויקט של פרויקט האשכול:

    gcloud projects describe CLUSTER_PROJECT_ID \
    --format='value(projectNumber)'

    מחליפים את הערך CLUSTER_PROJECT_ID במזהה הפרויקט של האשכול.

  2. מקצים את התפקיד 'משתמש במפתח קריפטוגרפי של Kubernetes Engine KMS' למפתח החתימה של חשבון השירות שיצרתם בשלב יצירת מפתחות:

    gcloud kms keys add-iam-policy-binding sa-signing-key \
  --location=LOCATION \
  --keyring=KEY_RING_NAME \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
  --role=roles/container.cloudKmsKeyUser \
  --project=KEY_PROJECT_ID

    מחליפים את הערך CLUSTER_PROJECT_NUMBER במספר הפרויקט של אשכול הפרויקט.

  3. מקצים את התפקיד 'מנהל אישורים של שירות CA' במאגרי ה-CA שיצרתם בשלב יצירת רשויות אישורים:

    gcloud privateca pools add-iam-policy-binding cluster-ca-pool \
    --location=LOCATION \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

gcloud privateca pools add-iam-policy-binding etcd-peer-ca-pool \
    --location=LOCATION \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

gcloud privateca pools add-iam-policy-binding etcd-api-ca-pool \
    --location=LOCATION \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

gcloud privateca pools add-iam-policy-binding aggregation-ca-pool \
    --location=LOCATION \
    --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role=roles/privateca.certificateManager \
    --project=KEY_PROJECT_ID

הענקת תפקידים נוספים כשלא משתמשים ב-CLI של gcloud

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

כשמשתמשים ב-CLI של gcloud כדי להגדיר את רשויות האישורים והמפתחות, כמו שמתואר במסמך הזה, ה-CLI של gcloud יוצר ומגדיר באופן אוטומטי סוכן שירות בשביל CA Service, ומעניק לו תפקידי IAM. עם זאת, אם אתם משתמשים בלקוח כמו Terraform או במסוף Google Cloud כדי להגדיר את סביבת Google Cloud, אתם צריכים לבצע את שלבי ההגדרה הבאים באופן ידני בפרויקט המפתח:

  1. מפעילים את היצירה של סוכן השירות של CA Service.

    gcloud beta services identity create --service=privateca.googleapis.com \
    --project=KEY_PROJECT_ID

  2. מאתרים את מספר הפרויקט של פרויקט המפתח:

    gcloud projects describe KEY_PROJECT_ID \
    --format='value(projectNumber)'

  3. צריך להעניק את התפקיד צפייה (roles/viewer) ואת התפקיד Cloud KMS CryptoKey Signer/Verifier (roles/cloudkms.signerVerifier) לכל מפתחות ה-CA הבסיסיים שיצרתם בקטע יצירת מפתחות:

    for key in cluster-ca-key etcd-peer-ca-key etcd-api-ca-key aggregation-ca-key
do
gcloud kms keys add-iam-policy-binding $key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --role=roles/viewer \
    --member="serviceAccount:service-KEY_PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com" \
    --project=KEY_PROJECT_ID

gcloud kms keys add-iam-policy-binding $key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --role=roles/cloudkms.signerVerifier \
    --member="serviceAccount:service-KEY_PROJECT_NUMBER@gcp-sa-privateca.iam.gserviceaccount.com" \
    --project=KEY_PROJECT_ID
done

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

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

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

אחרי שיוצרים מפתחות, מאגרי CA, רשויות CA בסיסיות ומקצים תפקידי IAM לסוכן השירות של GKE, יוצרים אשכול חדש שמשתמש במשאבים האלה.

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

  • הנתיב לגרסת המפתח ב-Cloud KMS של מפתח החתימה של חשבון השירות שיצרתם בקטע יצירת מפתחות. מציינים את הנתיב הזה בדגל service-account-signing-keys ובדגל service-account-verification-keys.
  • הנתיב לכל אחד ממאגרי ה-CA שיצרתם בקטע יצירת רשויות האישורים.

כדי להגדיר אשכול חדש לשימוש במפתחות וב-CA, מבצעים את השלבים הבאים:

  1. מוצאים את הנתיב לגרסה האחרונה של מפתח החתימה של חשבון השירות שמופעל:

    gcloud kms keys versions list \
    --key=sa-signing-key \
    --keyring=KEY_RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ --format="value(name)" | sed 1q

    מחליפים את הערך KEY_PROJECT_ID במזהה הפרויקט של פרויקט המפתח.

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

    projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1

  2. מאתרים את הנתיבים לכל אחד ממאגרי ה-CA שיצרתם:

    gcloud privateca pools list --format="get(name)" \
    --project=KEY_PROJECT_ID

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

    projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool

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

יצירת אשכול

בקטע הזה יוצרים אשכול עם אפשרויות שונות שמוגדרות בהתאם לתכונות של הרשאות הגישה למישור הבקרה של GKE שרוצים להגדיר. אפשר להגדיר את התכונות האלה באוסף רק במהלך יצירת האוסף. הפקודות הבאות יוצרות אשכולות במצב רגיל. כדי ליצור במקום זאת אשכולות במצב אוטומטי, משתמשים באותם דגלים עם הפקודה gcloud container clusters create-auto.

  • כדי להגדיר רק את רשויות האישורים והמפתחות שיצרתם במדריך הזה, מריצים את הפקודה הבאה:

    gcloud container clusters create example-cluster \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --cluster-version=VERSION \
    --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
    --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
    --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
    --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
    --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
    --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool

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

    • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של פרויקט האשכול.
    • ‫VERSION: גרסת GKE של האשכול. חייבת להיות גרסה ‎1.31.1-gke.1846000 ואילך.

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

    1. מבצעים את כל שלבי ההגדרה העיקריים שמפורטים במאמר הצפנת דיסקי האתחול של etcd ושל מישור הבקרה.
    2. מאתרים את הנתיבים לכל אחד מהמפתחות לפי ההוראות במאמר שימוש במפתחות הצפנה באשכול.

    3. יוצרים אשכול:

      gcloud container clusters create example-cluster \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --cluster-version=VERSION \
    --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
    --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
    --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
    --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
    --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
    --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
    --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
    --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY

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

      • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול.
      • ‫VERSION: גרסת ה-GKE של האשכול. הגרסה צריכה להיות 1.31.1-gke.1846000 ואילך.
      • ‫PATH_TO_DISK_KEY: הנתיב למפתח ההצפנה של הדיסק.
      • ‫PATH_TO_ETCD_BACKUP_KEY: הנתיב למפתח ההצפנה של הגיבוי הפנימי של etcd.

    אפשר גם להשתמש בדגלים האלה כשיוצרים אשכול חדש במצב רגיל.

איך מוודאים שהאשכול משתמש במפתחות וב-CA שציינתם

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

שימוש ברישום ביומן כדי לאמת מפתחות ורשויות אישורים

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

  1. נכנסים לדף Logs Explorer במסוף Google Cloud :

    כניסה לדף Logs Explorer

  2. מציינים את השאילתה הבאה:

    resource.type="gke_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="CLUSTER_LOCATION"
protoPayload.serviceName="container.googleapis.com"
protoPayload.methodName=~"google.container.v(1|1alpha1|1beta1).ClusterManager.CreateCluster"
protoPayload.request.cluster.userManagedKeysConfig:*

    protoPayload.request.cluster.userManagedKeysConfig:* מסנן את התוצאות של יומני יצירת אשכולות שכוללים מפתחות ורשויות אישורים שאתם מנהלים.

  3. לוחצים על Run query.

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

# lines omitted for clarity
userManagedKeysConfig: {
  aggregationCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool"
  clusterCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool"
  etcdApiCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool"
  etcdPeerCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool"
  serviceAccountSigningKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
  serviceAccountVerificationKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
}

אימות מפתחות ורשויות אישורים באמצעות ה-CLI של gcloud

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

gcloud container clusters describe example-cluster \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

הפלט אמור לכלול את השדה userManagedKeysConfig, כמו בדוגמה הבאה:

# lines omitted for clarity
userManagedKeysConfig:
  sa-signing-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  sa-verification-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  cluster-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
  etcd-peer-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
  etcd-api-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
  aggregation-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool

הסרת המשאבים

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

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

    כדי למחוק Google Cloud פרויקט:

    gcloud projects delete PROJECT_ID

מחיקת משאבים בודדים

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

    gcloud container clusters delete example-cluster \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

  2. משביתים את רשויות האישורים ברמה הבסיסית (root):

    gcloud privateca roots disable cluster-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
    --project=KEY_PROJECT_ID

gcloud privateca roots disable etcd-peer-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
    --project=KEY_PROJECT_ID

gcloud privateca roots disable etcd-api-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
    --project=KEY_PROJECT_ID

gcloud privateca roots disable aggregation-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
    --project=KEY_PROJECT_ID

  3. מוחקים את רשויות האישורים ברמה הבסיסית (root):

    gcloud privateca roots delete cluster-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
    --project=KEY_PROJECT_ID

gcloud privateca roots delete etcd-peer-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
    --project=KEY_PROJECT_ID

gcloud privateca roots delete etcd-api-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
    --project=KEY_PROJECT_ID

gcloud privateca roots delete aggregation-root-ca \
    --location=LOCATION \
    --pool=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
    --project=KEY_PROJECT_ID

  4. מוחקים את מאגרי ה-CA:

    gcloud privateca pools delete cluster-ca-pool --location=LOCATION \
    --project=KEY_PROJECT_ID

gcloud privateca pools delete etcd-peer-ca-pool --location=LOCATION \
    --project=KEY_PROJECT_ID

gcloud privateca pools delete etcd-api-ca-pool --location=LOCATION \
    --project=KEY_PROJECT_ID

gcloud privateca pools delete aggregation-ca-pool --location=LOCATION \
    --project=KEY_PROJECT_ID

  5. מחיקת המפתחות:

    gcloud kms keys versions destroy 1 \
    --location=LOCATION \
    --keyring=KEY_RING_NAME \
    --key=sa-signing-key \
    --project=KEY_PROJECT_ID

gcloud kms keys versions destroy 1 \
    --location=LOCATION \
    --keyring=KEY_RING_NAME \
    --key=cluster-ca-key \
    --project=KEY_PROJECT_ID

gcloud kms keys versions destroy 1 \
    --location=LOCATION \
    --keyring=KEY_RING_NAME \
    --key=etcd-peer-ca-key \
    --project=KEY_PROJECT_ID

gcloud kms keys versions destroy 1 \
    --location=LOCATION \
    --keyring=KEY_RING_NAME \
    --key=etcd-api-ca-key \
    --project=KEY_PROJECT_ID

gcloud kms keys versions destroy 1 \
    --location=LOCATION \
    --keyring=KEY_RING_NAME \
    --key=aggregation-ca-key \
    --project=KEY_PROJECT_ID

אי אפשר למחוק אוספי מפתחות מ-Cloud KMS. עם זאת, אוספי מפתחות לא כרוכים בעלויות נוספות.

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