למה בחרנו להשתמש דווקא ב-Consul ו-Vault לניטור ואבטחת שירותים בתשתית?

קיימים הרבה כלים בשוק שמאפשרים ניהול סודות ו-Service Discovery, אך חשוב לדעת אילו מהם מתאימים לצורכי החברה שלכם. אז אילו שיקולים, אתגרים ויתרונות יש במעבר לעבודה בכלי ה-Open source של Hashicorp? החלק השני בסדרה

gilaxia/ Getty Images Israel

צלם/תמונה: gilaxia/ Getty Images Israel

מאת דני שמש, DevOps Engineer ב-Fyber

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

חברת Fyber, שפועלת בתחום ה-Ad Tech ומפתחת טכנולוגיות לפרסום מודעות במובייל, מתמודדת עם תשתית מורכבת במיוחד, שגם צריכה לעמוד ב-Scale גבוה מאוד. סביבה כזו טומנת אתגרים רבים לצוות ה-DevOps: מההקמה והניהול, דרך הפיתוח ומעקב אחר מערכות, האינטגרציה ועד ניהול האבטחה וההרשאות של המערכות מול הרשת והמפתחים.

בכתבה הקודמת תיארנו איך אנחנו נעזרים ב-Terraform כדי להקים את תשתיות הענן. בכתבה זו נתאר כיצד ניתן לקבל אינפורמציה לגבי השירותים בתשתית, “להכיר” שירותים מסוימים לשירותים אחרים ולייצר להם הרשאות ומנגנון אבטחה, בעזרת הכלים Consul ו-Vault, ונסביר מדוע בחרנו דווקא בהם.

Hashicorp Consul: לא רק Service Discovery

כדי לקבל תמונה מפורטת של השרתים והשירותים שלנו, הסטטוס והכתובות שלהם, אנחנו זקוקים ל-Service Discovery: תהליך אוטומטי שמנטר מכונות ושירותים על גבי המכונות. לשם כך אנחנו נעזרים ב-Consul.

Consul היא מערכת מבוזרת ו-highly available, כלומר שואפת להיות זמינה תמיד. היא מוגדרת כ”רשת שירות” (service mesh) – שכבה שתפקידה לדאוג לתקשורת בין שירותים (אפליקציות web). המערכת עובדת באופן הבא: agent של Consul מותקן בכל שרת שנרצה שיחשוף את שירותיו (services), כך שניתן לבקש מקונסול להפעיל קוד שיבדוק את תקינות השירות. ה-agent אחראי לבדוק את תקינות השירותים (Health checks) ואת תקינות השרת עצמו.

בדיקת תקינות השירות על ידי Consul בכל 10 שניות, בשרת mongoDB שהוקם עם Terraform

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

מקור: https://www.slideshare.net

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

 

רשימת שרתי MongoDB

כתובת DNS קבועה במקום כתובות IP

שרתי אפליקציה שונים מתקשרים עם שרתי MongoDB באמצעות פרוטוקול HTTP. הכתובת המעודכנת של שרתים אלה ידועה, אולם כאשר אחד מהם מוחלף גם כתובתו משתנה. כיצד ניתן לעדכן את שרתי האפליקציה בכתובת המעודכנת של שרת ה-MongoDB החדש? שימוש ב-Consul DNS יסייע בפתרון הבעיה, משום שניתן לפנות ל-Consul עם כתובת DNS בצורה הבאה:

service name>.service.<datacenter name>.consul>

במקרה המתואר: mongodb.service.fyber.consul

מתחת לכתובת קבועה זו תופיע תמיד רשימה מעודכנת של שרתי MongoDB, כך שבמקום רשימת כתובות IP סטטיות תוגדר הכתובת הזו. אם אחד משרתי MongoDB נפל, בדיקת ה-Health check שהוגדרה תמנע פניה אליו.

ל-Consul יש פיצ’רים נלווים נוספים שהופכים אותו לאטרקטיבי ושאנחנו מצאנו כמתאימים לתהליך העבודה אצלנו:

  • Multi Datacenter – בעבודה עם מספר רב של חשבונות, ה-Service discovey של Consul מנטר את השרתים השונים out of the box.
  • מסד נתונים פנימי – key/value store, מאפשר שמירת קונפיגורציות ומתממשק עם Terraform ו-Vault.
  • Consul Lock – פקודה למניעה הדדית (Mutual exclusion). מתן הרשאה לתהליך אחד (קטע קוד) בלבד להשתמש במשאב מסוים בזמן נתון.
  • Consul-template – שתילת פונקציה המתשאלת את Consul ומעדכנת את הקונפיגורציה בקובצי קונפיגורציה בצורה אוטומטית ובזמן אמת, במקרה שערך חזרת השאילתה משתנה.
  • תקשורת מאובטחת בין שירותים.
  • ספריה שמאפשרת אינטגרציה של Consul ו-Kubernete – הספרייה מאפשרת ל-Consul לנטר שירותים ב-Kubernetes ולהיפך.

