הגדרת אימות mTLS

אפשר להגדיר את האשכול של השירות המנוהל ל-Apache Kafka כדי לאמת לקוחות של Kafka באמצעות TLS דו-כיווני (mTLS). בשיטה הזו נעשה שימוש באישור לקוח מ-Certificate Authority Service (שירות רשות האישורים) כבסיס לאימות. האפשרות הזו מספקת חלופה למנגנון SASL שמוגדר כברירת מחדל ומשתמש בחשבונות משתמשים של ניהול זהויות והרשאות גישה (IAM).

כשמשתמשים ב-mTLS, צריך להגדיר הרשאה באמצעות רשימות ACL של Kafka. למידע על מושגי יסוד, אפשר לעיין במסמכים הבאים:

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

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

  • מאשרים שהאשכול עומד בדרישות. מוודאים שיש לכם אשכול קיים של שירות מנוהל ל-Apache Kafka שנוצר אחרי 24 ביוני 2025. רק באשכולות האלה יש תמיכה באימות mTLS. כדי לאמת את תאריך היצירה של האשכול, משתמשים בפקודה gcloud managed-kafka clusters describe או מעיינים בדף הפרטים של האשכול במסוף.

  • מגדירים את שירות ה-CA. מגדירים את שירות ה-CA ואת מאגרי ה-CA שרוצים להשתמש בהם להנפקת אישורי לקוח. צריך ליצור אישורים בסיסיים ואישורים משניים במאגרי ה-CA.

    1. יוצרים מאגר רשויות אישורים. הערה מזהה מאגר הרשות שמנפיקה את האישורים (CA).

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

    2. יוצרים ומפעילים רשות אישורי בסיס למאגר.

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

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

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

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

כדי להגדיר mTLS, אתם (המשתמשים) וסוכן השירות של שירות מנוהל ל-Apache Kafka צריכים לוודא שיש לכם את הרשאות ה-IAM הנדרשות. ההגדרה הזו חלה גם כשיוצרים אשכול חדש וגם כשמעדכנים אשכול קיים כדי להגדיר mTLS.

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

כדי ליצור או להגדיר אשכול של שירות מנוהל ל-Apache Kafka עבור mTLS, אתם צריכים הרשאות ליצור או לעדכן את משאב האשכול. כדי לעשות את זה, צריך לבקש מהאדמין להקצות לכם את התפקיד Managed Kafka Cluster Editor (roles/managedkafka.clusterEditor) בפרויקט שמכיל את האשכול.

התפקיד המוגדר מראש הזה מכיל את ההרשאות managedkafka.clusters.create ו-managedkafka.clusters.update. ההרשאות האלה מאפשרות ליצור אשכול חדש או לשנות אשכול קיים כדי להוסיף את הגדרת מאגר שירותי ה-CA (רשות אישורים) שנדרשת ל-mTLS.

לא צריך הרשאות נפרדות למשאבים של שירות ה-CA כדי להגדיר mTLS באשכול Kafka, כל עוד יש לכם את נתיב המשאב המלא של מאגר ה-CA. עם זאת, כדי להציג, ליצור או לנהל מאגרי רשויות להנפקת אישורים (CA) במסוףGoogle Cloud , תצטרכו תפקידים נוספים שספציפיים לשירות רשויות האישורים, כמו אדמין של שירות רשויות אישורים (roles/privateca.admin) או מפעיל של שירות רשויות אישורים (roles/privateca.operator).

הרשאות של סוכני שירות

כדי שהשילוב של mTLS יפעל, לסוכן השירות של השירות המנוהל ל-Apache Kafka צריכה להיות הרשאה לגשת למאגר CA שצוין. סוכן השירות הוא חשבון שירות בניהול Google שמיועד לפרויקט שלכם.

סיכום ההרשאות הנדרשות

כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע הבא.

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

מתן גישה של סוכן השירות למאגרי CA

