בדף הזה מוסבר על שיטות האימות הנתמכות באפליקציות לקוח שמתחברות לשרתי ברוקר של שירות מנוהל של Google Cloud ל-Apache Kafka.
לאפליקציות לקוח של שירות מנוהל של Google Cloud ל-Apache Kafka שפועלות בשירותים כמו Google Kubernetes Engine, Compute Engine, Cloud Run או פונקציות Cloud Run, יש לכם את אפשרויות האימות הבאות: Google Cloud
SASL/OAUTHBEARER (מומלץ): זו השיטה הכי חלקה ומאובטחת ללקוחות בתוך Google Cloud. היא משתמשת ב-Application Default Credentials (ADC) כדי למצוא באופן אוטומטי את זהות חשבון השירות שמשויכת לסביבה. כך לא צריך לנהל ולהפיץ קבצים של פרטי כניסה סטטיים, כמו מפתחות של חשבונות שירות.
SASL/PLAIN: שיטה שימושית בשלבי פיתוח מוקדמים. הלקוח מבצע אימות באמצעות מפתח של חשבון שירות שתוקפו ארוך.
mTLS: זו אפשרות אם התקן של הארגון מבוסס על אימות באמצעות אישורים. האפליקציה שלך בכתובת Google Cloud מוגדרת עם אישור ומפתח לקוח.
באפליקציות לקוח שפועלות מחוץ ל- Google Cloud, למשל במרכז נתונים מקומי או בספק שירותי ענן אחר, כדאי להשתמש בשיטות האימות הבאות. בוחרים את השיטה הכי טובה בהתאם למצב האבטחה של הארגון ולתשתית הזהויות הקיימת.
איחוד שירותי אימות הזהויות של עומסי עבודה עם SASL/OAUTHBEARER (מומלץ): זו השיטה הכי מאובטחת ללקוחות חיצוניים. התכונה מאפשרת להעניק לזהויות ממערכות חיצוניות, כמו AWS, Microsoft Azure או ספק זהויות מקומי כמו ADFS, את היכולת להתחזות לGoogle Cloud חשבון שירות. במקום לנהל מפתחות של חשבונות שירות לטווח ארוך, הלקוח משתמש בפרטי הכניסה המועדפים שלו כדי לקבל אסימון גישה לטווח קצר. Google Cloud לאחר מכן הלקוח משתמש באסימון הזה לאימות, מה שמפחית באופן משמעותי את סיכון האבטחה שקשור לקובצי אישורים סטטיים.
mTLS: השיטה הזו לא תלויה בספק, והיא מתאימה אם הארגון שלכם כבר משתמש בתשתית מפתח ציבורי (PKI) כדי לנהל אישורי TLS לזהות השירות. הוא מאפשר ללקוחות לבצע אימות בלי זהות ספציפית. Google Cloudעם זאת, בדומה לשימוש במפתחות של חשבונות שירות, הגישה הזו מחייבת אתכם לנהל את מחזור החיים וההפצה של פרטי כניסה לטווח ארוך, כמו אישורי לקוח.
SASL/PLAIN עם מפתח של חשבון שירות: השיטה הזו מאפשרת ללקוח חיצוני לבצע אימות ישירות כ Google Cloud זהות. מורידים קובץ JSON של מפתח חשבון שירות ומשתמשים בו בהגדרות SASL/PLAIN של הלקוח. בדרך כלל לא מומלץ להשתמש בשיטה הזו בעומסי עבודה של ייצור, כי היא מחייבת ניהול ואבטחה של פרטי כניסה סטטיים לטווח ארוך בצד הלקוח.
השוואה בין תכונות של SASL ו-mTLS
מנגנון האימות העיקרי בשירות המנוהל ל-Apache Kafka הוא SASL (שכבת אבטחה ואימות פשוטים), שמשולב ישירות עם שירותי הזהויות שלGoogle Cloud. כברירת מחדל, SASL מאמת לקוחות באמצעות חשבון משתמש ב-IAM, כמו חשבון שירות. Google Cloud ל-SASL יש גמישות בכל הנוגע להרשאה: אפשר לנהל גישה לאשכולות באמצעות תפקידים פרטניים ב-IAM ורשימות של בקרת גישה (ACL) ב-Kafka.
לעומת זאת, mTLS מציע שיטת אימות שאינה תלויה בספק ושלא מסתמכת על Google Cloud IAM. במקום זאת, אימות mTLS מאמת לקוח על סמך אישור ה-TLS שלו, כאשר הזהות נגזרת משם הנושא של האישור.
ההבחנה הזו מובילה להבדל משמעותי באופן הטיפול בהרשאות. בניגוד לחשבונות משתמש ב-SASL, צריך לאשר חשבונות משתמש ב-mTLS באמצעות רשימות בקרת גישה (ACL) של Kafka בלבד. אי אפשר לנהל אותם באמצעות תפקידי IAM ב- Google Cloud .
מומלץ מאוד להגדיר רשימות בקרת גישה (ACL) של Kafka עבור האשכול. אם לא מוגדרות רשימות ACL, התנהגות ברירת המחדל של Kafka היא להעניק לכל הגורמים המאומתים – בין אם הם משתמשים ב-SASL או ב-mTLS – גישה מלאה לאשכול. מידע נוסף על הגדרת רשימות ACL ב-Kafka זמין במאמר יצירת רשימת ACL בשירות מנוהל ל-Apache Kafka.
השירות המנוהל ל-Apache Kafka תומך באימות mTLS עם אישורי לקוח שהונפקו על ידי רשויות אישורים שנמצאות בשירות ה-CA. אם הארגון שלכם משתמש בשורש חיצוני של אמון, אתם יכולים לשלב אותו על ידי יצירת רשות אישורים (CA) משנית ב-CA Service, שמתחברת לרשות האישורים החיצונית שלכם.
בטבלה הבאה מוצגת השוואה בין התכונות של שיטות האימות.
| תכונה | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| הזהות הראשית | Google Cloud חשבון ראשי ב-IAM | Google Cloud חשבון ראשי ב-IAM | שם הנושא של האישור |
| סוג פרטי הכניסה | Application Default Credentials (ADC) או אסימון OAuth 2.0 | מפתח של חשבון שירות בקידוד Base64 | אישור לקוח ומפתח פרטי |
| שיטת ההרשאה | Google Cloud תפקידי IAM או רשימות ACL של Kafka | Google Cloud תפקידי IAM או רשימות ACL של Kafka | הרשאות ACL של Kafka בלבד |
| תרחיש לדוגמה | לקוחות ב- Google Cloud; לקוחות חיצוניים באמצעות איחוד שירותי אימות הזהויות של עומסי עבודה | לקוחות פשוטים, תרחישי בדיקה או מערכות מדור קודם שבהן נדרש שימוש במפתח של חשבון שירות. | לא תלוי בספק; אידיאלי לאפליקציות מקומיות, מרובות עננים או PKI קיימות. |
| הגדרת לקוח | הגדרת JAAS עם מחלקה מיוחדת לטיפול בהתחברות (Java) או שרת אימות מקומי (שאינו Java) | הגדרות JAAS עם PlainLoginModule רגיל (Java) | מאפיינים של מאגר מפתחות ומאגר אישורים (לדוגמה – security.protocol=SSL) |
| זמינות האשכול | כל האשכולות | כל האשכולות | אשכולות שנוצרו אחרי 24 ביוני 2025 |
בחירה בין SASL לבין mTLS
בחירת שיטת האימות תלויה במדיניות האבטחה של הארגון ובמבנה הקיים. ברוב תרחישי השימוש, מומלץ להשתמש ב-SASL עם Google Cloud IAM.
SASL עם Google Cloud IAM או איחוד שירותי אימות הזהות של עומסי עבודה מספק את החוויה הכי גמישה ומשולבת לאימות ולהרשאות. היא משתמשת במערכת הזהויות של Google Cloudכמקור האמת היחיד לניהול הרשאות. בוחרים באפשרות הזו אם רוצים:
ניהול מרכזי של הרשאות ללקוחות Kafka באמצעותGoogle Cloud תפקידי IAM מוכרים.
לא מומלץ לנהל פרטי כניסה סטטיים בלקוחות.
הפעלת אימות של לקוחות מעננים אחרים כמו AWS, Azure או ספקי זהויות מקומיים כמו Okta או ADFS באמצעות איחוד שירותי אימות הזהות של עומסי עבודה. השיטה הזו מספקת פתרון זהות מאובטח שלא תלוי בענן, בלי צורך לעבור לפרוטוקול אימות אחר.
בוחרים באפשרות mTLS אם בארגון יש דרישה מחמירה לאימות מבוסס-אישורים. הצורך הזה מתעורר כשמעבירים פריסת Kafka קיימת מקומית שכבר נעשה בה שימוש באישור TLS לצורך זיהוי, או כשמדיניות החברה מחייבת אישורי לקוח לכל האפליקציות. mTLS מספק אבטחה חזקה ברמת התעבורה, אבל חשוב לזכור שצריך לנהל את ההרשאה ללקוחות mTLS באופן בלעדי באמצעות Kafka ACLs, שזה נפרד מ- Google Cloud IAM.
תהליך העבודה להגדרת SASL/PLAIN או SASL/OAUTHBEARER
כדי להגדיר לקוח להשתמש באימות SASL עם שירות מנוהל ל-Apache Kafka, צריך להעניק הרשאות לזהות של הלקוח ואז להגדיר את אפליקציית הלקוח על סמך מנגנון ה-SASL שנבחר. בהמשך מופיעה סקירה כללית של תהליך העבודה הנדרש. הוראות מפורטות להגדרת SASL מופיעות במאמר הגדרת אימות SASL.
מתן הרשאות IAM קודם צריך להעניק לחשבון השירות שהלקוח משתמש בו לאימות את התפקיד Managed Kafka Client (
roles/managedkafka.client). התפקיד הזה מספק את ההרשאהmanagedkafka.clusters.connectשנדרשת כדי להתחבר לאשכולות Kafka בפרויקט.הגדרת לקוח Kafka ההגדרה הספציפית של הלקוח תלויה במנגנון שבו משתמשים: SASL/OAUTHBEARER או SASL/PLAIN.
עבור SASL/OAUTHBEARER (מומלץ): המנגנון הזה משתמש ב-Application Default Credentials (ADC). ההגדרה תלויה בשפה של הלקוח:
לקוחות Java: מוסיפים את ספריית האימות Google Cloud המיוחדת לנתיב המחלקה של האפליקציה. לאחר מכן, מגדירים את מאפייני הלקוח של Kafka כך שישתמשו במחלקה
GcpLoginCallbackHandlerשסופקה, שמטפלת באימות באופן אוטומטי באמצעות ADC.
GcpLoginCallbackHandlerהוא מחלקה שמשמשת עם מנגנון האימות OAUTHBEARER של Kafka, שנועד במיוחד לשימוש עם שירות מנוהל ל-Apache Kafka. הוא מטפל בתהליך של קבלת אסימון אינטרנט מסוג JSON (JWT) מספק הזהויות של Google, ומאפשר ללקוחות Kafka לבצע אימות מול השירות באמצעות ADC.לקוחות שאינם Java: מריצים שרת אימות מקומי שסופק במכונה של הלקוח. השרת הזה משתמש ב-ADC כדי לאחזר פרטי כניסה ומספק אותם ללקוח Kafka. לאחר מכן, הלקוח מוגדר לקבל את טוקן האימות שלו מנקודת הקצה של השרת המקומי הזה.
עבור SASL/PLAIN
המנגנון הזה משתמש בשם משתמש ובסיסמה. צריך להגדיר את אפליקציית הלקוח כך שתשתמש בפרוטוקול האבטחה SASL_SSL, במנגנון PLAIN ובהגדרת JAAS שמציינת את המחלקה
PlainLoginModule.שם המשתמש הוא כתובת האימייל של חשבון השירות. אפשר ליצור את הסיסמה באחת משתי דרכים:
על ידי קידוד base64 של קובץ JSON של מפתח חשבון שירות.
קבלת אסימון גישה לטווח קצר.
הגדרת הרשאות אחרי שלקוח עובר אימות בהצלחה באמצעות SASL, הגישה שלו נשלטת על ידי הרשאות שמוגדרות בתפקידי IAM או ברשימות ACL של Kafka באשכול.
מגבלות של SASL
שיטת האימות SASL כוללת את המגבלות הבאות:
אימות SASL קשור באופן מובנה לחשבונות ראשיים ב-IAM. השיטה הזו לא מתאימה לארגונים שנדרש בהם הפרדה מוחלטת מGoogle Cloud זהויות או לארגונים שמשתמשים בזהויות שאינן של Google, אלא אם מגדירים איחוד שירותי אימות הזהות של עומסי עבודה.
SASL לא משתמש באישור לקוח לאימות. היא לא מתאימה באופן ישיר לארגונים שמסתמכים על PKI קיים כדי לזהות אפליקציות.
תהליך העבודה להגדרת mTLS
הגדרת mTLS בשירות מנוהל ל-Apache Kafka כוללת הגדרה של רשויות אישורים, אשכול Kafka ולקוחות Kafka. הוראות מפורטות להגדרת mTLS זמינות במאמר הגדרת אימות mTLS.
הגדרת רשויות אישורים (CA). קודם צריך ליצור ולהגדיר מאגרי CA ב-Certificate Authority Service (שירות CA). אם יוצרים מאגרי רשויות אישורים שנמצאים בפרויקט אחר, צריך לוודא שסוכן השירות של השירות המנוהל ל-Apache Kafka (
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com) קיבל הרשאה לגשת למאגרים האלה. צריך ליצור אישורים בסיסיים ואישורים משניים במאגרי ה-CA.הגדרת אשכול Kafka. יוצרים או מעדכנים את האשכול כדי להפעיל mTLS על ידי ציון מזהי המשאבים של מאגרי ה-CA שהגדרתם. מומלץ גם להגדיר את מאפיין המתווך
ssl.principal.mapping.rulesכדי ליצור שמות פשוטים של חשבונות משתמש בשירות לשימוש ברשימות ACL. אפשר לעשות זאת באמצעות פקודות של Google Cloud CLI.הגדרת לקוחות Kafka מקבלים אישורי לקוח מ-CA ומתקינים אותם בסביבה של הלקוח, למשל במאגר מפתחות של Java. לאחר מכן צריך להגדיר באפליקציית הלקוח את פרוטוקול האבטחה הנכון (SSL) ואת המיקום של מאגר המפתחות שלה כדי להתחבר ליציאת האתחול הייעודית של mTLS באשכול, שהיא
9192.מעקב אחרי mTLS. אחרי ההגדרה, כדאי לעקוב אחרי המדד
managedkafka.googleapis.com/mtls_truststore_update_countכדי לוודא שהאשכול מרענן בהצלחה את אישורי ה-CA שלו ממאגרי CA Service, שהוא מנסה לעשות זאת מעת לעת. אפשר גם להשתמש ב-Cloud Logging.
מגבלות של mTLS
לתכונת ה-mTLS יש את המגבלות הבאות:
אפשר להשתמש בתכונת mTLS רק באשכולות של שירות מנוהל ל-Apache Kafka שנוצרו אחרי 24 ביוני 2025.
צריך להגדיר הרשאה לחשבונות משתמשים של mTLS באמצעות רשימות ACL של Kafka. אי אפשר להשתמש בקשירת תפקידי IAM כדי לאשר לקוחות mTLS.
השירות מאמת רק לקוחות שמציגים אישורים שמנוהלים על ידי שירות רשות האישורים. עם זאת, אפשר לשלב שורש חיצוני של אמון על ידי יצירת CA משני בתוך שירות ה-CA, שמתחבר ל-CA החיצוני.
אפשר להגדיר אשכול שיסמוך על עד 10 מאגרי רשויות אישורים.