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

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

אחרי שיוצרים את שורשי האמון, במסמך הזה מפורט התהליך להעלאה שלהם למאגר האמון של משאב Certificate Manager‏ TrustConfig. לאחר מכן מקשרים את הגדרת האמון למשאב אימות הלקוח (ServerTLSPolicy), ומצרפים את משאב אימות הלקוח למשאב פרוקסי ה-HTTPS של מאזן העומסים.

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

  • כדאי לעיין בסקירה הכללית על TLS בו-זמני.
  • מומלץ לעיין במדריך בנושא ניהול הגדרות אמון.

  • מתקינים את Google Cloud CLI. סקירה כללית מלאה של הכלי זמינה במאמר סקירה כללית על ה-CLI של gcloud. אפשר למצוא פקודות שקשורות לאיזון עומסים במדריך העזר ל-API ול-CLI של gcloud.

    אם לא הפעלתם את ה-CLI של gcloud בעבר, אתם צריכים קודם להריץ את הפקודה gcloud init כדי לבצע אימות.

  • מפעילים את ממשקי ה-API הבאים: Compute Engine API,‏ Certificate Manager API,‏ Network Security ו-Network Services API. מידע נוסף מופיע במאמר הפעלה של ממשקי API.

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

    • קצוות עורפיים של קבוצת מכונות וירטואליות
    • קטגוריות של Cloud Storage (נתמך רק אם יש לפחות שירות לקצה העורפי אחד שמצורף גם למאזן העומסים, בנוסף לקטגוריית קצה עורפי)
    • Cloud Run,‏ App Engine או פונקציות Cloud Run
    • קישוריות היברידית
    • קצוות עורפיים של Private Service Connect

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

    • קצוות עורפיים של קבוצת מכונות וירטואליות
    • Cloud Run
    • קישוריות היברידית
    • קצוות עורפיים של Private Service Connect

  • מגדירים את הפרויקט.

    gcloud 

    gcloud config set project PROJECT_ID

הרשאות

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

  • כדי ליצור משאבי איזון עומסים כמו TargetHTTPSProxy: Compute Load Balancer Admin (roles/compute.loadBalancerAdmin)
  • כדי להשתמש במשאבים של Certificate Manager: בעלים של Certificate Manager (roles/certificatemanager.owner)
  • כדי ליצור רכיבי אבטחה ורשת: אדמין של רשת מחשוב (roles/compute.networkAdmin) ואדמין לענייני אבטחת מחשוב (roles/compute.securityAdmin)
  • כדי ליצור פרויקט (אופציונלי): יצירת פרויקטים (roles/resourcemanager.projectCreator)

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

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

יצירת אישורי הבסיס ואישורי הביניים

בקטע הזה נעשה שימוש בספריית OpenSSL כדי ליצור את אישור הבסיס (נקודת אמון) ואת אישור הביניים.

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

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

  1. יוצרים קובץ תצורה של OpenSSL.

    בדוגמה הבאה, קובץ התצורה (example.cnf) מכיל את הקטע [ca_exts], שמציין תוספים מסוג X.509 שמסמנים את האישור כמתאים לרשות שמנפיקה את האישורים (CA). מידע נוסף על הדרישות לגבי אישורי בסיס ואישורי ביניים זמין במאמר דרישות האישורים.

    cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name

[empty_distinguished_name]
# Kept empty to allow setting via -subj command-line argument.