אם מאגר תעודות ה-CA של CA Service והאשכול של השירות המנוהל ל-Apache Kafka נמצאים בפרויקטים שונים Google Cloud , צריך להעניק לסוכן השירות של האשכול הרשאה לגשת למאגר תעודות ה-CA. השם של סוכן השירות של שירות מנוהל ל-Apache Kafka הוא service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com.

מעניקים את התפקיד CA Pool Reader (roles/privateca.poolReader) לסוכן השירות של השירות המנוהל ל-Apache Kafka ברמת המאגר הספציפי (מומלץ) שמכיל את רשויות האישורים שלכם או בכל המאגרים בפרויקט. התפקיד הזה מספק את ההרשאה הנדרשת privateca.caPools.get.

מאגר אישורים פרטי של רשות שמנפיקה אישורים (CA)

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

מריצים את הפקודה gcloud privateca pools add-iam-policy-binding:

gcloud privateca pools add-iam-policy-binding CA_POOL_ID \
    --location=CA_POOL_LOCATION \
    --member='serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com' \
    --role='roles/privateca.poolReader'

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

  • ‫CA_POOL_ID: המזהה של מאגר רשויות האישורים שאתם מעניקים לו גישה. לדוגמה, test-mtls-pool1.

  • ‫CA_POOL_LOCATION: Google Cloud האזור שבו נמצא מאגר רשויות להנפקת אישורים (CA). לדוגמה, us-central1.

  • ‫CLUSTER_PROJECT_NUMBER: מספר הפרויקט שמכיל את האשכול של השירות המנוהל ל-Apache Kafka. לדוגמה, 12341234123.

כל מאגרי הרשות שמנפיקה את האישורים (CA)

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

מריצים את הפקודה gcloud projects add-iam-policy-binding:

gcloud projects add-iam-policy-binding CA_PROJECT_ID \
    --member='serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com' \
    --role='roles/privateca.poolReader'

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

  • CA_PROJECT_ID: מזהה הפרויקט שמכיל את מאגרי רשויות להנפקת אישורים (CA) שאתם מעניקים להם גישה. לדוגמה, test-cas-project.

  • ‫CLUSTER_PROJECT_NUMBER: מספר הפרויקט שמכיל את האשכול של השירות המנוהל ל-Apache Kafka. לדוגמה, 12341234123.

הפעלת mTLS באשכול

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

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

המסוף

אפשר להפעיל mTLS באשכול חדש במהלך היצירה שלו או באשכול קיים על ידי עריכה שלו.

באשכול חדש

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

    מעבר אל Clusters

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

    ייפתח הדף Create Kafka cluster.

  3. פועלים לפי השלבים במאמר יצירת אשכול.
  4. לפני השלב האחרון, מאתרים את הקטע Optional mTLS configuration.
  5. מזינים את השם המלא של המשאב של מאגר CA בפורמט projects/PROJECT_ID/LOCATION/LOCATION/caPools/POOL_ID.
  6. כדי להוסיף עוד, לוחצים על הוספת מאגר רשויות להנפקת אישורים (CA). אפשר להוסיף עד 10 מאגרי CA.
  7. (אופציונלי) מזינים כללי מיפוי של ישויות.
  8. לוחצים על Create (יצירה) כדי ליצור את האשכול עם mTLS מופעל.

באשכול קיים

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

    מעבר אל Clusters

  2. לוחצים על השם של האשכול שרוצים לעדכן.
  3. לוחצים על Edit.
  4. בקטע mTLS configuration, מוסיפים או משנים את רשימת מאגרי CA. אפשר להוסיף עד 10 מאגרי CA.
  5. (אופציונלי) מזינים או עורכים כללי מיפוי של ישויות ראשיות.
  6. לוחצים על Save.

gcloud

