ניהול אמצעי בקרה של מדיניות

במדריך הזה מוסבר איך להטמיע אמצעי בקרה של מדיניות במשאבים של שירות רשות האישורים (CAS).

מטרות

במדריך הזה מוסבר איך להגדיר מאגר משותף של רשויות אישורים (CA) להנפקת אישורי DNS באמצעות אמצעי הבקרה הבאים של המדיניות:

  • המשתמש prod-dns-requester יכול לבקש אישורים של שרת TLS של ישות קצה עבור הדומיין *.prod.example.com.
  • המשתמש test-dns-requester יכול לבקש אישורים של שרת TLS של ישות קצה לדומיין *.test.example.com.
  • המשתמש blank-check-requester יכול לבקש כל סוג של אישור ממאגר רשויות האישורים.

במדריך הזה נעשה שימוש במדיניות הנפקת אישורים של מאגר CA, בתבניות אישורים ובקשרי IAM מותנים כדי להשיג את התרחיש הזה.

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

יצירת מאגר של רשויות שמנפיקות אישורים

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

  1. כדי ליצור מאגר של רשויות אישורים שמשתמש בקובץ issuance-policy.yaml, משתמשים בפקודה הבאה gcloud:

    gcloud

    gcloud privateca pools create POOL_NAME --location=LOCATION --tier=ENTERPRISE

    כאשר:

    • ‫LOCATION הוא המיקום שבו רוצים ליצור את מאגר רשויות האישורים. רשימה מלאה של המיקומים זמינה במאמר בנושא מיקומים.
    • הדגל --tier משמש לציון הרמה של מאגר רשויות האישורים. מידע נוסף על רמות זמין במאמר בחירת רמות הפעולה.

  2. כדי ליצור רשות אישורים עם משאבים שמנוהלים על ידי Google במאגר רשויות האישורים שנוצר לאחרונה, משתמשים בפקודה gcloud הבאה:

    gcloud

    gcloud privateca roots create CA_NAME \
    --pool=POOL_NAME \
    --location=LOCATION \
    --subject="CN=Example DNS Root, O=Example LLC, C=US" \
    --validity="10Y" \
    --max-chain-length=1 \
    --auto-enable

    כאשר:

    • ‫POOL_NAME הוא המזהה הייחודי של מאגר רשויות האישורים.
    • ‫LOCATION הוא המיקום שבו רוצים ליצור את מאגר רשויות האישורים. רשימה מלאה של המיקומים זמינה במאמר בנושא מיקומים.
    • הדגל --subject משמש להעברת השם של נושא האישור.
    • הדגל --validity קובע את תקופת התוקף של רשות האישורים. תקופת התוקף שמוגדרת כברירת מחדל היא 10 שנים.
    • הדגל --max-chain-length קובע את העומק המקסימלי של רשויות אישורים משניות שמותרות תחת רשות אישורים.
    • הדגל --auto-enable יוצר את ה-CA במצב ENABLED ולא במצב STAGED. מידע נוסף על מצבי CA זמין במאמר מצבי CA.

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

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

גם בתבניות ה-DNS של הבדיקה וגם בתבניות ה-DNS של ההפקה, צריך להשתמש באותם ערכים מוגדרים מראש של אישורי TLS של השרת. יוצרים קובץ YAML‏ leaf_server_tls_predefined_values.yaml ומעתיקים אליו את הגדרת ה-TLS של השרת של ישות הקצה הבאה.

    keyUsage:
      baseKeyUsage:
        digitalSignature: true
        keyEncipherment: true
      extendedKeyUsage:
        serverAuth: true
    caOptions:
      isCa: false

הגדרת אמצעי בקרה של מדיניות לאישורי DNS לבדיקה

בקטע הזה מוסבר איך מגדירים אמצעי בקרה של מדיניות כדי לאפשר למשתמש test-dns-requester לבקש אישורי TLS של שרת ישות קצה עבור DNS בדומיין *.test.example.com.

יצירת תבנית אישור DNS לאישורי בדיקה

בקטע הזה מוסבר איך ליצור תבנית אישור שמכילה את ההגדרה של TLS של שרת ישות קצה. תבנית האישור הזו מגבילה את השימוש באישורים רק ל-SAN של DNS בדומיין *.test.example.com. ההגבלות האלה מיושמות באמצעות ביטוי של Common Expression Language ‏ (CEL). תבנית האישור גם מסירה כל נושא שצוין בבקשת האישור.

  1. משתמשים בפקודה gcloud הבאה כדי ליצור את תבנית האישור שמכילה את התוספים של שרת TLS של ישות הקצה, מסירה את כל subject שצוינו בבקשת האישור ומגבילה את שמות ה-SAN המותרים.

    gcloud

    gcloud privateca templates create test-server-tls-template \