[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth

EOF

  2. יוצרים אישור בסיס X.509 בחתימה עצמית (root.cert). אישור הבסיס הוא בחתימה עצמית עם המפתח הפרטי שלו (root.key).

    openssl req -x509 \
    -new -sha256 -newkey rsa:2048 -nodes \
    -days 3650 -subj '/CN=root' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout root.key -out root.cert

  3. יוצרים את בקשת החתימה על האישור (int.req) לאישור הביניים.

    openssl req -new \
    -sha256 -newkey rsa:2048 -nodes \
    -subj '/CN=int' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout int.key -out int.req

  4. חותמים על ה-CSR כדי ליצור את אישור הביניים X.509 ‏ (int.cert). ה-CSR נחתם באמצעות אישור הבסיס.

    openssl x509 -req \
    -CAkey root.key -CA root.cert \
    -set_serial 1 \
    -days 3650 \
    -extfile example.cnf \
    -extensions ca_exts \
    -in int.req -out int.cert

יצירת אישור בחתימה עצמית שאפשר להוסיף לרשימת ההיתרים

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

משתמשים בפקודת OpenSSL הבאה כדי ליצור אישור X.509 עם חתימה עצמית.

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=localhost' \
       -keyout allowlisted.key -out allowlisted.cert

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

עיצוב האישורים

כדי לכלול אישורים חדשים או קיימים בקובץ TrustStore, צריך לעצב את האישורים לשורה אחת ולאחסן אותם במשתני סביבה, כדי שאפשר יהיה להפנות אליהם מקובץ ה-YAML של הגדרת האמון.

export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

כדי לכלול אישורים חדשים או קיימים שנוספו לרשימת ההיתרים בהגדרת אמון, צריך לעצב את האישורים לשורה אחת ולאחסן אותם במשתני סביבה, כדי שאפשר יהיה לקרוא אותם בקובץ ה-YAML. עבור אישורים שנמצאים ברשימת ההיתרים, משתמשים בפקודה הבאה כדי לעצב את האישורים בשורה אחת ולאחסן אותם במשתנה הסביבה ALLOWLISTED_CERT.

export ALLOWLISTED_CERT=$(cat allowlisted.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

יצירה של משאב להגדרת אמון

הגדרת אמון היא משאב שמייצג את התצורה של תשתית המפתח הציבורי (PKI) שלכם ב-Certificate Manager.

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

המסוף

  1. נכנסים לדף Certificate Manager במסוף Google Cloud .

    מעבר אל Certificate Manager

  2. בכרטיסייה Trust Configs, לוחצים על Add Trust Config.

  3. מזינים שם להגדרה.

  4. בקטע מיקום, בוחרים באפשרות גלובלי או אזורי.

    המיקום מציין איפה מאוחסן משאב הגדרות האמון. למאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), למאזני עומסים קלאסיים של אפליקציות (ALB) ולמאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים, צריך ליצור משאב גלובלי של הגדרת אמון. עבור מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ומאזני עומסים פנימיים אזוריים של אפליקציות (ALB), צריך ליצור משאב של הגדרת אמון אזורית.

    אם בחרתם באפשרות אזורי, בוחרים את האזור.

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

  6. לוחצים על הוספה.

  7. בקטע מאגר אישורים, לוחצים על Add intermediate CA ומעלים את קובץ האישור בקידוד PEM, או מעתיקים את תוכן האישור.

    בשלב הזה אפשר להוסיף עוד רמת אמון בין אישור הבסיס לבין אישור השרת.

  8. לוחצים על הוספה כדי להוסיף את רשות האישורים המתווכת.

  9. אופציונלי: בקטע Allowlisted certificates (אישורים ברשימת ההיתרים), לוחצים על Add certificate (הוספת אישור) ומעלים את קובץ האישור בקידוד PEM, או מעתיקים את תוכן האישור.

  10. לוחצים על הוספה כדי להוסיף את האישור לרשימת ההיתרים.

  11. לוחצים על יצירה.

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

gcloud

  1. יוצרים קובץ YAML של הגדרות אמון (trust_config.yaml) שמציין את הפרמטרים של הגדרות האמון. משאב ההגדרה של האמון בדוגמה הזו מכיל מאגר אישורים עם ישות עוגן אמינה ואישור ביניים. הוא קורא את תוכן האישור ממשתני הסביבה שנוצרו בשלב הקודם Format the certificates.

    cat << EOF > trust_config.yaml
trustStores:
- trustAnchors:
  - pemCertificate: "${ROOT_CERT?}"
  intermediateCas:
  - pemCertificate: "${INTERMEDIATE_CERT?}"
EOF

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

  2. אופציונלי: מציינים את האישור שנוסף לקובץ ה-YAML של הגדרות האמון בשדה allowlistedCertificates. לא צריך מאגר אישורים כדי להוסיף אישור לרשימת ההיתרים.

    cat << EOF >> trust_config.yaml
allowlistedCertificates:
- pemCertificate: "${ALLOWLISTED_CERT?}"
EOF

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

  3. כדי לייבא את קובץ ה-YAML של תצורת האמון, משתמשים בפקודה gcloud certificate-manager trust-configs import:

    גלובלי

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

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
    --source=trust_config.yaml \
    --location=global

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

    • ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון.

    אזורי

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

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
    --source=trust_config.yaml \
    --location=LOCATION

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

    • ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון.
    • ‫LOCATION: האזור שבו מאוחסן משאב הגדרות האמון. מיקום ברירת המחדל הוא global.

יצירת משאב לאימות לקוח

משאב של אימות לקוח (נקרא גם ServerTLSPolicy) מאפשר לכם לציין את מצב ה-TLS בצד השרת ואת משאב הגדרות האמון שבו יש להשתמש כשמאמתים אישורים של לקוחות. כשלקוח מציג למאזן העומסים אישור לא תקין או לא מציג אישור בכלל, ההגדרה clientValidationMode מציינת איך לטפל בחיבור של הלקוח. מידע נוסף זמין במאמר בנושא מצבי אימות של לקוח mTLS.

  • כשהמדיניות clientValidationMode מוגדרת כ-ALLOW_INVALID_OR_MISSING_CLIENT_CERT, כל הבקשות מועברות לעורף גם אם האימות נכשל או שחסר אישור לקוח.
  • כשהערך של clientValidationMode הוא REJECT_INVALID, רק בקשות שמספקות אישור לקוח שאפשר לאמת מול משאב TrustConfig מועברות אל ה-Backend.

כדי ליצור משאב של אימות לקוח (ServerTlsPolicy):

המסוף

  1. נכנסים לדף Authentication Configuration במסוף Google Cloud .

    מעבר אל Authentication Configuration

  2. בכרטיסייה Client Authentication (אימות לקוח), לוחצים על Create (יצירה).

  3. מזינים שם למשאב אימות הלקוח.

  4. בקטע מיקום, בוחרים באפשרות גלובלי או אזורי.

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

  5. ב-Client Authentication mode, בוחרים באפשרות איזון עומסים.

  6. בוחרים מצב אימות לקוח.

  7. בוחרים את משאב הגדרת האמון שיצרתם קודם.

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

  9. לוחצים על יצירה.

מוודאים שמוצג אימות הלקוח (ServerTlsPolicy).

gcloud

  1. בהתאם לאופן שבו רוצים לטפל בחיבור, בוחרים באחת מהאפשרויות הבאות כדי להגדיר את משאב אימות הלקוח (ServerTlsPolicy) בפורמט YAML.

    • אפשרות 1: הערך של clientValidationMode מוגדר ל-ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

      גלובלי

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

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
    clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
EOF

      אזורי

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

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
    clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
EOF

    • אפשרות 2: הערך של clientValidationMode מוגדר ל-REJECT_INVALID.

      גלובלי

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

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: REJECT_INVALID
    clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
EOF

      אזורי

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

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
      clientValidationMode: REJECT_INVALID
      clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
EOF

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

      ‫SERVER_TLS_POLICY_NAME: השם של משאב אימות הלקוח (ServerTlsPolicy).

      ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

      ‫LOCATION: במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), במאזני עומסים קלאסיים של אפליקציות (ALB) ובמאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים, משתמשים ב-global. במאזן עומסים חיצוני אזורי של אפליקציות (ALB) או במאזן עומסים פנימי אזורי של אפליקציות (ALB), משתמשים באזור שבו הגדרתם את מאזן העומסים.

      ‫TRUST_CONFIG_NAME: השם של משאב הגדרות האמון שיצרתם קודם.

  2. כדי לייבא את משאב ServerTlsPolicy של אימות הלקוח, משתמשים בפקודה gcloud network-security server-tls-policies import:

    גלובלי

    במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), במאזני עומסים קלאסיים של אפליקציות (ALB) ובמאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים, מגדירים את הדגל --location לערך global.

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
  --source=server_tls_policy.yaml \
  --location=global

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

    ‫SERVER_TLS_POLICY_NAME: השם של משאב אימות הלקוח (ServerTlsPolicy).

    אזורי

    במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ובמאזני עומסים פנימיים אזוריים של אפליקציות (ALB), צריך להגדיר את הדגל --location לאזור שבו מאזן העומסים מוגדר.

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
  --source=server_tls_policy.yaml \
  --location=LOCATION

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

    ‫SERVER_TLS_POLICY_NAME: השם של משאב אימות הלקוח (ServerTlsPolicy).

  3. אופציונלי: כדי להציג רשימה של כל המשאבים של אימות לקוח (ServerTlsPolicies), משתמשים בפקודה gcloud network-security server-tls-policies list:

    gcloud network-security server-tls-policies list \
  --location=LOCATION

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

    ‫LOCATION: במאזני עומסים גלובליים חיצוניים של אפליקציות, במאזני עומסים קלאסיים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות בין אזורים, משתמשים ב-global. במאזן עומסים חיצוני אזורי של אפליקציות (ALB) או במאזן עומסים פנימי אזורי של אפליקציות (ALB), משתמשים באזור שבו הגדרתם את מאזן העומסים.