באשכול חדש

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

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

  2. מריצים את הפקודה gcloud managed-kafka clusters create עם הדגל --mtls-ca-pools. בדוגמה הזו, מוגדרים שני מאגרי רשויות להנפקת אישורים (CA).

    gcloud managed-kafka clusters create CLUSTER_ID \
    --location=LOCATION \
    --cpu=3 \
    --memory=3GiB \
    --subnets=projects/PROJECT_ID/locations/LOCATION/subnetworks/SUBNET_ID \
    --mtls-ca-pools=projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_1,projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_2

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

  • ‫CLUSTER_ID: המזהה או השם של האשכול.

    מידע נוסף על מתן שם לאשכול זמין במאמר הנחיות למתן שם למשאב של שירות מנוהל ל-Apache Kafka. לדוגמה – test-mtls-cluster.

  • ‫LOCATION: המיקום של האשכול.

    מידע נוסף על מיקומים נתמכים זמין במאמר בנושא מיקומים נתמכים של שירות מנוהל ל-Apache Kafka. לדוגמה – us-central1.

  • ‫SUBNETS: רשימת רשתות המשנה להתחברות. כדי להפריד בין כמה ערכים של רשתות משנה, צריך להשתמש בפסיקים.

    הפורמט של רשת המשנה הוא projects/PROJECT_ID/locations/LOCATION/subnetworks/SUBNET_ID.

    • ‫POOL_ID_1: המזהה של מאגר רשויות להנפקת אישורים (CA) הראשון. לדוגמה – test-mtls-pool1.

  • ‫POOL_ID_2: המזהה של מאגר אישורי ה-CA השני. לדוגמה – test-mtls-pool2.

באשכול קיים

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

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

  2. משתמשים בפקודה gcloud managed-kafka clusters update. הפקודה הזו מחליפה את כל מאגרי הכתובות שמוגדרים כרגע. מספקים את הרשימה המלאה של מאגרי ה-CA הנדרשים. בדוגמה הזו, מוגדרים שני מאגרי רשויות להנפקת אישורים (CA).

    gcloud managed-kafka clusters update CLUSTER_ID \
    --location=LOCATION \
    --mtls-ca-pools=projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_1,projects/PROJECT_ID/locations/LOCATION/caPools/POOL_ID_2

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

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

כשלקוח מבצע אימות באמצעות mTLS, כברירת מחדל, פרטי המשתמש ב-Kafka נגזרים מהשם הייחודי (DN) של הנושא באישור, והם בפורמט User:CN=...,OU=...,O=...,L=...,ST=...,C=.... יוצרים כללי מיפוי כדי להמיר את ה-DN של נושא האישור לכינוי נוח שקל יותר להשתמש בו ב-ACL של Kafka. מידע נוסף על הטופס של שם הנושא ב-DN זמין במאמר התאמה אישית של שם המשתמש ב-SSL בתיעוד של Apache Kafka.

הטרנספורמציות האלה מוגדרות על ידי המאפיין ssl.principal.mapping.rules של ברוקר Kafka, שמשתמש בביטויים רגולריים כדי לחלץ ולעצב מחדש חלקים מנושא האישור.

לדוגמה, אפשר להחיל כלל כדי להמיר שם DN מלא של נושא לכינוי באופן הבא:

  • נושא האישור DN: CN=order-processing-app,OU=marketing,O=company,C=US

  • כלל מיפוי: RULE:^.*[Cc][Nn]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT

  • המשתמש הראשי ב-Kafka שנוצר: order-processing-app

כלל לדוגמה שמחלץ את השם המוכר (CN) מנושא האישור ומשתמש בו כשם העיקרי ב-Kafka.

