cert-manager 1.0 יצא לאור

אם תשאלו מהנדס מנוסה וחכם מה הוא חושב על cert-manager ולמה כולם משתמשים בזה, אז המומחה יאנח, יחבק אותו בביטחון ויגיד בעייפות: "כולם משתמשים בזה, כי אין חלופות שפויות. העכברים שלנו בוכים, דוקרים, אבל ממשיכים לחיות עם הקקטוס הזה. למה אנחנו אוהבים? כי זה עובד. למה אנחנו לא אוהבים? כי כל הזמן יוצאות גרסאות חדשות המשתמשות בתכונות חדשות. ואתה צריך לעדכן את האשכול שוב ושוב. והגרסאות הישנות מפסיקות לעבוד, כי יש קונספירציה ושמאניזם מסתורי גדול.

אבל המפתחים טוענים זאת cert-manager 1.0 הכל ישתנה.

האם נאמין?

Cert-manager הוא בקר ניהול האישורים המקורי של Kubernetes. ניתן להשתמש בו להנפקת אישורים ממקורות שונים: Let's Encrypt, HashiCorp Vault, Venafi, חתימה וצמדי מפתחות בחתימה עצמית. זה גם מאפשר לך לשמור מפתחות מעודכנים לפי תאריך תפוגה, וגם מנסה לחדש אוטומטית אישורים בזמן מוגדר לפני שהם יפוג. Cert-manager מבוסס על kube-lego והשתמש גם בכמה טריקים מפרויקטים דומים אחרים כמו kube-cert-manager.

מכתבי שחרור

עם גרסה 1.0, אנו שמים אות אמון לשלוש שנים של פיתוח של פרויקט ה-cert-manager. במהלך תקופה זו, הוא התפתח באופן משמעותי בפונקציונליות וביציבות, אבל יותר מכל בקהילה. כיום, אנו רואים אנשים רבים משתמשים בו כדי לאבטח את אשכולות ה-Kubernetes שלהם, כמו גם לפרוס אותו לחלקים שונים של המערכת האקולוגית. הרבה באגים תוקנו ב-16 המהדורות האחרונות. ומה שהיה צריך להישבר שבור. מספר ביקורים לעבודה עם ה-API שיפרו את האינטראקציה שלו עם המשתמשים. פתרנו 1500 בעיות ב-GitHub עם עוד בקשות משיכה מ-253 חברי קהילה.

עם שחרורו של 1.0, אנו מכריזים רשמית ש-cert-manager הוא פרויקט בוגר. אנו גם מבטיחים לשמור על תואם ה-API שלנו v1.

תודה רבה לכל מי שעזר לנו להפוך למנהל תעודות כל שלוש השנים האלה! תן לגרסה 1.0 להיות הראשונה מבין הרבה דברים גדולים שיגיעו.

מהדורה 1.0 היא מהדורה יציבה עם מספר תחומי עדיפות:

• v1 API;

• קבוצה kubectl cert-manager status, כדי לעזור בניתוח בעיות;

• שימוש בממשקי ה-API העדכניים ביותר של Kubernetes;

• רישום משופר;

• שיפורים ב-ACME.

הקפד לקרוא את הערות השדרוג לפני השדרוג.

API v1

גרסה v0.16 עבדה עם ה-API v1beta1. זה הוסיף כמה שינויים מבניים וגם שיפר את תיעוד שדה ה-API. גרסה 1.0 מבוססת על זה עם API v1. ה-API הזה הוא ה-API היציב הראשון שלנו, במקביל כבר נתנו הבטחות תאימות, אבל עם ה-API v1 אנו מבטיחים לשמור על תאימות במשך שנים רבות.

שינויים שבוצעו (הערה: כלי ההמרה שלנו דואגים לך להכל):

תְעוּדָה:

• emailSANs עכשיו נקרא emailAddresses

• uriSANs - uris

שינויים אלה מוסיפים תאימות ל-SANs אחרים (שמות חלופיים בנושא, משוער. מְתוּרגְמָן), כמו גם עם ממשק ה-API של Go. אנו מסירים את המונח הזה מה-API שלנו.

לעדכן

אם אתה משתמש ב-Kubernetes 1.16+, המרת webhooks תאפשר לך לעבוד בו-זמנית וחלקה עם גרסאות API v1alpha2, v1alpha3, v1beta1 и v1. בעזרת אלה, תוכל להשתמש בגרסה החדשה של ה-API מבלי לשנות או לפרוס מחדש את המשאבים הישנים שלך. אנו ממליצים בחום לשדרג את המניפסטים שלך ל-API v1, שכן גרסאות קודמות יופסקו בקרוב. משתמשים legacy לגרסאות של cert-manager עדיין תהיה רק ​​גישה v1, ניתן למצוא שלבי שדרוג כאן.

פקודת סטטוס kubectl cert-manager

עם שיפורים חדשים בהרחבה שלנו ל kubectl נעשה קל יותר לחקור את הבעיות הקשורות לאי הנפקת תעודות. kubectl cert-manager status כעת נותן הרבה יותר מידע על מה שקורה עם התעודות וגם מציג את שלב הנפקת התעודה.

לאחר התקנת התוסף, תוכל להפעיל kubectl cert-manager status certificate <имя-сертификата>, אשר יחפש את האישור עם השם הנתון וכל משאבים קשורים כגון CertificateRequest, Secret, Issuer ו- Order and Challenges אם משתמשים בתעודות מ-ACME.

דוגמה לאיתור באגים באישור שעדיין לא מוכן:

$ kubectl cert-manager status certificate acme-certificate