צירוף משאב אימות הלקוח למאזן העומסים

כדי שאימות TLS בו-זמני (mTLS) יפעל, אחרי שמגדירים את מאזן העומסים צריך לצרף את משאב אימות הלקוח (ServerTLSPolicy) למשאב ה-proxy של HTTPS שמשמש כיעד של מאזן העומסים.

המסוף

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף איזון עומסים

  2. ברשימת מאזני העומסים, בוחרים את מאזן העומסים שאליו רוצים לצרף את משאב אימות הלקוח (ServerTLSPolicy).

  3. לוחצים על עריכה.

  4. בקטע Frontend configuration של חזית אתרים מסוג HTTPS, מרחיבים את הקטע Show Advanced features.

  5. ברשימה Client Authentication, בוחרים את משאב Client Authentication.

  6. לוחצים על סיום.

  7. לוחצים על עדכון.

gcloud

  1. כדי להציג את כל משאבי ה-HTTPS proxy בפרויקט, משתמשים בפקודה gcloud compute target-https-proxies list:

    gcloud compute target-https-proxies list

    רושמים את השם של שרת ה-proxy של היעד מסוג HTTPS כדי לצרף אליו את המשאב ServerTLSPolicy. השם הזה נקרא TARGET_HTTPS_PROXY_NAME בשלבים הבאים.

  2. כדי לייצא את ההגדרה של שרת proxy של HTTPS ליעד לקובץ, משתמשים בפקודה gcloud compute target-https-proxies export.

    גלובלי

      gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
      --destination=TARGET_PROXY_FILENAME \
      --global

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

    • ‫TARGET_HTTPS_PROXY_NAME: השם של שרת ה-proxy של היעד.
    • ‫TARGET_PROXY_FILENAME: השם של קובץ התצורה של ה-proxy של היעד בפורמט YAML. לדוגמה, mtls_target_proxy.yaml.

    אזורי

    gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
    --destination=TARGET_PROXY_FILENAME \
    --region=REGION

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

    • ‫TARGET_HTTPS_PROXY_NAME: השם של שרת ה-proxy של היעד.
    • ‫TARGET_PROXY_FILENAME: השם של קובץ התצורה של ה-proxy של היעד בפורמט YAML. לדוגמה, mtls_target_proxy.yaml.
    • ‫REGION: האזור שבו הגדרתם את מאזן העומסים.

  3. כדי להציג את כל המשאבים של Client Authentication (ServerTlsPolicy), משתמשים בפקודה gcloud network-security server-tls-policies list:

    gcloud network-security server-tls-policies list \
    --location=LOCATION

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

    ‫LOCATION: במאזן עומסים פנימי אזורי של אפליקציות, במאזן עומסים גלובלי חיצוני של אפליקציות או במאזן עומסים קלאסי של אפליקציות, משתמשים ב-global. במאזן עומסים חיצוני אזורי של אפליקציות (ALB) או במאזן עומסים פנימי אזורי של אפליקציות (ALB), צריך להשתמש באזור שבו הגדרתם את מאזן העומסים.

    רושמים את השם של משאב אימות הלקוח (ServerTLSPolicy) כדי להגדיר mTLS. השם הזה נקרא SERVER_TLS_POLICY_NAME בשלב הבא.

  4. מוסיפים את אימות הלקוח (ServerTlsPolicy) ל-Proxy של יעד HTTPS.

    echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫LOCATION: במאזני עומסים גלובליים חיצוניים של אפליקציות, במאזני עומסים קלאסיים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות בין אזורים, משתמשים ב-global. במאזן עומסים חיצוני אזורי של אפליקציות (ALB) או במאזן עומסים פנימי אזורי של אפליקציות (ALB), צריך להשתמש באזור שבו הגדרתם את מאזן העומסים.
    • ‫SERVER_TLS_POLICY_NAME: השם של משאב אימות הלקוח (ServerTLSPolicy).
    • ‫TARGET_PROXY_FILENAME: השם של קובץ התצורה של שרת ה-proxy של היעד בפורמט YAML.

  5. כדי לייבא את התצורה של שרת proxy של HTTPS ליעד מקובץ, משתמשים בפקודה gcloud compute target-https-proxies import.

    גלובלי

      gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
      --source=TARGET_PROXY_FILENAME \
      --global

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

    • ‫TARGET_HTTPS_PROXY_NAME: השם של שרת ה-proxy של היעד.
    • ‫TARGET_PROXY_FILENAME: השם של קובץ התצורה של ה-proxy של היעד בפורמט YAML. לדוגמה, mtls_target_proxy.yaml.

    אזורי

      gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
      --source=TARGET_PROXY_FILENAME \
      --region=REGION

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

    • ‫TARGET_HTTPS_PROXY_NAME: השם של שרת ה-proxy של היעד.
    • ‫TARGET_PROXY_FILENAME: השם של קובץ התצורה של שרת ה-proxy של היעד בפורמט YAML. לדוגמה, mtls_target_proxy.yaml.
    • ‫REGION: האזור שבו הגדרתם את מאזן העומסים.