--predefined-values-file  ./leaf_server_tls_predefined_values.yaml \
--no-copy-subject \
--copy-sans \
--identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.test.example.com'))"

    כאשר:

    • הדגל --predefined-values-file משמש להעברת קובץ YAML שמתאר ערכי X.509 מוגדרים מראש שהוגדרו על ידי תבנית האישור.
    • הדגל --no-copy-subject משמיט את כל הנושאים שצוינו על ידי המתקשר מבקשת האישור.
    • הדגל --copy sans מוודא שהתוסף SAN מבקשת האישור מועתק לאישור החתום.
    • הדגל --identity-cel-expression משמש להעברת ביטוי CEL שמוערך מול הזהות באישור לפני שהוא מונפק. מידע נוסף על שימוש בביטויי CEL להטמעה של אמצעי בקרה שונים של מדיניות זמין במאמר שימוש ב-CEL.

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

יצירת קישורי IAM לאישורי בדיקה של DNS

כדי לאפשר למשתמש test-dns-requester@ במאגר אישורי ה-CA של DNS לבקש אישורי TLS של שרת בדיקה, יוצרים קשירת IAM מותנית במאגר אישורי ה-CA. הקצאת התפקיד  למשתמש  רק אם בקשת האישור מכילה הפניה לתבנית .privateca.certificateRequestertest-dns-requester@test-server-tls-template מידע נוסף על ההרשאות והתפקידים ב-IAM שחלים על CA Service זמין במאמר בקרת גישה באמצעות IAM.

  1. יוצרים קובץ YAML של מדיניות test_dns_condition.yaml ומעתיקים את הגדרת ה-TLS הבאה לקובץ.

      title: test DNS binding
  description: allows user to only create DNS test certificates
  expression: api.getAttribute("privateca.googleapis.com/template", "") == "PROJECT_ID/-/test-server-tls-template"

    בתחביר של התבנית נעשה שימוש ב-PROJECT_ID/-/TEMPLATE_ID במקום בשם המשאב המלא הרגיל projects/PROJECT_ID/locations/LOCATION/certificateTemplates/TEMPLATE_ID, כי תבניות האישורים צריכות להיות באותו מיקום כמו מאגר רשויות האישורים. המקף (-) פועל כתו כללי לחיפוש מיקום, וכך תנאי CEL נשארים תמציתיים, קריאים ולא תלויים במיקום.

    שם התבנית שצוין בתנאי IAM חייב להיות זהה לשם התבנית בבקשת האישור. לכן, אם מציינים מזהה פרויקט במאפיין privateca.googleapis.com/template של ביטוי CEL, צריך לציין מזהה פרויקט גם כשמבקשים את האישור. אם מציינים מספר פרויקט בביטוי CEL, צריך לציין מספר פרויקט גם בבקשת האישור.

  2. משתמשים בפקודה gcloud הבאה כדי להוסיף אמצעי בקרה למדיניות שמאפשרים ל-test-dns-requester@ לבקש רק אישורי TLS לבדיקות בסביבת הייצור ממאגר רשויות האישורים.

    gcloud

    gcloud privateca pools add-iam-policy-binding POOL_NAME \
    --location=LOCATION \
    --role='roles/privateca.certificateRequester' \
    --member='user:test-dns-requester@' \
    --condition-from-file=./test_dns_condition.yaml

    כאשר:

    • הדגל --role משמש להעברת שם התפקיד שיוקצה לחבר. מידע נוסף על תפקידים והרשאות ב-IAM עבור CA Service זמין במאמר בקרת גישה באמצעות IAM.
    • הדגל --member משמש להעברת החבר כדי להוסיף את הקישור.
    • הדגל condition-from-file משמש להעברת השם של הקובץ עם תנאי CEL.

  3. משתמשים בgcloud הבא כדי להוסיף אמצעי בקרה של מדיניות שמאפשרים ל-test-dns-requester@ להשתמש בתבנית האישורים test-server-tls-template.

    gcloud

    gcloud privateca templates add-iam-policy-binding test-server-tls-template \
    --role='roles/privateca.templateUser' \
    --member='user:test-dns-requester@'

    כאשר:

    • הדגל --role משמש להעברת שם התפקיד שיוקצה לחבר. מידע נוסף על תפקידים והרשאות ב-IAM עבור CA Service זמין במאמר בקרת גישה באמצעות IAM.
    • הדגל --member משמש להעברת החבר כדי להוסיף את הקישור.

    מידע נוסף על הגדרת מדיניות IAM זמין במאמר הגדרת מדיניות IAM.

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

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

