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

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

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

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

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

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

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

שליחת בקשה לתפקידים ב-IAM

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

הכנת הסביבה

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

• מתקינים את kubectl CLI.

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

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

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

כדי ליצור רשות CA משנה מנוהלת, צריך להחיל משאב מותאם אישית על מופע של 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	השם של רשות האישורים (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. מאמתים את המוּכנוּת (readiness) של רשות המשנה לאישור (Sub CA). נדרשות כ-40 דקות עד שהרשות המנפיקה מוכנה:

   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	השם של רשות המשנה לאישור (subCA).
   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 נוצרת בשרת GDC Management API. צריך להוריד את ה-CSR ולחתום עליו. אחרי החתימה, אפשר להעלות את האישור החתום לשרת GDC Management API.

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 חתום על ידי רשות אישורי הבסיס של הלקוח. מאחסנים את האישור בקובץ 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. מאמתים את המוּכנוּת של תת-רשות אישורים (Sub CA) מסוג 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 שמופרד מרשת האינטרנט:

משתמשים בפרמטר 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