רוטציה של רשויות אישורים

ב-Google Distributed Cloud נעשה שימוש באישורים ובמפתחות פרטיים כדי לאמת ולהצפין חיבורים בין רכיבי מערכת באשכולות. רשות האישורים (CA) של האשכול מנהלת את האישורים והמפתחות האלה. כשמריצים את הפקודה bmctl update credentials certificate-authorities rotate, Google Distributed Cloud מבצע את הפעולות הבאות:

• הפקודה יוצרת ומעלה רשויות אישורים (CA) חדשות של אשכולות עבור רשות ה-CA של האשכול, רשות ה-CA של etcd ורשות ה-CA של ה-proxy הקדמי למרחב השמות של אשכול המשתמשים באשכול האדמין.

• הבקרי של אשכול האדמין מחליפים את רשויות האישורים של אשכול המשתמשים באלה שנוצרו לאחרונה.

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

• הפקודה גם מעדכנת את stackdriver-prometheus-etcd-scrape Secret, שנוצר על ידי Google Distributed Cloud במהלך יצירת האשכול. ‫Prometheus צריך את הסוד הזה כדי לאסוף מדדי etcd.

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

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

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

לפני שמבצעים רוטציה של רשות האישורים (CA) של האשכול, צריך לתכנן את הפעולה בהתאם לתנאים ולהשפעות הבאים:

• לפני שמתחילים את הרוטציה של אישורי ה-CA, צריך לוודא שגרסת האשכולות של האדמינים והמשתמשים היא 1.9.0 ואילך.

• הרוטציה של אישורי ה-CA היא מצטברת, ומאפשרת לרכיבי המערכת לתקשר במהלך הרוטציה.

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

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

• במהלך רוטציה של אישורים, אי אפשר לבצע פעולות לניהול אשכולות.

• משך הרוטציה של רשות האישורים תלוי בגודל האשכול. לדוגמה, החלפה של אישורים של הרשות שמנפיקה את האישורים (CA) עשויה להימשך כמעט שעתיים באשכול עם מישור בקרה אחד ו-50 צמתי עבודה.

מגבלות

היכולת של סבב מפתחות של רשות אישורים כוללת את המגבלות הבאות:

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

• אחרי שמתחילים בהחלפת אישורים, אי אפשר להשהות אותה או לבטל אותה.

התחלת רוטציה של רשות אישורים באשכול

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

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

bmctl update credentials certificate-authorities rotate --cluster CLUSTER_NAME \
    --kubeconfig KUBECONFIG

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

• ‫CLUSTER_NAME: השם של האשכול שעבורו רוצים להחליף את רשויות האישורים.
• ‫KUBECONFIG: הנתיב לקובץ ה-kubeconfig של אשכול האדמין. במקרה של אשכולות בניהול עצמי, הקובץ הזה הוא קובץ ה-kubeconfig של האשכול.

הפקודה bmctl יוצאת אחרי שה-CA מוחלף בהצלחה ונוצר קובץ kubeconfig חדש. הנתיב הסטנדרטי לקובץ kubeconfig הוא bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

פתרון בעיות בהחלפת רשות אישורים באשכול

הפקודה bmctl update credentials מציגה את ההתקדמות של החלפת אישורי ה-CA. קובץ update-credentials.log המשויך נשמר בספרייה הבאה עם חותמת זמן:

bmctl-workspace/CLUSTER_NAME/log/update-credentials-TIMESTAMP