הגדרת אמצעי בקרה של מדיניות לאישורי DNS של סביבת ייצור

בקטע הזה מוסבר איך מגדירים אמצעי בקרה של מדיניות כדי לאפשר למשתמש prod-dns-requester לבקש אישורי TLS של ישות קצה עבור הדומיין .prod.example.com של DNS.

יצירת תבנית אישור לאישורי DNS של סביבת ייצור

כדי ליצור תבנית אישור שמכילה הגדרה של TLS של שרת ישות קצה, פועלים לפי ההוראות הבאות. תבנית האישור הזו מגבילה את השימוש באישורים רק ל-SAN של DNS בדומיין *.prod.example.com. המגבלות האלה מיושמות באמצעות ביטוי של Common Expression Language ‏ (CEL). תבנית האישור גם מבטלת כל נושא שצוין בבקשת האישור.

יוצרים תבנית אישור prod-server-tls-template באמצעות הפקודה gcloud הבאה.

gcloud

gcloud privateca templates create prod-server-tls-template \
  --predefined-values-file ./leaf_server_tls_predefined_values.yaml \
  --no-copy-subject \
  --copy-sans \
  --identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.prod.example.com'))"

כאשר:

  • הדגל --predefined-values-file משמש להעברת קובץ YAML שמתאר ערכים מוגדרים מראש של X.509 שהוגדרו בתבנית האישור.
  • הדגל --no-copy-subject משמיט את כל הנושאים שצוינו על ידי המתקשר מבקשת האישור.
  • הדגל --copy sans מוודא שהתוסף SAN מבקשת האישור מועתק לאישור החתום.
  • הדגל --identity-cel-expression משמש להעברת ביטוי CEL שמוערך מול הזהות באישור לפני שהוא מונפק. מידע נוסף על ביטויי CEL זמין במאמר שימוש בביטויי CEL.

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

מידע נוסף על הפקודה gcloud privateca templates create זמין במאמר gcloud privateca templates create.

יצירת קשירת IAM של DNS בסביבת ייצור

כדי לאפשר למשתמש prod-dns-requester@ במאגר אישורי ה-DNS לבקש אישורי TLS של שרת ייצור, צריך ליצור קשירת IAM מותנית במאגר אישורי ה-CA. נותנים למשתמש prod-dns-requester@ את התפקיד privateca.certificateRequester רק אם בקשת האישור מכילה הפניה לתבנית prod-server-tls-template. מידע נוסף על תפקידים והרשאות ב-IAM זמין במאמר בקרת גישה באמצעות IAM.

  1. יוצרים קובץ YAML של מדיניות prod_dns_condition.yaml ומעתיקים את הגדרת ה-TLS הבאה לקובץ.

    title: Production DNS binding
description: allows user to only create DNS production certificates
expression: api.getAttribute("privateca.googleapis.com/template", "") == "PROJECT_ID/-/prod-server-tls-template"

  2. משתמשים בפקודה gcloud הבאה כדי להוסיף אמצעי בקרה למדיניות שמאפשרים ל-prod-dns-requester@ לבקש רק אישורי TLS של שרת ייצור ממאגר רשויות האישורים.

    gcloud

    gcloud privateca pools add-iam-policy-binding POOL_NAME \
    --location=LOCATION \
    --role='roles/privateca.certificateRequester' \
    --member='user:prod-dns-requester@' \
    --condition-from-file=./prod_dns_condition.yaml

    כאשר:

    • הדגל --role משמש להעברת שם התפקיד שיוקצה לחבר. מידע נוסף על תפקידים והרשאות ב-IAM עבור CA Service זמין במאמר בקרת גישה באמצעות IAM.
    • הדגל --member משמש להעברת החבר כדי להוסיף את הקישור.
    • הדגל condition-from-file משמש להעברת השם של הקובץ עם תנאי CEL.

    מידע נוסף על הפקודה gcloud privateca pools add-iam-policy-binding זמין במאמר gcloud privateca pools add-iam-policy-binding.

  3. כדי להוסיף אמצעי בקרה של מדיניות שמאפשרים ל-prod-dns-requester@ להשתמש בתבנית האישורים prod-server-tls-template, משתמשים בפקודה gcloud הבאה:

    gcloud

    gcloud privateca templates add-iam-policy-binding prod-server-tls-template \
    --role='roles/privateca.templateUser' \
    --member='user:prod-dns-requester@'

    כאשר:

    • הדגל --role משמש להעברת שם התפקיד שיוקצה לחבר. מידע נוסף על תפקידים והרשאות ב-IAM עבור CA Service זמין במאמר בקרת גישה באמצעות IAM.
    • הדגל --member משמש להעברת החבר כדי להוסיף את הקישור.

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

