יצירת רשות אישורים משנית

במאמר הזה מוסבר איך ליצור רשות אישורים משנית (Sub CA).

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

הגורם שחותם על אישור ה-CA יכול להיות רשות אישורים אחרת שנוצרה ב-CA Service, למשל רשות אישורים ברמה הבסיסית, או רשות אישורים חיצונית. עם רשויות אישורים חיצוניות, שירות CA יוצר בקשה לחתימה על אישור (CSR) שרשות האישורים החיצונית צריכה לחתום עליה.

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

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

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

בקשת תפקידים ב-IAM

כדי ליצור, לעדכן ולמחוק משאבים של רשות אישורים, צריך לבקש ממנהל חשבון ארגוני ב-IAM את התפקיד Certificate Authority Service Admin (certificate-authority-service-admin) במרחב השמות של הפרויקט של רשות האישורים.

הכנת הסביבה

• אם עדיין לא עשיתם את זה, מורידים ומתקינים את ה-gdcloud CLI.

• מתקינים את ה-CLI של kubectl.

• יוצרים קובץ kubeconfig כדי להגדיר את הגישה ל-kubectl.

יצירת רשות אישורים משנית מנוהלת

ב-Sub CA מנוהל, החותם על אישור ה-CA הוא CA אחר (root CA) שנוצר ב-CA Service.

כדי ליצור רשות אישורים משנית מנוהלת, צריך להחיל משאב בהתאמה אישית על המכונה של Distributed Cloud Appliance.

1. יוצרים משאב CertificateAuthority ושומרים אותו כקובץ YAML בשם subca.yaml:

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateAuthority
   metadata:
     Name: SUB_CA_NAME
     namespace: USER_PROJECT_NAMESPACE
   spec:
     caProfile:
       commonName: COMMON_NAME
       duration: DURATION
       renewBefore: RENEW_BEFORE
       organizations:
       - ORGANIZATIONS
       organizationalUnits:
       - ORGANIZATIONAL_UNITS
       countries:
       - COUNTRIES
       localities:
       - LOCALITIES
       provinces:
       - PROVINCES
       streetAddresses:
       - STREET_ADDRESSES
       postalCodes:
       - POSTAL_CODES
     caCertificate:
       managedSubCA:
         certificateAuthorityRef:
           name: ROOT_CA_NAME
           namespace: USER_PROJECT_NAMESPACE
     certificateProfile:
       keyUsage:
         - digitalSignature
         - keyCertSign
         - crlSign
       extendedKeyUsage:
         - EXTENDED_KEY_USAGE
     secretConfig:
       secretName: SECRET_NAME
       privateKeyConfig:
         algorithm: KEY_ALGORITHM
         size: KEY_SIZE
     acme:
       enabled: ACME_ENABLED
   

   מחליפים את המשתנים הבאים:

   משתנה	תיאור
   SUB_CA_NAME	השם של רשות האישורים המשנית.
   USER_PROJECT_NAMESPACE	השם של מרחב השמות שבו נמצא פרויקט המשתמש.
   COMMON_NAME	השם המוכר של אישור ה-CA.
   DURATION	משך החיים המבוקש של אישור ה-CA. צריך לציין את משך הזמן בשעות (לדוגמה, 1000h). אין תמיכה ביחידות כמו ימים (d) או שנים (y).
   ROOT_CA_NAME	השם של רשות האישורים ברמה הבסיסית (root CA).
   SECRET_NAME	השם של הסוד ב-Kubernetes שמכיל את המפתח הפרטי ואת אישור ה-CA החתום.

   המשתנים הבאים הם ערכים אופציונליים:

   משתנה	תיאור
   RENEW_BEFORE	זמן הסבב לפני שפג התוקף של אישור ה-CA.
   ORGANIZATIONS	הארגונים שבהם ייעשה שימוש באישור.
   ORGANIZATIONAL_UNITS	היחידות הארגוניות שבהן ייעשה שימוש באישור.
   COUNTRIES	המדינות שיופיעו באישור.
   LOCALITIES	הערים שיופיעו באישור.
   PROVINCES	המדינה (State) או המחוז שיופיעו באישור.
   STREET_ADDRESSES	כתובות הרחוב שיופיעו באישור.
   POSTAL_CODES	המיקודים שיופיעו באישור.
   EXTENDED_KEY_USAGE	השימוש המורחב במפתח של האישור. אם מציינים את המאפיין, הערכים המותרים הם serverAuth ו-clientAuth.
   KEY_ALGORITHYM	אלגוריתם המפתח הפרטי שמשמש לאישור הזה. הערכים המותרים הם RSA,‏ Ed25519 או ECDSA. אם לא מציינים את הגודל, ברירת המחדל היא 256 ל-ECDSA ו-2048 ל-RSA. גודל המפתח לא רלוונטי ל-Ed25519.
   KEY_SIZE	גודל המפתח הפרטי של האישור הזה, בביטים, תלוי באלגוריתם. ב-RSA אפשר להשתמש ב-2048, 3072, 4096 או 8192 (ברירת המחדל היא 2048). ‫ECDSA מאפשר 256, 384 או 521 (ברירת המחדל היא 256). ב-Ed25519 המערכת מתעלמת מהגודל.
   ACME_ENABLED	אם הערך הוא true, רשות האישורים פועלת במצב ACME ומוציאה את כתובת ה-URL של שרת ACME. לאחר מכן תוכלו להשתמש בלקוח ובפרוטוקול של ACME כדי לנהל את האישורים.