כדי להגדיר כלל מיפוי באשכול באמצעות Google Cloud CLI, מבצעים את השלבים הבאים. כשמשתמשים במסוף, אפשר להגדיר את כללי המיפוי כשיוצרים או מעדכנים אשכול.

  • כדי לעדכן את האשכול, משתמשים בפקודה gcloud managed-kafka clusters update עם הדגל --ssl-principal-mapping-rules.

    gcloud managed-kafka clusters update CLUSTER_ID \
    --location=REGION \
    --ssl-principal-mapping-rules='MAPPING_RULE'

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

    • ‫CLUSTER_ID: המזהה של האשכול של השירות המנוהל ל-Apache Kafka שאתם יוצרים. לדוגמה – test-kafka-cluster.

    • ‫REGION: Google Cloud האזור שבו רוצים ליצור את האשכול. לדוגמה – us-central1.

    • ‫MAPPING_RULE*: כלל המיפוי שרוצים להחיל. לדוגמה – RULE:^.*[Cc][Nn]=([a-zA-Z0-9.-]*).*$/$1/L,DEFAULT.

מידע נוסף על כתיבת כללי מיפוי זמין במאמר בנושא הרשאות ורשימות ACL במסמכי התיעוד של Apache Kafka.

הגדרת רשימות ACL של Kafka עבור ישויות mTLS

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

כדי ליצור רשימות ACL של Kafka, צריך את תפקיד ה-IAM‏ Managed Kafka ACL Editor (roles/managedkafka.aclEditor).

נניח שיש לכם אפליקציה שמזוהה באמצעות האישור שלה, ושיוצרת הודעות ל-orders-topic וצורכת הודעות מ-analytics-topic. חשבון המשתמש של האפליקציה, אחרי פישוט באמצעות כלל מיפוי, הוא order-processing-app. כשיוצרים רשימות ACL ב-Kafka, צריך להוסיף את הקידומת User: ל-principal.

  1. מחילים את רשימת ה-ACL‏ WRITE על האשכול. מריצים את הפקודה gcloud managed-kafka acls add-acl-entry כדי להעניק הרשאה WRITE ב-orders-topic.

    gcloud managed-kafka acls add-acl-entry topic/orders-topic \
    --cluster=CLUSTER_ID \
    --location=REGION \
    --principal=User:order-processing-app \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host="*"

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

    • ‫CLUSTER_ID: המזהה של האשכול של השירות המנוהל ל-Apache Kafka שאתם יוצרים. לדוגמה – test-kafka-cluster.

    • ‫REGION: Google Cloud האזור שבו רוצים ליצור את האשכול. לדוגמה – us-central1.

  2. מחילים את רשימת ה-ACL‏ READ על האשכול. מריצים את הפקודה gcloud managed-kafka acls add-acl-entry כדי להעניק הרשאה READ ב-analytics-topic.

    gcloud managed-kafka acls add-alc-entry topic/analytics-topic \
    --cluster=CLUSTER_ID \
    --location=REGION \
    --principal=User:order-processing-app \
    --operation=READ \
    --permission-type=ALLOW \
    --host="*"

אחרי שמחילים את רשימות בקרת הגישה האלה, ללקוח order-processing-app יש רק את ההרשאות הספציפיות שהענקתם. מידע נוסף על יצירת רשימות ACL זמין במאמר יצירת רשימות ACL של Kafka.

