הגדרת אימות mTLS

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

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

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

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

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

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

    1. יוצרים מאגר רשויות אישורים. שימו לב למזהה של מאגר רשויות האישורים.

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

    2. יוצרים ומפעילים רשות אישורים (CA) עליונה למאגר.

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

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

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

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

כדי להגדיר 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 מסוף, תצטרכו תפקידים נוספים שספציפיים לשירות CA, כמו אדמין של שירות CA (roles/privateca.admin) או מפעיל של שירות CA (roles/privateca.operator).

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

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

  • אם האוסף של רשויות האישורים והאשכול של השירות המנוהל ל-Apache Kafka נמצאים באותו פרויקט, לסוכן השירות יש את ההרשאות הנדרשות כברירת מחדל. התפקיד managedkafka.serviceAgent, שמוקצה אוטומטית לסוכן השירות בפרויקט, כולל את ההרשאה הנדרשת privateca.caPools.get.

  • אם מאגר רשויות האישורים נמצא בפרויקט אחר מהפרויקט של אשכול השירות המנוהל ל-Apache Kafka, צריך להעניק לסוכן השירות הרשאה לגשת אליו באופן ידני. מקצים לסוכן השירות את התפקיד Private CA Pool Reader (roles/privateca.poolReader) בפרויקט שמכיל את מאגר רשויות ה-CA.

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

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

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

מתן גישה של סוכן השירות למאגרי 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 ברמת המאגר הספציפי (מומלץ) שמכיל את רשויות ה-CA שלכם או בכל המאגרים בפרויקט. התפקיד הזה מספק את ההרשאה הנדרשת privateca.caPools.get.

מאגר אישורים נפרד

הגישה המומלצת היא להעניק הרשאות למאגר 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 האזור שבו נמצא מאגר רשויות האישורים. לדוגמה, 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: מזהה הפרויקט שמכיל את מאגרי רשויות האישורים שאתם מעניקים להם גישה. לדוגמה, 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. מזינים את השם המלא של המשאב במאגר של רשויות אישורים בפורמט projects/PROJECT_ID/LOCATION/LOCATION/caPools/POOL_ID.
  6. כדי להוסיף עוד, לוחצים על הוספת מאגר אישורים. אפשר להוסיף עד 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. בדוגמה הזו, מוגדרים שני מאגרי אישורים.

    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: המזהה או השם של האשכול.

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

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

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

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

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

    • ‫POOL_ID_1: המזהה של מאגר האישורים הראשון. לדוגמה – 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. הפקודה הזו מחליפה את כל מאגרי הכתובות שמוגדרים כרגע. צריך לספק את הרשימה המלאה של מאגרי רשויות האישורים הנדרשים. בדוגמה הזו, מוגדרים שני מאגרי אישורים.

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

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

  • Certificate Subject 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 הוא שם הנושא (Subject) של האישור שלו (או כינוי ממופה), עם הקידומת 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: מזהה הפרויקט שמכיל את מאגר רשויות האישורים. לדוגמה – test-project-12345.

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

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

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

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

    • ‫--subject="CN=test-client-app": שם הדומיין של הנושא. השם הזה משמש כחשבון הראשי של 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: המזהה של מאגר רשויות האישורים שממנו הנפקתם את האישור. לדוגמה – test-mtls-pool1.

    • ‫REGION: האזור שבו נמצא מאגר רשויות האישורים. לדוגמה – 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.

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

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

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