2. מחילים את המשאב בהתאמה אישית על המכונה של Distributed Cloud:

   kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
   

   מחליפים את MANAGEMENT_API_SERVER_KUBECONFIG בנתיב לקובץ kubeconfig של שרת Management API.

3. מוודאים שהרשות המשנית לאישורים מוכנה. לוקח כ-40 דקות עד שה-CA מוכן:

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' 
   .status.conditions[] | select( .type as $id | "Ready" | index($id))'
   

   הפלט אמור להיראות כך:

   {
     "lastTransitionTime": "2025-01-24T17:09:29Z",
     "message": "CA reconciled",
     "observedGeneration": 2,
     "reason": "Ready",
     "status": "True",
     "type": "Ready"
   }
   

יצירת רשות אישורים משנית מרשות אישורים חיצונית

רשות האישורים המשנית הזו תומכת בחתימה על אישורי קצה באמצעות רשויות אישורים חיצוניות או כאלה שמנוהלות על ידי המשתמשים. הוא יוצר CSR שהמשתמשים יכולים לחתום עליו.

1. יוצרים משאב CertificateAuthority ושומרים אותו כקובץ YAML בשם subca-external.yaml:

   apiVersion: pki.security.gdc.goog/v1
   kind: CertificateAuthority
   metadata:
     Name: SUB_CA_NAME
     namespace: USER_PROJECT_NAMESPACE
   spec:
     caProfile:
       commonName: COMMON_NAME
       duration: DURATION
       renewBefore: RENEW_BEFORE
       organizations:
       - ORGANIZATION
       organizationalUnits:
       - ORGANIZATIONAL_UNITS
       countries:
       - COUNTRIES
       localities:
       - LOCALITIES
       provinces:
       - PROVINCES
       streetAddresses:
       - STREET_ADDRESSES
       postalCodes:
       - POSTAL_CODES
     caCertificate:
       externalCA: {}
     certificateProfile:
       keyUsage:
         - digitalSignature
         - keyCertSign
         - crlSign
       extendedKeyUsage:
         - EXTENDED_KEY_USAGE
     secretConfig:
       secretName: SECRET_NAME
       privateKeyConfig:
         algorithm: KEY_ALGORITHM
         size: KEY_SIZE
     acme:
       enabled: ACME_ENABLED
   

   מחליפים את המשתנים הבאים:

   משתנה	תיאור
   SUB_CA_NAME	השם של רשות האישורים המשנית.
   USER_PROJECT_NAMESPACE	מזהה הפרויקט שאליו רוצים לייבא את קובץ האימג'.
   COMMON_NAME	השם המוכר של אישור ה-CA.
   DURATION	משך החיים המבוקש של אישור ה-CA. צריך לציין את משך הזמן בשעות (לדוגמה, 1000h). אין תמיכה ביחידות כמו ימים (d) או שנים (y).
   SECRET_NAME	השם של הסוד ב-Kubernetes שמכיל את המפתח הפרטי ואת אישור ה-CA החתום.

   המשתנים הבאים הם ערכים אופציונליים:

   משתנה	תיאור
   RENEW_BEFORE	זמן הסבב לפני שפג התוקף של אישור ה-CA.
   ORGANIZATION	הארגון שיופיע באישור.
   ORGANIZATIONAL_UNITS	היחידות הארגוניות שבהן ייעשה שימוש באישור.
   COUNTRIES	המדינות שיופיעו באישור.
   LOCALITIES	הערים שיופיעו באישור.
   PROVINCES	המדינה (State) או המחוז שיופיעו באישור.
   STREET_ADDRESSES	כתובות הרחוב שיופיעו באישור.
   POSTAL_CODES	המיקודים שיופיעו באישור.
   EXTENDED_KEY_USAGE	השימוש המורחב במפתח של האישור. אם מציינים את המאפיין, הערכים המותרים הם serverAuth ו-clientAuth.
   KEY_ALGORITHYM	אלגוריתם המפתח הפרטי שמשמש לאישור הזה. הערכים המותרים הם RSA,‏ Ed25519 או ECDSA. אם לא מציינים את הגודל, ברירת המחדל היא 256 ל-ECDSA ו-2048 ל-RSA. המערכת מתעלמת מגודל המקש ב-Ed25519.
   KEY_SIZE	גודל המפתח הפרטי של האישור הזה, בביטים, תלוי באלגוריתם. RSA מאפשר 2048, 3072, 4096 או 8192 (ברירת המחדל היא 2048). ECDSA מאפשר 256, 384 או 521 (ברירת המחדל היא 256). Ed25519 מתעלם מהגודל.
   ACME_ENABLED	אם הערך הוא true, רשות האישורים פועלת במצב ACME ומוציאה את כתובת ה-URL של שרת ACME. לאחר מכן תוכלו להשתמש בלקוח ובפרוטוקול של ACME כדי לנהל את האישורים.