הוספת כותרות מותאמות אישית של mTLS

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

הוספת כותרות מותאמות אישית של mTLS לשירותי קצה עורפי

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

  1. כדי לראות את רשימת כל שירותי ה-Backend בפרויקט, משתמשים בפקודה gcloud compute backend-services list:

    gcloud compute backend-services list

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

  2. כדי לעדכן את שירות לקצה העורפי, משתמשים בפקודה gcloud compute backend-services update:

    gcloud compute backend-services update BACKEND_SERVICE \
  --global \
  --enable-logging \
  --logging-sample-rate=1 \
  --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \
  --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \
  --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \
  --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \
  --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \
  --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \
  --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \
  --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \
  --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \
  --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'

הוספת כותרות מותאמות אישית של mTLS למפת URL

במאזן עומסים פנימי של אפליקציות (ALB) בין אזורים, במאזן עומסים חיצוני אזורי של אפליקציות (ALB) או במאזן עומסים פנימי אזורי של אפליקציות (ALB), אפשר להשתמש ב כותרות בהתאמה אישית כדי להעביר מידע על חיבור mTLS אל מפת URL.

כדי להציג את כל מיפויי כתובות ה-URL בפרויקט, משתמשים בפקודה gcloud compute url-maps list:

   gcloud compute url-maps list

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