כדי לאפשר למשתמש blank-check-requester@ לבקש כל אישור ללא הגבלות, יוצרים קישור IAM ללא תנאים ומקצים למשתמש את התפקיד privateca.certificateRequester.

gcloud

gcloud privateca pools add-iam-policy-binding POOL_NAME \
    --location=LOCATION \
    --role='roles/privateca.certificateRequester' \
    --member='user:blank-check-requester@example.com'

כאשר:

  • הערך של הדגל --role קובע את התפקיד שמוקצה למשתמש. מידע נוסף על תפקידים והרשאות ב-IAM עבור CA Service זמין במאמר בקרת גישה באמצעות IAM.
  • הערך של הדגל --member קובע את המשתמש שהתפקיד מוקצה לו.

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

  • ‫POOL_NAME: המזהה הייחודי של מאגר הרשות שמנפיקה את האישורים (CA)
  • ‫LOCATION: המיקום של מאגר הרשות שמנפיקה את האישורים. כאן מפורטת רשימת המיקומים המלאה.

בדיקת אמצעי הבקרה של המדיניות

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

אחזור כל קשרי המדיניות

מאחזרים את כל מדיניות ה-IAM שמוטמעת במאגר הרשויות להנפקת אישורים. כדי לאחזר את כל מדיניות ה-IAM של מאגר רשויות האישורים, משתמשים בפקודה gcloud privateca pools get-iam-policy:

gcloud

gcloud privateca pools get-iam-policy POOL_NAME --location=LOCATION

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

  • ‫POOL_NAME: המזהה הייחודי של מאגר הרשות שמנפיקה את האישורים (CA)
  • ‫LOCATION: המיקום של מאגר אישורי ה-CA. כאן מפורטת רשימת המיקומים המלאה.

מידע נוסף על הפקודה gcloud privateca pools get-iam-policy זמין במאמר gcloud privateca pools get-iam-policy.

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

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

יצירת אישורי DNS לבדיקה

כדי לאפשר למשתמש test-dns-requester@ לבקש אישורי DNS לבדיקה ממאגר רשויות האישורים, משתמשים בפקודה הבאה gcloud:

gcloud

gcloud privateca certificates create test-dns-1 \
    --project=PROJECT_ID \
    --issuer-location=LOCATION \
    --issuer-pool=POOL_NAME \
    --dns-san=foo.bar.test.example.com \
    --generate-key \
    --key-output-file=KEY_FILE_NAME \
    --cert-output-file=test_dns_cert.pem \
    --template=projects/PROJECT_ID/locations/LOCATION/certificateTemplates/test-server-tls-template

כאשר:

  • הדגל --dns-san משמש להגדרת אחד או יותר שמות SAN של DNS שמופרדים בפסיקים.
  • הדגל --generate-key מפעיל את יצירת המפתח הפרטי החדש RSA-2048 במחשב.
  • הסימון --key-output-file משמש להגדרת הנתיב שבו ייכתב המפתח הפרטי שנוצר (בפורמט PEM).
  • הדגל --cert-output-file משמש להגדרת הנתיב שבו ייכתב קובץ שרשרת האישורים בקידוד PEM (מסודר מישות הקצה ועד לרמה הבסיסית).
  • הדגל --template משמש להגדרת השם של תבנית האישור שרוצים להשתמש בה להנפקת האישור הזה. התבנית שצוינה צריכה להיות באותו המיקום שבו נמצא מאגר ה-CA המנפיק. מידע נוסף על תבניות אישורים זמין במאמר סקירה כללית על תבניות אישורים ומדיניות הנפקה.

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

  • ‫PROJECT_ID: המזהה הייחודי של הפרויקט
  • ‫LOCATION: המיקום של מאגר רשויות האישורים שממנו נשלחת הבקשה לאישור. רשימה מלאה של המיקומים זמינה במאמר מיקומים.
  • ‫POOL_NAME: המזהה הייחודי של מאגר הרשות שמנפיקה את האישורים (CA)

יצירת אישורים לסביבת ייצור