הגדרת לקוחות Kafka

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

  1. יוצרים ומורידים אישור לקוח במכונת הלקוח. מריצים את הפקודה gcloud privateca certificates create כדי להנפיק אישור חדש מאחד ממאגרי ה-CA שהגדרתם עבור האשכול.

    הפקודה הזו מורידה את האישור client-cert.pem ואת המפתח הפרטי שלו client-key.pem לסביבה המקומית.

    gcloud privateca certificates create CERTIFICATE_ID \
    --project=PROJECT_ID \
    --issuer-location=REGION \
    --issuer-pool=POOL_ID \
    --ca=CA_NAME \
    --generate-key \
    --dns-san="client.example.com" \
    --subject="CN=test-client-app" \
    --key-output-file=client-key.pem \
    --cert-output-file=client-cert.pem

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

    • ‫CERTIFICATE_ID: שם ייחודי של אובייקט האישור. לדוגמה – order-app-cert.

    • PROJECT_ID: מזהה הפרויקט שמכיל את מאגר רשויות להנפקת אישורים (CA). לדוגמה – test-project-12345.

    • REGION: האזור שבו נמצא מאגר רשויות להנפקת אישורים (CA). לדוגמה – us-central1.

    • ‫POOL_ID: המזהה של מאגר רשויות להנפקת אישורים (CA) שממנו יונפק האישור. לדוגמה – test-mtls-pool1.

    • ‫CA_NAME: השם של רשות האישורים במאגר. לדוגמה – test-sub-ca.

    • ‫--dns-san="client.example.com": שם חלופי של בעלים (subject) של ה-DNS. אפשר להשתמש בכל ערך שרלוונטי ללקוח.

    • ‫--subject="CN=test-client-app": ה-DN של הנושא. השם הזה משמש כזהות העיקרית של mTLS, אלא אם הגדרתם כלל למיפוי שמות של זהויות עיקריות.

  2. מציגים את אישור הלקוח, מציגים את נושא האישור ומאמתים את ssl.principal.mapping.rules. מריצים את הפקודה gcloud privateca certificates describe:

    gcloud privateca certificates describe CERTIFICATE_ID \
   --issuer-pool=POOL_ID \
   --issuer-location=REGION

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

    • ‫CERTIFICATE_ID: השם הייחודי של אובייקט האישור. לדוגמה – order-app-cert.

    • ‫POOL_ID: המזהה של מאגר רשויות להנפקת אישורים (CA) שממנו הנפקתם את האישור. לדוגמה – test-mtls-pool1.

    • REGION: האזור שבו נמצא מאגר רשויות להנפקת אישורים (CA). לדוגמה – us-central1.

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

    certificateDescription:
  aiaIssuingCertificateUrls:
  - http://privateca-content-68e092f4-0000-288c-95cf-30fd3814648c.storage.googleapis.com/a6553d092bbedd752e34/ca.crt
  authorityKeyId:
    keyId: 9568aa9d2baa11a097addc2e24adeaebea0d6a2a
  certFingerprint:
    sha256Hash: 230e52b8411fd094048fca194fc6cf80e41b3e8561298aec3519e13cb1fd05eb
  ...
  subjectDescription:
    hexSerialNumber: 2107b74cf5a814043a38a87eeb6cd7c7891a5f
    lifetime: P30D
    notAfterTime: '2025-07-13T15:34:43Z'
    notBeforeTime: '2025-06-13T15:34:44Z'
    subject:
      commonName: test-client-app
    subjectAltName:
      dnsNames:
      - client.example.com
  ...

  3. יוצרים Java KeyStore. משלבים את האישור והמפתח הפרטי בקובץ PKCS#12, ואז מייבאים אותו לקובץ Java KeyStore ‏ (.jks).

    # Create a password for the keystore
export KEYSTORE_PASSWORD="KEYSTORE_PASSWORD"

# Combine the key and cert into a PKCS#12 file
openssl pkcs12 -export -inkey client-key.pem -in client-cert.pem \
  -name client -out client-keystore.p12 -password "pass:$KEYSTORE_PASSWORD"

# Import the PKCS#12 file into a Java KeyStore
keytool -importkeystore -srckeystore client-keystore.p12 -srcstoretype pkcs12 \
  -destkeystore client-keystore.jks -srcstorepass "$KEYSTORE_PASSWORD" -deststorepass "$KEYSTORE_PASSWORD"

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

    keytool -v -list -keystore client-keystore.jks -storepass "$KEYSTORE_PASSWORD"

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

    Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: client