גלובלי

כדי לערוך את מפת URL של מאזן עומסים פנימי של אפליקציות שפועל בכמה אזורים, משתמשים בפקודה gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --global

בהמשך מופיעה דוגמה לקובץ YAML שמראה איך להשתמש במשתנים בכותרות של בקשות בהתאמה אישית (requestHeadersToAdd). אפשר להשתמש באותם משתנים כדי לשלוח כותרות של תשובות בהתאמה אישית (responseHeadersToAdd).

   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"

אזורי

כדי לערוך את מפת URL עבור מאזן עומסים חיצוני אזורי של אפליקציות או מאזן עומסים פנימי אזורי של אפליקציות, השתמשו בפקודה gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --region=REGION

בהמשך מופיעה דוגמה לקובץ YAML שמראה איך להשתמש במשתנים בכותרות של בקשות בהתאמה אישית (requestHeadersToAdd). אפשר להשתמש באותם משתנים כדי לשלוח כותרות של תשובות בהתאמה אישית (responseHeadersToAdd).

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: regional-lb-map
      region: region/REGION
   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"

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

בקטע הזה מוסברת אפשרות הגדרה נוספת ליצירת אישור לקוח (עלה). אם כבר יצרתם משאב TrustConfig שמכיל אישור ביניים, צריך לבצע את הפעולות הבאות:

  1. יוצרים קובץ תצורה כדי ליצור את ה-CSR לאישור הלקוח.

    קובץ התצורה הבא (client.config) מכיל את הקטע [extension_requirements], שמציין את התוספים של X.509 שייכללו ב-CSR. מידע נוסף על הדרישות לגבי אישורי לקוח זמין במאמר דרישות לגבי אישורים.

    cat > client.config << EOF
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no

