ב-Google Distributed Cloud נעשה שימוש באישורים ובמפתחות פרטיים כדי לאמת ולהצפין חיבורים בין רכיבי מערכת באשכולות משתמשים. באמצעות אישורי CA, אשכול האדמין יוצר קבוצה חדשה של רשויות אישורים (CA) לכל אשכול משתמשים, ומנפיק אישורי עלים נוספים לרכיבי המערכת. באמצעות אשכול האדמין, אפשר לנהל את ההפצה של אישורי ה-CA הציבוריים ושל זוגות המפתחות של אישורי העלה לרכיבי המערכת, כדי ליצור תקשורת מאובטחת ביניהם.
התכונה 'רוטציה של אישורי CA באשכול משתמשים' מאפשרת להפעיל רוטציה של אישורי המערכת המרכזיים באשכול משתמשים. במהלך הרוטציה, אשכול האדמין מחליף את אישורי ה-CA של מערכת הליבה באישורי CA שנוצרו לאחרונה עבור אשכול המשתמשים, ומפיץ את אישורי ה-CA הציבוריים החדשים ואת זוגות המפתחות של אישורי העלה לרכיבי המערכת של אשכול המשתמשים. הרוטציה מתבצעת באופן מצטבר, כדי שרכיבי המערכת יוכלו להמשיך לתקשר במהלך הרוטציה. עם זאת, חשוב לזכור שעומסי העבודה והצמתים מופעלים מחדש במהלך הרוטציה.
יש שלוש רשויות אישורים של המערכת שמנוהלות על ידי אשכול האדמין לכל אשכול משתמשים:
- ה-CA של etcd מאבטח את התקשורת משרת ה-API אל העותקים של etcd, וגם את התעבורה בין העותקים של etcd. ה-CA הזה הוא בחתימה עצמית.
- רשות ה-CA של האשכול מאבטחת את התקשורת בין שרת ה-API לבין כל לקוחות ה-API הפנימיים של Kubernetes (kubelet, בקרים, מתזמנים). ה-CA הזה הוא בחתימה עצמית.
- ה-CA של ה-proxy הקדמי מאבטח את התקשורת עם ממשקי API מצטברים. ה-CA הזה הוא בחתימה עצמית.
בנוסף, יכול להיות שאתם משתמשים ברשות אישורים (CA) של הארגון כדי לחתום על האישור שהוגדר באמצעות האפשרות authentication.sni.
ה-CA הזה ואישור ה-SNI משמשים להצגת ה-Kubernetes API ללקוחות מחוץ לאשכול. אתם מנהלים את ה-CA הזה ויוצרים באופן ידני את אישור ה-SNI. התכונה של רוטציה של CA באשכול משתמשים לא משפיעה על ה-CA הזה וגם לא על אישור ה-SNI.
מגבלות
שימו לב למגבלה הבאה שקיימת באשכולות מתקדמים:
- גרסה 1.31: אין תמיכה בסיבוב של רשות אישורים באשכולות מתקדמים.
- גרסה 1.32 ואילך: יש תמיכה ברוטציה של CA באשכולות מתקדמים, אבל יש כמה הבדלים קלים שמצוינים במסמך הזה במקומות הרלוונטיים.
רוטציה של אישורי CA מוגבלת לאישורי CA של etcd, של אשכול ושל front-proxy שצוינו קודם.
רוטציה של אישורי CA מוגבלת לאישורים שמונפקים באופן אוטומטי על ידי Google Distributed Cloud. הוא לא מעדכן אישורים שהונפקו ידנית על ידי אדמין, גם אם האישורים האלה נחתמו על ידי רשויות האישורים של המערכת.
רוטציה של CA מפעילה מחדש את שרת ה-API, תהליכים אחרים במישור הבקרה וכל צומת באשכול מספר פעמים. כל שלב בהחלפת אישורים של רשות אישורים מתקדם באופן דומה לשדרוג אשכול. למרות שאשכול המשתמשים נשאר פעיל במהלך רוטציה של CA, צריך לצפות לכך שעומסי העבודה יופעלו מחדש ויתוזמנו מחדש. בנוסף, אם באשכול המשתמשים שלכם אין מישור בקרה עם זמינות גבוהה, צפויים פרקי זמן קצרים של השבתה של מישור הבקרה.
אחרי רוטציה של רשות אישורים, צריך לעדכן את קובץ ה-kubeconfig של אשכול המשתמשים ואת קובצי ההגדרות של האימות. הסיבה לכך היא שהאישור הישן של האשכול בוטל, ופרטי הכניסה בקובץ kubeconfig כבר לא פועלים.
אחרי שמתחילים רוטציה של רשות אישורים, אי אפשר להשהות אותה או לבטל אותה.
החלפה של רשות אישורים עשויה להימשך זמן רב, בהתאם לגודל של אשכול המשתמשים.
ביצוע סבב של רשות האישורים
מתחילים את הסבב:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGמחליפים את מה שכתוב בשדות הבאים:
USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמשים
ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין
ההתנהגות של הפקודה משתנה בהתאם לשאלה אם האפשרות 'אשכול מתקדם' מופעלת:
מושבתת
אם לא מפעילים את האפשרות advanced cluster באשכול, הפקודה היא אסינכרונית, היא מתחילה את הרוטציה של רשות האישורים ואז יוצאת. אין צורך לצפות בפלט של הפקודה למשך כל משך הרוטציה של רשות האישורים. במקום זאת, אפשר להריץ את הפקודה gkectl update credentials certificate-authorities status כדי לבדוק מדי פעם את ההתקדמות.
אם רוטציית ה-CA מתחילה בהצלחה, מוצגת הודעה שדומה לזו:
successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
אם תהליך של החלפת CA כבר מתבצע, תוצג הודעת שגיאה דומה לזו:
Exit with error: admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads
כדי לראות את הסטטוס של הרוטציה:
gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
הפקודה הקודמת מדווחת על CAVersion, שהוא מספר שלם שהמערכת מגדילה באופן אוטומטי כדי להבדיל בין רשויות האישורים שנעשה בהן שימוש לפני ואחרי הרוטציה. הפקודה גם מדווחת על סטטוס (True או False) שמציין אם רוטציית ה-CA הושלמה, ועל הודעה שמתארת איזה CAVersion נמצא כרגע בשימוש בכל רכיב של המערכת.
אם רוטציית ה-CA כבר הושלמה, תופיע הודעה שדומה להודעה הזו:
State of CARotation with CAVersion 2 is - status: True, reason: CARotationCompleted, message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.
אם רוטציית ה-CA עדיין מתבצעת, תופיע הודעה דומה לזו:
State of CARotation with CAVersion 2 is - status: False, reason: CARotationProgressed, message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.
עדכון פרטי הכניסה של אשכול משתמשים
באשכולות שלא מופעל בהם אשכול מתקדם, צריך לקבל קובץ kubeconfig חדש של אשכול משתמשים מאשכול האדמין. הסיבה לכך היא שהחלפת רשות האישורים מבטלת את רשות האישורים שהקובץ הישן של kubeconfig התבסס עליה.
מקבלים קובץ kubeconfig חדש:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
מופעל
אם מופעלת האפשרות 'אשכול מתקדם', הפקודה gkectl update credentials
certificate-authorities rotate היא סינכרונית. הפקודה מוציאה הודעות סטטוס לתחנת העבודה של האדמין ככל שהרוטציה של רשות האישורים מתקדמת.
אחרי שהחלפת ה-CA מסתיימת בהצלחה, הפקודה יוצאת ונוצר אוטומטית קובץ kubeconfig חדש. פלט הפקודה כולל את השם של קובץ ה-kubeconfig החדש, והוא דומה לזה:
Beginning CA rotation with generated CA ... Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has been updated.
קובץ ה-kubeconfig החדש נמצא באותה ספריה שבה נמצא קובץ ה-kubeconfig של אשכול האדמין שציינתם בפקודה. השם של קובץ ה-kubeconfig החדש הוא USER_CLUSTER_NAME-kubeconfig.
הפצת קובץ ה-kubeconfig החדש
מפיצים את קובץ ה-kubeconfig החדש לכל מי שמשתמש בקובץ kubeconfig כדי ליצור אינטראקציה עם האשכול.
עדכון קובצי התצורה של האימות
אחרי שסבב ה-CA מסתיים, צריך לעדכן את קובצי הגדרות האימות ולשלוח אותם מחדש. מידע נוסף זמין במאמר בנושא ניהול זהויות משתמשים.
רוטציה של אישורים במישור הבקרה
בלי רוטציה, תוקף האישורים של רשויות האישורים של אשכול המשתמשים ושל מישור הבקרה יפוג חמש שנים מהתאריך שבו האשכול נוצר. האישורים של מישור הבקרה (control-plane) של אשכול המשתמשים עוברים רוטציה אוטומטית תוך עשר שעות משדרוג של כל אשכול משתמשים, אבל רשויות האישורים לא עוברות רוטציה אוטומטית. המשמעות היא שצריך לבצע רוטציה של אישורים לפחות פעם בחמש שנים, בנוסף לשדרוגים רגילים של הגרסה.
כדי למנוע מצב שבו אשכול משתמשים לא יהיה זמין, מתבצעת רוטציה של אישורים במישור הבקרה תוך עשר שעות אחרי שדרוג של אשכול משתמשים. במקרה כזה, הודעה מופיעה בסטטוס של רוטציית אישורי ה-CA של אשכול המשתמשים.
כדי לראות את הגרסה האחרונה שאליה שודרג אשכול משתמשים כשבוצע רוטציה של אישורים במישור הבקרה:
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
המידע מופיע בסוף השדה message תוך עשר שעות משדרוג. לדוגמה:
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
פתרון בעיות בהחלפת רשות אישורים
הפקודה gkectl diagnose תומכת בבדיקת הסטטוס הצפוי של רוטציה של רשות אישורים שהושלמה מול אשכול משתמשים. הוראות להפעלת gkectl diagnose באשכול משתמשים מפורטות במאמר אבחון בעיות באשכול.
אם נתקלים בבעיות ברוטציה של CA, פונים לתמיכה של Google ומספקים את gkectl diagnose הפלט.