ב-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 של etcd, של האשכול ושל front-proxy שצוינו קודם.
רוטציה של אישורי CA מוגבלת לאישורים שמונפקים באופן אוטומטי על ידי Google Distributed Cloud. הוא לא מעדכן אישורים שהונפקו באופן ידני על ידי אדמין, גם אם האישורים האלה נחתמו על ידי רשויות האישורים של המערכת.
רוטציה של CA מפעילה מחדש את שרת ה-API, תהליכים אחרים במישור הבקרה וכל צומת באשכול כמה פעמים. כל שלב בהחלפת אישורים מתקדם באופן דומה לשדרוג אשכול. אף על פי שאשכול המשתמשים נשאר פעיל במהלך רוטציה של CA, צריך לצפות לכך שעומסי העבודה יופעלו מחדש ויתוזמנו מחדש. בנוסף, אם באשכול המשתמשים שלכם אין מישור בקרה עם זמינות גבוהה, צפויים פרקי זמן קצרים של השבתה של מישור הבקרה.
אחרי רוטציה של CA, צריך לעדכן את קובץ ה-kubeconfig של אשכול המשתמשים ואת קובצי ההגדרות של האימות. הסיבה לכך היא שהאישור הישן של האשכול בוטל, ופרטי הכניסה בקובץ kubeconfig כבר לא פועלים.
אחרי שמתחילים החלפה של רשות אישורים, אי אפשר להשהות או לבטל אותה.
החלפה של הרשות שמנפיקה את האישורים (CA) עשויה להימשך זמן רב, בהתאם לגודל של אשכול המשתמשים.
ביצוע סבב של רשות האישורים
מתחילים את הסבב:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGמחליפים את מה שכתוב בשדות הבאים:
USER_CLUSTER_CONFIG: הנתיב של קובץ התצורה של אשכול המשתמשים
ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ ה-kubeconfig של אשכול האדמין
ההתנהגות של הפקודה משתנה בהתאם לשאלה אם האפשרות 'אשכול מתקדם' מופעלת:
מושבתת
אם לא מפעילים את האפשרות 'אשכול מתקדם' באשכול, הפקודה היא אסינכרונית, היא מתחילה את החלפת אישורי ה-CA ואז יוצאת. אין צורך לצפות בפלט של הפקודה למשך כל משך הרוטציה של הרשות שמנפיקה את האישורים (CA). במקום זאת, אפשר להריץ את הפקודה gkectl update credentials certificate-authorities status כדי לבדוק מדי פעם את ההתקדמות.
אם רוטציית רשות האישורים מתחילה בהצלחה, מוצגת הודעה שדומה לזו:
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 מסתיים, צריך לעדכן את קובצי הגדרות האימות ולשלוח אותם מחדש. מידע נוסף זמין במאמר בנושא ניהול זהויות משתמשים.
רוטציה של אישורים במישור הבקרה
בלי רוטציה, גם תעודות ה-CA של אשכול המשתמשים וגם התעודות של מישור הבקרה יפוגו חמש שנים אחרי התאריך שבו האשכול נוצר. האישורים של מישור הבקרה של אשכול המשתמשים עוברים רוטציה אוטומטית תוך עשר שעות משדרוג אשכול המשתמשים, אבל רשויות האישורים לא עוברות רוטציה אוטומטית. המשמעות היא שצריך לבצע רוטציה של הרשות שמנפיקה את האישורים (CA) לפחות פעם בחמש שנים, בנוסף לשדרוגים רגילים של הגרסה.
כדי למנוע מצב שבו אשכול משתמשים לא יהיה זמין, מתבצעת רוטציה של אישורים במישור הבקרה תוך עשר שעות אחרי שדרוג של אשכול משתמשים. במקרה כזה, מופיעה הודעה בסטטוס של רוטציית אישורי ה-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 הפלט.