תכונת ה-mTLS של Apigee מוסיפה אבטחה לתקשורת בין רכיבים ב-Edge באשכול הענן הפרטי. היא מספקת דרך סטנדרטית בתחום להגדרה ולהתקנה של רשת Service mesh. הוא תומך באוטומציה של ניהול חבילות והגדרת תצורה.
סקירה כללית של הארכיטקטורה
כדי לספק תקשורת מאובטחת בין רכיבים, ב-Apigee mTLS נעשה שימוש ב-Service mesh שיוצר חיבורי TLS מאובטחים ומאומתים באופן הדדי בין רכיבים.
בתמונה הבאה מוצגים חיבורים בין רכיבי Apigee שאפשר לאבטח ב-Apigee mTLS (in red). היציאות שמוצגות בתמונה הן דוגמאות. ניתן לעיין בשימוש ביציאה לרשימת הטווחים שבהם כל רכיב יכול להשתמש.
(חשוב לשים לב שיציאות שמסומנות ב-M משמשות לניהול הרכיב וצריכות להיות פתוחות ברכיב כדי ששרת הניהול יוכל לגשת אליהן).
כפי שניתן לראות בתרשים שלמעלה, Apigee mTLS מוסיף אבטחה לחיבורים בין רוב הרכיבים באשכול, כולל:
מקור | יעד | |
---|---|---|
שרת ניהול | נתבים, MP, QPid, LDAP, Postgres, zokeeper ו-Cassandra | |
נתב | Logback, Qpid, Zookeeper ו-Cassandra | |
מעבד בקשות | Logback, Qpid, Zookeeper ו-Cassandra | |
גן חיות קנדי | צמתים נוספים של גן החיות וה-Cassandra | |
ממשק משתמש Edge | SMTP (ל-IdP חיצוני בלבד) | |
Postgres | צמתים אחרים ב-Postgres, zokeeper ו-Cassandra |
הצפנה/פענוח של הודעות
רשת השירות של Apigee mTLS מורכבת משרתי Consul שפועלים בכל צומת שלzoKeeper באשכול, ואת שירותי Consul הבאים בכל צומת באשכול:
- שרת proxy לתעבורת נתונים יוצאת, המיירט הודעות יוצאות בצומת המארח. השירות הזה מצפין הודעות יוצאות לפני שליחתן ליעדן.
- שרת proxy של תעבורת נתונים נכנסת (ingress) המיירט הודעות נכנסות בצומת המארח. השירות הזה מפענח הודעות נכנסות לפני שהן נשלחות ליעד הסופי.
לדוגמה, כששרת הניהול שולח הודעה לנתב, שירות ה-proxy לתעבורת נתונים יוצאת מיירט את ההודעה היוצאת, מצפין אותה ואז שולח אותה לנתב. כשהצומת של הנתב מקבל את ההודעה, שירות ה-proxy לתעבורת נתונים נכנסת מפענח את ההודעה ואז מעביר אותה לרכיב הנתב לעיבוד.
כל זה קורה בשקיפות לרכיבי Edge: הם לא מודעים לתהליך ההצפנה והפענוח שמבוצעים על ידי שירותי ה-proxy של Consul.
בנוסף, ב-Apigee mTLS נעשה שימוש בכלי העזר iptables
, שירות חומת אש של Linux שמנהל את ההפניה האוטומטית של תעבורת הנתונים.
דרישות
לפני שתוכל להתקין את Apigee mTLS, הסביבה שלך חייבת לעמוד בדרישות הבאות:
- דרישות לטופולוגיה
- כלי התחזוקה הותקנו והופצו
- חשבון משתמש עם רמת ההרשאות המתאימה
- מכונת ניהול (מומלץ)
- שימוש ביציאה
בחלקים הבאים מתואר בפירוט הדרישות האלה.
דרישות לטופולוגיה
כדי להשתמש ב-mTLS ב-Apigee הטופולוגיה של הסביבה חייבת לכלול לפחות שלושה צמתים של Zouter. כתוצאה מכך, אפשר להתקין את Apigee mTLS רק בטופולוגיות שמשתמשות בצמתים 5, 9, 12 (מרכז נתונים מרובים) או 13 צמתים. תוכלו לקרוא מידע נוסף במאמר טופולוגיות של התקנה.
תוכניות שירות/חבילות
לפני שמתחילים בתהליך ההתקנה, צריך להתקין ולהפעיל את החבילות הבאות ב-Apigee mTLS בכל מכונה באשכול, כולל מכונת הניהול:
כלי/חבילה | תיאור | אפשר להסיר לאחר ההתקנה? |
---|---|---|
base64 |
מאמת נתונים בתוך הסקריפטים של ההתקנה. | |
gnu-bash gnu-sed gnu-grep |
משמש את סקריפט ההתקנה וכלים נפוצים אחרים. | |
iptables |
מחליפה את חומת האש המוגדרת כברירת מחדל, firewalld . |
|
iptables-services |
מספק פונקציונליות לכלי השירות iptables . |
|
lsof |
משמש את סקריפט ההתקנה. | |
nc |
מאמת iptables מסלולים. |
|
openssl |
מחתום על אישורים באופן מקומי בתהליך האתחול הראשוני. |
במהלך ההתקנה, מתקינים גם את חבילת ה-Consul במכונת הניהול כדי ליצור פרטי כניסה ואת מפתח ההצפנה.
החבילה apigee-mtls
מתקינה ומגדירה את שרתי Consul, כולל שרתי proxy של תעבורת נתונים נכנסת (ingress) ויוצאת (egress) בצמתים שלzoKeeper באשכול.
הרשאות בחשבון משתמש
לפני ההתקנה, צריך ליצור חשבון משתמש חדש או לוודא שיש לכם גישה לחשבון עם הרשאות מורחבות.
החשבון שמפעיל את התקנת mTLS של Apigee בכל צומת באשכול צריך להיות מסוגל:
- הפעלה, עצירה, הפעלה מחדש ואתחול של רכיבי Apigee
- הגדרת כללים של חומת אש
- יצירת חשבון משתמש חדש למערכת ההפעלה/מערכת
- הפעלה, השבתה, הפעלה, עצירה ואנונימיזציה של שירותים באמצעות
systemctl
מחשב ניהול (מומלץ)
ההמלצה של Apigee היא להוסיף צומת באשכול שבו אפשר לבצע משימות ניהול שונות שמתוארות במסמך הזה, כולל:
- מתקינים את HashiCorp Consul 1.6.2.
- ליצור ולהפיץ זוג אישורים/מפתחות ומפתח להצפנת רכילות.
- מעדכנים ומפיצים את קובץ התצורה.
כשמגדירים את מכונת הניהול:
- חשוב לוודא שיש לכם גישה לרמה הבסיסית (root) שלו.
- מורידים ומתקינים במחשב את כלי השירות
apigee-service
ו-apigee-setup
, כפי שמתואר בהתקנת כלי השירות להגדרת apigee של Edge. - חשוב לוודא שאפשר להשתמש ב-
scp/ssh
כדי לגשת לכל הצמתים באשכול ממכונת הניהול. הפעולה הזו נדרשת כדי שתוכלו להפיץ את קובץ התצורה ואת פרטי הכניסה.
שימוש ביציאות והקצאה שלהן
בקטע הזה מתוארים השימוש ביציאות והקצאות היציאות כדי לתמוך בתקשורת Consul באמצעות Apigee mTLS.
שימוש ביציאות: כל הצמתים שפועלים עם apigee-mtls
כל הצמתים באשכול שמשתמשים בשירות apigee-mtls
חייבים לאפשר חיבורים משירותים ב-localhost (127.0.0.1). כך שרתי ה-proxy של Consul יוכלו לתקשר עם השירותים האחרים בזמן שהם מעבדים הודעות נכנסות ויוצאות.
שימוש ביציאות: צמתים של שרתי Consul (צמתים שמפעילים אתzoKeeper)
כדי לקבל בקשות מכל הצמתים באשכול, צריך לפתוח את רוב היציאות הבאות בצמתים של שרת ה-Consul (הצמתים שפועלים עם ZooKeeper):
צומת | יציאת שרת Consul | תיאור | פרוטוקול | מתן הרשאה ל-mtls-סוכנים חיצוניים * |
---|---|---|---|---|
שרת Consul (צמתים ב-ZooKeeper) | 8300 |
חיבור כל שרתי Consul באשכול. | הכנסה לקליק | |
8301 |
טיפול בהודעות של חברות ושידורים בתוך האשכול. | UDP/TCP | ||
8302 |
יציאת WAN שמטפלת בחברות ובשידור הודעות בהגדרה של מרכז נתונים מרובים. | UDP/TCP | ||
8500 |
טיפול בחיבורי HTTP לממשקי ה-API של שרת ה-Consul מתוך תהליכים באותו צומת.
היציאה הזו לא משמשת לתקשורת או לתיאום מרחוק. היא מאזינה רק ל-localhost. |
HTTP | ||
8502 |
טיפול בחיבורי gRPC+HTTPS לממשקי API של שרת Consul מצמתים אחרים באשכול. | gRPC+HTTPS | ||
8503 |
טיפול בחיבורי HTTPS לממשקי ה-API של שרת ה-Consul מצמתים אחרים באשכול. | HTTPS | ||
8600 |
מטפל ב-DNS של שרת ה-Consul. | UDP/TCP | ||
* ב-Apigee ההמלצה היא להגביל את הבקשות הנכנסות לחברי אשכול בלבד (כולל Cross-datastore). אפשר לעשות זאת באמצעות iptables .
|
כפי שמוצג בטבלה הזו, הצמתים שמריצים את הרכיב consul-server
(צמתים של ZooKeeper) חייבים לפתוח את היציאות 8301, 8302, 8502 ו-8503 לכל החברים באשכול שמריצים את השירות apigee-mtls
, גם דרך מרכזי הנתונים. צמתים שלא מריצים אתzoKeeper לא צריכים לפתוח את היציאות האלה.
הקצאות יציאות לכל הצמתים ב-Consul (כולל צמתים שמריצים אתzoKeeper)
כדי לתמוך בתקשורת עם Consul, צמתים שמריצים את הרכיבים הבאים של Apigee חייבים לאפשר חיבורים חיצוניים ליציאות בטווחים הבאים:
רכיב Apigee | טווח | מספר היציאות הנדרשות לכל צומת |
---|---|---|
Apigee mTLS | 10700 עד 10799 | 1 |
קסנדרה | 10100 עד 10199 | 2 |
מעבד בקשות | 10500 עד 10599 | 2 |
OpenLDAP | 10200 עד 10299 | 1 |
Postgres | 10300 עד 10399 | 3 |
QPid | 10400 עד 10499 | 2 |
נתב | 10600 עד 10699 | 2 |
ZooKeeper | 10000 עד 10099 | 3 |
Consul מקצה יציאות בצורה ליניארית פשוטה. לדוגמה, אם לאשכול יש שני צומתי Postgres, הצומת הראשון משתמש בשתי יציאות, ולכן Consul יקצה לו את היציאות 10300 ו-10301. הצומת השני משתמש גם הוא בשתי יציאות, לכן Consol מקצה את 10302 ואת 10303 לצומת הזה. הכלל הזה חל על כל סוגי הרכיבים.
כמו שאפשר לראות, מספר היציאות בפועל תלוי בטופולוגיה: אם לאשכול יש שני צומתי Postgres, צריך לפתוח ארבע יציאות (שני צמתים כפול שתי יציאות כל אחד).
שימו לב לנקודות הבאות:
- שרתי proxy של Consul לא יכולים להאזין באותן יציאות כמו שירותי Apigee.
- ב-Consul יש רק מרחב כתובות יציאה אחד. ההקצאות של יציאות שרת proxy בקונסולה צריכות להיות ייחודיות בכל האשכול, כולל מרכזי נתונים. המשמעות היא שאם שרת proxy A במארח א' מאזין ביציאה 15,000, שרת proxy ב' במארח B לא יכול להאזין ביציאה 15,000.
- מספר היציאות שנעשה בהן שימוש משתנה בהתאם לטופולוגיה, כפי שתואר קודם.
בהגדרה של מרכז נתונים מרובים, כל המארחים שמריצים mTLS צריכים לפתוח גם את היציאה 8302.
ניתן להתאים אישית את יציאות ברירת המחדל שבהן משתמש Apigee mTLS. למידע נוסף על כך, אפשר לעיין במאמר התאמה אישית של טווח יציאות ה-Proxy.
מגבלות
ב-Apigee mTLS יש את המגבלות הבאות:
- לא מצפינה את התקשורת בין הצמתים של Cassandra (יציאה 7000)
- ההגדרה וההגדרה הן לא אידמפוטנטיות. כלומר, אם מבצעים שינוי אחד בצומת אחד, צריך לבצע את אותו שינוי בכל הצמתים. המערכת לא מחילה את השינוי הזה עבורך על צמתים אחרים. למידע נוסף, ראו שינוי תצורה קיימת של apigee-mtls.
הסברים על המונחים
בקטע הזה נעשה שימוש במונחים הבאים:
מונח | הגדרה |
---|---|
cluster | קבוצת המכונות שמהן מורכב ה-Edge עבור התקנת הענן הפרטי. |
קונסול | רשת השירות שבה משתמש Apigee mTLS. במודל האבטחה של Conul אפשר לקרוא מידע נוסף על האופן שבו Consul מאבטח את התקשורת שלך בענן הפרטי. |
mTLS | TLS מאומת באופן הדדי. |
service mesh | רשת שכבת-על (או רשת בתוך רשת). |
TLS | אבטחת שכבת עסקה. פרוטוקול אימות המקובל בתחום לתקשורת מאובטחת. |