Creation date: Jun 13, 2024
Entry type: Private key entry
Certificate chain length: 1
Certificate[1]:
Owner: CN=test-client-app
Issuer: CN=test-sub-ca
...

    שימו לב שבשורה Owner מוצג ה-DN של נושא האישור. כברירת מחדל,‏ Kafka מגדיר את שם המשתמש של Kafka בפורמט המדויק הזה: CN=...,OU=...,O=...,L=...,ST=...,C=.... מידע נוסף זמין במאמר בנושא הרשאות ורשימות בקרת גישה (ACL) במסמכי התיעוד של Apache Kafka.

  4. מגדירים את מאפייני לקוח Kafka ואת כתובת ה-bootstrap. באפליקציית הלקוח של Kafka, מגדירים את המאפיינים הבאים כדי להשתמש במאגר המפתחות לחיבור SSL. בנוסף, חשוב להשתמש בכתובת הנכונה של ה-bootstrap עם היציאה 9192. מידע נוסף על הגדרת לקוח זמין במאמר תחילת העבודה: יצירת אשכול של שירות מנוהל ל-Apache Kafka וחיבור לקוח.

    security.protocol=SSL
ssl.keystore.location=KEYSTORE_LOCATION
ssl.keystore.password=KEYSTORE_PASSWORD
bootstrap.servers=CLUSTER_BOOTSTRAP_ADDRESS

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

    • ‫KEYSTORE_LOCATION: הנתיב לקובץ .jks.

    • ‫KEYSTORE_PASSWORD: הסיסמה של מאגר המפתחות.

    • ‫CLUSTER_BOOTSTRAP_ADDRESS: כתובת ה-bootstrap של האשכול. כדי למצוא את כתובת ה-bootstrap, אפשר לעיין במאמר בנושא הצגת פרטי האשכול. חשוב להוסיף את מספר היציאה כ-9192.

אבטחת הגדרות הלקוח

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

  • מאחסנים את מאגר המפתחות ואת הסיסמה שלו כסודות ב-Google Cloud Secret Manager ומאחזרים אותם בזמן הריצה בקוד האפליקציה.

  • אם אתם פורסים את האפליקציה ב-GKE, אתם יכולים להשתמש בתוסף Secret Manager כדי לטעון את הסודות במערכת הקבצים של האפליקציה בזמן הריצה.

מעקב אחר mTLS

אפשר לעקוב אחרי התקינות של עדכוני אישורים של mTLS באמצעות מדדים ויומנים ב-Cloud Monitoring וב-Cloud Logging.

כדי לעקוב באופן יזום אחרי תקינות העדכונים של אישורי mTLS, אפשר להשתמש במדד managedkafka.googleapis.com/mtls_truststore_update_count ב-Monitoring. המדד הזה סופר את הניסיונות לעדכן את מאגר האישורים וכולל את התווית STATUS, שיכולה להיות SUCCESS או סיבת הכשל, כמו CA_POOL_FETCH_ERROR.

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

עדכונים של truststore צורכים את המכסה של Certificate Authority Service API. חשוב להבין את הנקודות הבאות:

  • תהליך העדכון קורא לשיטה FetchCaCerts, שחלה עליה מכסת API requests per minute per region.

  • השימוש הזה במכסה משויך לפרויקט שמכיל את מאגר רשויות להנפקת אישורים (CA) שאליו מתייחסים, ולא לפרויקט של השירות המנוהל ל-Apache Kafka.

  • מגבלת ברירת המחדל היא 400 שאילתות לשנייה (QPS) לכל אזור. בהתחשב בתדירות הנמוכה של בקשה אחת לשעה לכל אשכול, סביר להניח שהעדכונים האלה של truststore לא יגרמו לכם לחרוג מהמכסה הזו.

אפשר גם לעקוב אחרי עדכונים של truststore באמצעות צפייה ביומנים ב-Logging. מחפשים את רשומות היומן הבאות כדי לוודא שהעדכונים בוצעו בהצלחה:

  • Managed Service for Apache Kafka updated the mTLS trust store

  • Added root CA certificate to trust store

פתרון בעיות

מידע על פתרון בעיות באימות mTLS מופיע במאמר פתרון בעיות ב-mTLS.

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

‫Apache Kafka®‎ הוא סימן מסחרי רשום של The Apache Software Foundation או של השותפים העצמאיים שלה בארצות הברית או במדינות אחרות.