2. מחילים את המשאב בהתאמה אישית על המכונה של Distributed Cloud:

   kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
   

3. בקשת חתימה על אישור (CSR) ל-Sub-CA נוצרת בשרת Management API של GDC. צריך להוריד את ה-CSR ולחתום עליו. אחרי החתימה, אתם יכולים להעלות את האישור החתום לשרת של Management API ב-GDC.

4. אוספים את בקשות החתימה על אישורים (CSR) מהסביבה של Distributed Cloud:

   kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
   

   הפקודה יוצרת קובץ CSR בשם sub_ca.csr בספרייה הנוכחית. הקובץ הזה מכיל בקשת חתימה על אישור (CSR) לאישור CA של X.509.

5. משתמשים ברשות האישורים (CA) הבסיסית של הלקוח כדי לבקש אישורי CA חתומים לקובץ sub_ca.csr.

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

7. אם רלוונטי, מקבלים את אישור ה-CA הבסיסי של הלקוח ושומרים אותו בקובץ ca.crt בספרייה הנוכחית.

8. מאמתים את השם הנפוץ (CN) של אישור ה-CA:

   openssl x509 -noout -subject -in sub_ca.crt
   

   אם ההגדרה שלכם דורשת תוספי שם חלופי של בעלים (SAN), צריך לאמת את תוספי ה-SAN באישור:

   openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
   

9. יוצרים את spec כדי לתקן את המשאב CertificateAuthority:

   echo "spec:
     caCertificate:
       externalCA:
         signedCertificate:
           certificate: $(base64 -w0 SUB_CA_NAME.crt)
           ca: $(base64 -w0 ca.crt)" > patch.txt
   

   התוכן בקובץ patch.txt נראה כך:

   spec:
     caCertificate:
       externalCA:
         signedCertificate:
           certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ…
           ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…
   

10. עורכים את השדה spec של המשאב CertificateAuthority:

    kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'
    

11. מוודאים שהרשות המשנית לאישורים (BYO) מוכנה. בדרך כלל לוקח כ-40 דקות עד שה-CA מוכן:

    kubectl -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
    

    הפלט אמור להיראות כך:

    {
      "lastTransitionTime": "2024-04-30T22:10:50Z",
      "message": "Certificate authority is ready for use",
      "observedGeneration": 3,
      "reason": "Ready",
      "status": "True",
      "type": "Ready"
    }
    

12. בודקים את תאריך התפוגה של אישורי ה-CA החתומים:

    kubectl -n USER_PROJECT_NAMESPACE get secret SECRET_NAME -ojson | jq -j '"echo ", .metadata.name, " $(echo ", .data["tls.crt"], "| base64 -d | openssl x509 -enddate -noout)\n"' | bash
    

הצגת רשימה של רשויות CA

כדי להציג את כל המשאבים של Certificate Authority Service במכונה של Distributed Cloud עם air gap:

משתמשים בפרמטר certificateauthorities כדי להציג את כל המשאבים של CertificateAuthority:

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities

הפלט אמור להיראות כך:

   NAMESPACE    NAME              READY   REASON   AGE
   foo          root-ca           True    Ready    7h24m
   foo          sub-ca            True    Ready    7h24m