[extension_requirements]
basicConstraints          = critical, CA:FALSE
keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage          = clientAuth

[dn_requirements]
countryName               = US
stateOrProvinceName       = California
localityName              = San Francisco
0.organizationName        = example
organizationalUnitName    = test
commonName                = test.example.com
emailAddress              = test@example.com

EOF

    כדי לצרף זהות SPIFFE לקובץ התצורה:

    • מוסיפים שדה subjectAltName לקטע [extension_requirements] באופן הבא:

      subjectAltName            = @sans_list

    • מוסיפים קטע חדש ([sans_list]) בתחתית הקובץ client.config באופן הבא:

      [sans_list]
URI.1                     = spiffe://example.com/test-identity

  2. יוצרים את ה-CSR (client.csr) לאישור הלקוח.

    openssl req -new \
    -config client.config \
    -keyout client.key -out client.csr

  3. חותמים על ה-CSR כדי להנפיק את אישור הלקוח X.509 ‏ (client.cert). ה-CSR נחתם על ידי אישור הביניים.

    openssl x509 -req \
    -CAkey int.key -CA int.cert \
    -days 365 \
    -extfile client.config \
    -extensions extension_requirements \
    -in client.csr -out client.cert

  4. שליחת בקשת HTTPS מאובטחת לכתובת ה-IP של מאזן העומסים באמצעות אישור SSL בצד הלקוח. הלקוח מציג את האישור שלו (client.cert) כדי לאמת את עצמו מול מאזן העומסים.

    curl -v --key client.key --cert client.cert https://IP_ADDRESS

    מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים.

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