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

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

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

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

  • קוראים את הסקירה הכללית על Mutual TLS.
  • קוראים את המדריך ניהול הגדרות האמון.

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

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

  • מפעילים את ממשקי ה-API הבאים: Compute Engine API,‏ Certificate Manager API,‏ אבטחת רשת ו-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 ‏(roles/compute.loadBalancerAdmin)
  • כדי להשתמש במשאבים של Certificate Manager: בעלים של Certificate Manager (roles/certificatemanager.owner)
  • כדי ליצור רכיבי אבטחה ורשת: אדמין של רשת Compute‏ (roles/compute.networkAdmin) ואדמין של אבטחת Compute‏ (roles/compute.securityAdmin)
  • כדי ליצור פרויקט (אופציונלי): יצירת פרויקטים (roles/resourcemanager.projectCreator)

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

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

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

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

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

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

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

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

    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. יוצרים מפתח פרטי חדש מסוג RSA‏ (root.key) ומשתמשים בו כדי ליצור אישור CA בסיסי מסוג X.509 עם חתימה עצמית (root.cert), שמשמש כרשות אישורי בסיס (CA).

    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. יוצרים בקשה לחתימה על אישור (CSR) (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. יוצרים את אישור הביניים X.509‏ (int.cert) מה-CSR. רשות האישורים הבסיסית משתמשת במפתח הפרטי (root.key) ובאישור (root.cert) שלה כדי להנפיק את אישור הביניים X.509 ולחתום עליו.

    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

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

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

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

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

  3. נותנים שם להגדרה האישית.

  4. בשדה Location, בוחרים באפשרות Global או Regional.

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

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

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

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

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

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

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

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

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

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

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

gcloud

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

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

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

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

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

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

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

    גלובלית

    במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), במאזני עומסים קלאסיים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות בכמה אזורים, מציינים את 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 מועברות לקצה העורפי.
  • כשהערך של clientValidationMode מוגדר כ-ALLOW_VALIDATION_RELAXATIONS, רק בקשות שמספקות אישור לקוח שאפשר לאמת מול משאב TrustConfig – עם החלת הקלות האימות שצוינו (clientValidationRelaxations) – מועברות לקצה העורפי.

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

המסוף

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

    כניסה לדף Authentication Configuration

  2. בכרטיסייה Client Authentication, לוחצים על Create.

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

  4. בשדה Location, בוחרים באפשרות Global או Regional.

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

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

  6. בקטע Client Validation Mode, בוחרים באחת מהאפשרויות הבאות:

    • דחיית הצעות לא תקינות
    • אישור לקוח לא תקין או חסר
    • אישור הקלות באימות

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

    אם בוחרים באפשרות אישור הקלות באימות, בוחרים אחת או יותר מההקלות הבאות באימות:

    • אישור EKU חסר
    • מתן הרשאה לגיבוב SHA-1
    • אישור קצה שפג תוקפו

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

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

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

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

gcloud

  1. בהתאם לאופן שבו רוצים לטפל בחיבור, בוחרים אחת מהאפשרויות הבאות כדי להגדיר את המשאב Client Authentication (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.

      גלובלית

      במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), במאזני עומסים קלאסיים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות בכמה אזורים, יוצרים קובץ 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

    • אפשרות 3: clientValidationMode מוגדר ל-ALLOW_VALIDATION_RELAXATIONS.

      גלובלית

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

      cat << EOF > server_tls_policy.yaml
name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
    clientValidationMode: ALLOW_VALIDATION_RELAXATIONS
    clientValidationRelaxations:
    - VALIDATION_RELAXATION
    - VALIDATION_RELAXATION
    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_VALIDATION_RELAXATIONS
    clientValidationRelaxations:
    - VALIDATION_RELAXATION
    - VALIDATION_RELAXATION
    clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
EOF

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

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

    • ‫VALIDATION_RELAXATION: אחד או יותר מהערכים הבאים: ALLOW_MISSING_EKU,‏ ALLOW_SHA1_HASHING או ALLOW_EXPIRED_LEAF_CERTIFICATE.

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

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

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

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

    גלובלית

    במאזני עומסים גלובליים חיצוניים של אפליקציות (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).

    אזורי

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

צירוף המשאב Client Authentication למאזן העומסים

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

המסוף

  1. במסוף Google Cloud , עוברים לדף איזון עומסים.

    כניסה לדף Load balancing

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

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

  4. בקטע Frontend configuration של ממשק קצה מסוג HTTPS, מרחיבים את הקטע תכונות מתקדמות.

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

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

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

gcloud

  1. כדי להציג את כל משאבי שרת ה-proxy ל-HTTPS בפרויקט, משתמשים בפקודה 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. כדי להציג את כל המשאבים של אימות הלקוח (ServerTlsPolicy), משתמשים בפקודה gcloud network-security server-tls-policies list:

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

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

    ‫LOCATION: למאזן עומסים פנימי של אפליקציות (ALB) בין אזורים, למאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או למאזן עומסים קלאסי של אפליקציות (ALB), משתמשים ב-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. כדי להציג את כל שירותי הקצה העורפי בפרויקט, משתמשים בפקודה 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 \
  --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 של מאזן עומסים פנימי של אפליקציות (ALB) בכמה אזורים, משתמשים בפקודה gcloud compute url-maps edit:

   gcloud compute url-maps edit URL_MAP_NAME --global

בהמשך מוצג קובץ YAML לדוגמה שמראה איך להשתמש במשתנים בכותרות של request header (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. יוצרים אישור לקוח (client.cert) מה-CSR. רשות האישורים המתווכת משתמשת במפתח הפרטי (int.key) ובאישור (int.cert) שלה כדי להנפיק ולחתום על אישור הלקוח מסוג X.509.

    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 של מאזן העומסים.

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