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

.

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

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

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

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

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

אשכולות GKE משתמשים במפתחות וברשויות אישורים ספציפיים כדי להנפיק פרטי כניסה באשכול, כמו אישורי X.509 או אסימונים של חשבון שירות. אתם יכולים ליצור מפתחות ב-Cloud Key Management Service ‏ (Cloud KMS) ו-CAs ב-Certificate Authority Service ‏(CA Service) ולהגדיר את האשכולות כך שישתמשו במשאבים האלה במקום במפתחות וב-CAs שמנוהלים על ידי 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, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים 

    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, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים 

    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).
  • אפשר להשתמש רק ב-CA משירות CA.

הכנת הסביבה

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

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

מומלץ להשתמש ב 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 משתמש בהם כדי לחתום על פרטי הכניסה ולאמת אותם באשכול. אתם יכולים לציין מאפיינים משלכם למפתחות האלה בהתאם לצרכים של הארגון. פרטים נוספים זמינים בדף יצירת מפתח ובמאמר projects.locations.keyRings.cryptoKeys בנושא הפניית API.

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

  • אם יש לכם אוסף מפתחות קיים בפרויקט המפתחות, אתם יכולים להשתמש בו כדי לאחסן את כל המפתחות שאתם יוצרים לשימוש עם האשכול.
  • כדי לצמצם את זמן האחזור, אוסף המפתחות צריך להיות באותו Google Cloud מיקום כמו האשכול.
  • במפתחות צריך לציין את asymmetric-signing כמטרת המפתח.
  • משתמשים באלגוריתמים הבאים בהתאם לסוג המפתח:
    • מפתחות חתימה של חשבון שירות: אלגוריתם חתימה חזק של 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:

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

    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. יוצרים את רשות האישורים (CA) הבסיסית של האשכול:

    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. יוצרים את רשות האישורים (CA) הבסיסית של עמיתי 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. יוצרים את רשות האישורים (CA) הבסיסית של 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 שיצרתם בשלב יצירת ה-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.

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

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

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

  3. מקצים את התפקיד Viewer (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. אם השתמשתם בשמות שונים למפתחות של רשות האישורים הבסיסית, צריך להריץ את הפקודות האלה באופן ידני לכל מפתח.

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

אחרי שיוצרים מפתחות, מאגרי רשויות אישורים, רשויות אישורי בסיס ונותנים תפקידי 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. מוצאים את הנתיבים לכל מאגרי הרשויות שמנפיקות אישורים שיצרתם:

    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. משביתים את רשויות האישורים (CA) העליונות:

    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. מחיקת רשויות האישורים העליונות:

    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. עם זאת, מחזיקי מפתחות לא כרוכים בעלויות נוספות.

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