Name: acme-certificate
Namespace: default
Created at: 2020-08-21T16:44:13+02:00
Conditions:
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
  Issuing: True, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  18m   cert-manager  Stored new private key in temporary Secret resource "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Created new CertificateRequest resource "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: The ACME account was registered with the ACME server
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Waiting on certificate issuance from order default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Created Order resource default/acme-certificate-qp5dm-1319513028
Order:
  Name: acme-certificate-qp5dm-1319513028
  State: pending, Reason:
  Authorizations:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial State: pending, Wildcard: false
Challenges:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Key: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, State: pending, Reason: error getting clouddns service account: secret "clouddns-accoun" not found, Processing: true, Presented: false

הפקודה יכולה גם לעזור לך ללמוד עוד על תוכן התעודה. דוגמה מפורטת לאישור שהונפק על ידי Letsencrypt:

$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
  Name: example
  Issuer Country: US
  Issuer Organisation: Let's Encrypt
  Issuer Common Name: Let's Encrypt Authority X3
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usages: Server Authentication, Client Authentication
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  <none>
Not Before: 2020-06-02T04:29:56+02:00
Not After: 2020-08-31T04:29:56+02:00
Renewal Time: 2020-08-01T04:29:56+02:00
[...]

שימוש בממשקי ה-API העדכניים ביותר של Kubernetes

Cert-Manager היה מהראשונים שהטמיעו קוברנטס CRDs. זה, והתמיכה שלנו בגרסאות Kubernetes עד 1.11, פירושו שעלינו לתמוך במורשת apiextensions.k8s.io/v1beta1 גם ל-CRD שלנו admissionregistration.k8s.io/v1beta1 עבור webhooks שלנו. כעת הם הוצאו משימוש והם יוסרו ב-Kubernetes מגרסה 1.22. עם 1.0 שלנו אנו מציעים כעת תמיכה מלאה apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 עבור Kubernetes 1.16 (שם הם נוספו) ואילך. למשתמשים בגרסאות קודמות, אנו ממשיכים להציע תמיכה v1beta1 בשלנו legacy גרסאות.

רישום משופר

במהדורה זו, עדכנו את ספריית הרישום ל klog/v2, בשימוש ב-Kubernetes 1.19. אנחנו גם סוקרים כל יומן שאנחנו כותבים כדי לוודא שהוקצו לו הרמה המתאימה. אנחנו הודרכנו על ידי זה הדרכה של Kubernetes. יש חמישה (למעשה שישה, משוער. מְתוּרגְמָן) רמות רישום החל מ Error (רמה 0), שמדפיסה רק שגיאות חשובות, ומסתיימת ב Trace (רמה 5) שיעזור לך לדעת בדיוק מה קורה. עם השינוי הזה, צמצמנו את מספר היומנים אם אינך זקוק למידע באגים בעת הפעלת cert-manager.

טיפ: cert-manager פועל ברמה 2 כברירת מחדל (Info), אתה יכול לעקוף את זה באמצעות global.logLevel ב-Helmchart.

הערה: צפייה ביומנים היא המוצא האחרון בעת ​​פתרון בעיות. למידע נוסף בדוק את שלנו руководством.

מס' העורך: כדי ללמוד עוד על איך הכל עובד תחת מכסה המנוע של Kubernetes, לקבל עצות חשובות ממורים מתרגלים, כמו גם עזרה טכנית איכותית, אתה יכול לקחת חלק בקורסים מקוונים בסיס Kubernetes, שיתקיים 28-30 בספטמבר, ו Kubernetes Megaשיתקיים בין התאריכים 14-16 באוקטובר.

שיפורים ב-ACME

השימוש הנפוץ ביותר ב-cert-manager קשור כנראה להנפקת אישורים מ-Let's Encrypt באמצעות ACME. גרסה 1.0 בולטת בשימוש במשוב קהילתי כדי להוסיף שני שיפורים קטנים אך חשובים למנפיק ACME שלנו.

השבת את יצירת מפתחות החשבון

אם אתה משתמש בתעודות ACME בכמויות גדולות, סביר להניח שתשתמש באותו חשבון במספר אשכולות, כך שהגבלות הנפקת האישורים שלך יחולו על כולם. זה כבר היה אפשרי ב-cert-manager בעת העתקת הסוד שצוין ב privateKeySecretRef. מקרה השימוש הזה היה די בעייתי, מכיוון ש-cert-manager ניסה לעזור ויצר בשמחה מפתח חשבון חדש אם הוא לא מצא אחד. לכן הוספנו disableAccountKeyGenerationכדי להגן עליך מפני התנהגות זו אם תגדיר אפשרות זו ל true - cert-manager לא יפיק מפתח ויזהיר אותך שלא סופק לו מפתח חשבון.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

שרשרת מועדפת

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

Let's Encrypt כבר חותמת על אישורים עם CA זה ומציעה אותם כ"שרשרת אישורים חלופית" באמצעות ACME. בגרסה זו של cert-manager, ניתן להגדיר גישה לרשתות אלו בהגדרות המנפיק. בפרמטר preferredChain אתה יכול לציין את שם ה-CA שנמצא בשימוש, שאיתו תונפק האישור. אם זמין אישור CA התואם לבקשה, הוא יוציא לך אישור. שימו לב שזו האפשרות המועדפת, אם לא יימצא דבר, תונפק אישור ברירת מחדל. זה יבטיח שעדיין תחדש את האישור שלך לאחר מחיקת השרשרת החלופית בצד מנפיק ACME.

כבר היום ניתן לקבל תעודות חתומות על ידי ISRG Root, כך:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

אם אתה מעדיף לעזוב את השרשרת IdenTrust - הגדר אפשרות זו ל DST Root CA X3:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "DST Root CA X3"

שים לב ש-CA שורש זה יוצא משימוש בקרוב, Let's Encrypt ישאיר את השרשרת פעילה עד 29 בספטמבר 2021.

מקור: www.habr.com