המשתמש prod-dns-requester יכול עכשיו לבקש אישורי DNS של סביבת ייצור ממאגר ה-CA. ההגדרה --dns-san=foo.bar.prod.example.com מוסיפה ל-SAN סוג DNS עם הערך שצוין לבקשת האישור.

gcloud

gcloud privateca certificates create prod-dns-1 \
    --project=PROJECT_ID \
    --issuer-location=LOCATION \
    --issuer-pool=POOL_NAME \
    --dns-san=foo.bar.prod.example.com \
    --generate-key \
    --key-output-file=KEY_FILE_NAME \
    --cert-output-file=prod_dns_cert.pem \
    --template=projects/PROJECT_ID/locations/LOCATION/certificateTemplates/prod-server-tls-template

כאשר:

  • הדגל --issuer-location משמש להגדרת המיקום של האישור. רשימה מלאה של המיקומים זמינה במאמר בנושא מיקומים.
  • הדגל --issuer-pool מגדיר את מאגר רשויות האישורים שממנו מתבקש האישור.
  • הדגל --dns-san משמש להגדרת אחד או יותר שמות SAN של DNS שמופרדים בפסיקים.
  • הדגל --generate-key מפעיל את יצירת המפתח הפרטי החדש RSA-2048 במחשב.
  • הסימון --key-output-file משמש להגדרת הנתיב שבו ייכתב המפתח הפרטי שנוצר (בפורמט PEM).
  • הדגל --cert-output-file משמש להגדרת הנתיב שבו ייכתב קובץ שרשרת האישורים בקידוד PEM (מסודר מישות הקצה ועד לרמה הבסיסית).
  • הדגל --template משמש להגדרת השם של תבנית האישור שבה יש להשתמש להנפקת האישור הזה. התבנית שצוינה צריכה להיות באותו מיקום כמו מאגר ה-CA המנפיק. מידע נוסף על תבניות אישורים זמין במאמר סקירה כללית של תבניות אישורים ומדיניות הנפקה.

יצירת אישורים לשימוש כללי

המשתמש blank-check-requester@ יכול לבקש כל אישור ממאגר ה-CA באמצעות הפקודה gcloud privateca certificates create.

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

הסרת המשאבים

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

הסרה של קישור IAM ספציפי

כדי להסיר את הקישורים המותנים של IAM למאגר CA עבור המשתמש blank-check-requester, משתמשים בפקודה gcloud הבאה:

gcloud

gcloud privateca pools remove-iam-policy-binding POOL_NAME \
    --location=LOCATION \
    --role='roles/privateca.certificateRequester' \
    --member='user:blank-check-requester@'

כאשר:

  • הערך של הדגל --role קובע את התפקיד שמוקצה למשתמש. מידע נוסף על תפקידים והרשאות ב-IAM עבור CA Service זמין במאמר בקרת גישה באמצעות IAM.
  • הערך של הדגל --member קובע את המשתמש שהתפקיד מוקצה לו.

כשמסירים ישות ספציפית ב-IAM, צריך לספק את כל המידע שקשור לישות ב-IAM בפקודה gcloud privateca pools remove-iam-policy-binding. יכול להיות שלתפקיד ולחבר יהיו כמה קישורי IAM עם תנאים שונים. חשוב לספק את כל הפרטים שקשורים לקישור IAM כדי למנוע מחיקה בטעות של קישור אחר.

מידע נוסף על הפקודה gcloud privateca pools remove-iam-policy-binding זמין במאמר gcloud privateca pools remove-iam-policy-binding.

הסרת כל הקישורים המותנים של IAM

כדי להסיר קשר IAM, אפשר להשתמש בפקודה gcloud privateca pools remove-iam-policy-binding. כשמסירים קשירה מותנית של IAM, צריך לספק את כל המידע על הקשירה. למשתמש ולתפקיד יכולים להיות יותר מקישור מותנה אחד. כדי להסיר את כל ההתניות, משתמשים בדגל --all בפקודה gcloud.

כדי להסיר את כל הקישורים של המשתמש prod-code-signing-requester, משתמשים בפקודה gcloud הבאה.

gcloud

gcloud privateca pools remove-iam-policy-binding POOL_NAME \
    --location=LOCATION \
    --role='roles/privateca.certificateRequester' \
    --member='user:prod-code-signing-requester@' \
    --all

כאשר:

  • הערך של הדגל --role קובע את התפקיד שמוקצה למשתמש. מידע נוסף על תפקידים והרשאות ב-IAM עבור CA Service זמין במאמר בקרת גישה באמצעות IAM.
  • הערך של הדגל --member קובע את המשתמש שהתפקיד מוקצה לו.