פיצ׳ר נוסף: UI נוח

מדוע להשתמש ב-Consul כ-Service Discovery?

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

לכן עדיף להשתמש במוצרים ייעודיים ל-Service Discovery, דוגמת Zookeeper הוותיק והמומלץ. בהשוואה לכלים אלה, ה-Consul מצריך עקומת למידה קטנה יותר. ה-Service Discovery עצמו מובנה ב-Consul, וברוב האלטרנטיבות המשתמשים נדרשים לבנות מעליו את ה-Service Discovery שלהם.

ניהול סודות עם Hashicorp Vault

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

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

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

אז איך נראה המצב האידיאלי?

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

Vault הוא כלי לניהול מאובטח של סודות, Highly available. באמצעות ממשק (API) זהה, ניתן ליצור הרשאות לכל ספק פופולרי (או Secret Engine בשפת Vault, דוגמת ענן, מסד נתונים וכיוצא בזה) ולנהל אותן. בנוסף, הוא תומך בכל פונקציות האימות (Authentication methods), הנפוצות, כך שניתן למשל להתחבר אליו באמצעות Token שמופק מחשבון Github או באמצעות AWS Role.

מקור התמונה www.hashicorp.com

כך, יצירת פרטי משתמש ב-AWS, MySQL או MongoDB תיעשה באמצעות אותו API עם פרמטרים שונים. Vault עובד בשיטת Role Based Policies, בה מגדירים לכל משתמש רק את ההרשאות הרלוונטיות וכן ניתן לשמור כל סיסמה או סוד אחר בצורה מאובטחת (ממש כמו ב-Lastpass ודומיו).

Policy ב-Vault

Vault שומר את המידע שברשותו בצורה מוצפנת לפי בחירה (למשל בזיכרון, ב-Mysql ,Consul KV store ועוד).

פרטי משתמש בצורה מוצפנת ב Consul KV

לכל הרשאה שנוצרת באמצעות Vault יש ID שנשמר לזמן מסוים (וניתן להארכה בכל שלב), ובתום הזמן המוקצב ההרשאה נמחקת. הפעולות מתבצעות באמצעות בקשות HTTP לשרת Vault או ישירות בשרת עצמו באמצעות Vault CLI. ניתן לצפות ולבצע גם באמצעות ממשק ה-UI הנוח שמגיע עימו.

מסך אינפורציה של הרשאה בממשק ה-UI

איך זה עובד אצלנו?

זרימת ניהול הסודות שלנו היא כזו:

– משתמש שמוגדר כ-Root יוצר Policies (שמגדירים מה אפשר לבצע מול Vault), ו-Roles (מה שהמשתמשים ש-Vault יוצר יכולים לעשות מול הספקים) ופרטי משתמש עבור משתמשים אנושיים.

– השירותים עצמם מזדהים בפני Vault, בדרך כלל באמצעות פונקציית אימות (i.e. AWS role) בזמן ריצה, יוצרים לעצמם משתמשים זמניים ומחדשים את התוקף שלהם כל עוד שהם עצמם רלוונטיים.

– Vault מבצע עבורם את הפעולות שתוארו ומשמיד את המשתמש שהם יצרו כשתוקפו נגמר. המידע נשמר במקום שהוגדר כשהוא מוצפן (Consul KV).

– משתמשים יכולים לשמור סודות שלהם כך שיהיו חשופים להם בלבד.

תרשים זרימת ניהול הסודות ב-Fyber

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

הכתבה הראשונה בסדרה:

למה בחרנו לנהל תשתית כקוד דווקא עם Hashicorp?

הכתבה בחסות Fyber

חברת Fyber הינה חברת Advertising Technology בינלאומית, עם מעל 300 עובדים בכל העולם, מייצרת פתרונות טכנולוגיים אשר מאפשרים למפתחי אפליקציות להציע תוכן חינמי באמצעות פרסומות, תוך כדי שימור חוויית המשתמש.
לבלוג הטכנולוגי של חברת Fyber - לחצו כאן.
למשרות הפתוחות חברת Fyber - לחצו כאן.

כתב אורח

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

הגב

1 תגובה על "למה בחרנו להשתמש דווקא ב-Consul ו-Vault לניטור ואבטחת שירותים בתשתית?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
Dani Shemesh
Member

פרטים יותר טכניים על איך אנחנו מסכרנים את Consul עם Kubernetes כאן
https://fullgc.github.io/syncing-kubernetes-and-hashicorp-consul/

wpDiscuz

תגיות לכתבה: