שימוש ברשויות אישורים מותאמות אישית של אשכולות

רשויות אישורים (CA) של אשכולות מנפיקות וחותמות על אישורים כדי לאפשר אימות והצפנה מאובטחים בין רכיבי האשכול. כברירת מחדל, ב-Google Distributed Cloud, ‏ Cluster API יוצר את רשויות האישורים של האשכול כשיוצרים אשכול חדש. במאמר הזה מוסבר איך להשתמש ברשויות אישורים משלכם עם Google Distributed Cloud. שימוש ברשויות אישורים מותאמות אישית של אשכולות מאפשר לכם לקבל שליטה רבה יותר בהנפקה ובניהול של אישורי האשכולות. אפשר גם לשלוט באמינות, בפרמטרים של אלגוריתם ההצפנה, בעומק של אישורי משנה ובמטרה שלהם.

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

• ‫etcd CA: אישור ה-CA של etcd מאבטח את התקשורת משרת ה-API של Kubernetes אל הרפליקות של etcd, וגם את התקשורת בין הרפליקות של etcd.

• CA של האשכול: האישור של ה-CA של האשכול מאבטח את התקשורת בין שרת ה-API של Kubernetes לבין כל לקוחות ה-API הפנימיים של Kubernetes. הלקוחות כוללים את kubelet, את controller manager ואת scheduler.

• CA של שרת proxy קדמי: האישור של CA של שרת proxy קדמי מאבטח את התקשורת עם ממשקי API מצטברים.

אפשר לספק זוג ייחודי של אישור ומפתח לכל CA, או להשתמש מחדש בזוג של אישור ומפתח לכמה CA.

מחילים את זוגות המפתחות של האישורים במהלך יצירת אשכול (שיטה bmctl בלבד) והחלפת רשות האישורים. התכונה 'CA של אשכול בהתאמה אישית' פועלת עם כל סוגי האשכולות: אדמין, משתמש, היברידי ועצמאי.

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

דרישות מוקדמות

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

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

• לגבי האישור, מומלץ להשתמש בפורמט Distinguished Encoding Rules‏ (DER) (ראו המלצה X.690 לגבי כללי קידוד של ASN.1). קובץ האישור צריך להכיל נתונים בקידוד Base64, שמופיעים אחרי התו ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ ולפני התו ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

• למפתח הפרטי, מומלץ להשתמש בפורמט Public-Key Cryptography Standards (PKCS) #1. קובץ המפתח צריך להכיל נתונים בקידוד Base64, שלפניהם התו ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ ואחריהם התו ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

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

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

• למשתמש שמריץ פקודות bmctl צריכה להיות גישה לספרייה שבה מאחסנים את הקבצים. מומלץ להציב את הקבצים בספרייה קיימת שמשמשת לאישור ולמפתחות. לדוגמה, אפשר לאחסן את הקבצים ב-~/baremetal/bmctl-workspace/.sa-keys יחד עם המפתחות של חשבון השירות.

• למשתמש שמריץ פקודות bmctl צריכה להיות גישת קריאה לקבצים.

שימוש ב-CA מותאם אישית במהלך יצירת האשכול

כשיוצרים אשכול באמצעות bmctl, קודם מעדכנים את קובץ התצורה של האשכול כדי לתאר את התכונות וההגדרות של האשכול. כדי להשתמש בתכונה 'רשויות CA מותאמות אישית של אשכולות' במהלך יצירת האשכול, יש שתי אפשרויות לציין את רשויות ה-CA המותאמות אישית של האשכול בקובץ ההגדרות של האשכול:

• מציינים את הנתיבים של קובצי אישור ה-CA ושל קובצי המפתח הפרטי.
• מציינים רק את הנתיבים לקובצי המפתח הפרטי

כשמציינים רק את המפתחות הפרטיים, bmctl מחפש את קובצי האישורים המתאימים של רשות האישורים באותה ספרייה. שמות הקבצים של האישורים צריכים להיות זהים לשמות הקבצים של המפתחות הפרטיים התואמים, והם צריכים לכלול את סיומת הקובץ .crt. לדוגמה, אם הנתיב של המפתח הפרטי הוא /custom-ca/cluster_ca.key, אז bmctl מצפה שהנתיב של האישור יהיה /custom-ca/cluster_ca.crt.

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

דוגמה 1: ציון נתיבי אישורים ומפתחות

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

הערה: באשכול משתמשים, מסירים את הנתיבים של חשבון השירות ומפתח ה-SSH מהקטע credentials.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

דוגמה 2: ציון נתיבים של מפתחות פרטיים בלבד

הקטע הבא מקובץ תצורה של אשכול מראה איך לציין רק את הנתיבים לקובצי המפתח. בדוגמה הזו, קובצי המפתח הפרטי של CA נמצאים באותה ספרייה כמו קובצי מפתח ה-JSON של חשבון השירות. קובצי אישור ה-CA המתאימים צריכים להיות גם בתיקייה /.sa-keys. שמות הקבצים של האישורים זהים לשמות הקבצים של המפתחות, אבל עם הסיומת .crt. לכן, קובץ אישור ה-CA של etcd נקרא etcd_ca.crt.

הערה: באשכול משתמשים, מסירים את הנתיבים של חשבון השירות ומפתח ה-SSH מהקטע credentials.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

דוגמה 3: שימוש חוזר בצמד יחיד של קובצי מפתח ואישור CA

הקטע הבא מקובץ הגדרות של אשכול מראה איך מציינים רק את הנתיבים לקובצי המפתח. בדוגמה הזו, נעשה שימוש בזוג מפתחות אישור יחיד לכל רשויות האישורים של האשכול. קובץ אישור ה-CA וקובץ המפתח הפרטי נמצאים שניהם בספרייה /custom-ca. בהתאם למוסכמת השמות, שם הקובץ של אישור ה-CA הוא custom_ca.crt.

הערה: באשכול משתמשים, מסירים את הנתיבים של חשבון השירות ומפתח ה-SSH מהקטע credentials.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

שימוש ב-CA מותאם אישית במהלך החלפת CA

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

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

דוגמה 1: ציון נתיבים של אישור CA ומפתח פרטי

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

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

• ‫CLUSTER_NAME: השם של האשכול שעבורו רוצים להחליף את רשויות האישורים.
• ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין. במקרה של אשכולות בניהול עצמי, הקובץ הזה הוא קובץ ה-kubeconfig של האשכול.
• ‫CLUSTER_CA_CERT_PATH: הנתיב של קובץ האישור של רשות האישורים של האשכול.
• ‫CLUSTER_CA_KEY_PATH: הנתיב לקובץ המפתח הפרטי של רשות האישורים של האשכול.
• ‫ETCD_CA_CERT_PATH: הנתיב של קובץ אישור ה-CA של etcd.
• ‫ETCD_CA_KEY_PATH: הנתיב לקובץ של המפתח הפרטי של רשות האישורים (CA) של etcd.
• ‫FRONT_PROXY_CA_CERT_PATH: הנתיב של קובץ האישור של ה-front-proxy.
• ‫FRONT_PROXY_CA_KEY_PATH: הנתיב של קובץ המפתח הפרטי של ה-front-proxy.

דוגמה 2: ציון נתיבים של מפתחות פרטיים בלבד

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

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

• ‫CLUSTER_NAME: השם של האשכול שעבורו רוצים להחליף את רשויות האישורים.
• ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין. במקרה של אשכולות בניהול עצמי, הקובץ הזה הוא קובץ ה-kubeconfig של האשכול.
• ‫CLUSTER_CA_KEY_PATH: הנתיב לקובץ המפתח הפרטי של רשות האישורים של האשכול.
• ‫ETCD_CA_KEY_PATH: הנתיב לקובץ של המפתח הפרטי של רשות האישורים (CA) של etcd.
• ‫FRONT_PROXY_CA_KEY_PATH: הנתיב של קובץ המפתח הפרטי של ה-front-proxy.

רשויות אישורים (CA) ביניים

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

גרסה 1.29 של אשכולות תומכת בשימוש ב-CA ביניים כתכונת Preview. התכונה הזו לא נמצאת באותו שלב השקה בכל גרסאות המוצר הנתמכות:

• ‫1.29: תצוגה מקדימה
• ‫1.28: לא זמין
• ‫1.16: לא זמין

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

• etcd CA
• רשות אישורים של אשכול
• רשות אישורים של שרת proxy קדמי

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

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

בדוגמה הבאה (מתחילים עם רשות האישורים הבסיסית בתחתית), הסדר מציין את הדברים הבאים:

• רשות האישורים (CA) הבסיסית חתמה על אישור רשות האישורים (CA) ברמת ביניים A
• רשות אישורים ברמת ביניים (Intermediate-A) חתמה על אישור CA ברמת ביניים (Intermediate-B)
• השרשרת ממשיכה עד לאישור ה-CA הסופי Intermediate-Y, שנחתם על ידי ה-CA‏ Intermediate-X

-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE----- 

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

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

כדי לבדוק אם האשכול משתמש ב-CA ביניים, בודקים את מספר האישורים בסוד ה-CA של האשכול:

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l