cert-manager 1.0 منتشر شد

اگر از یک مهندس باتجربه و خردمند بپرسید که در مورد مدیر گواهینامه چیست و چرا همه از آن استفاده می کنند، متخصص آهی می کشد، او را با اطمینان در آغوش می گیرد و با خستگی می گوید: «همه از آن استفاده می کنند، زیرا هیچ جایگزین عاقلانه ای وجود ندارد. موش های ما گریه می کنند، نیش می زنند، اما با این کاکتوس به زندگی خود ادامه می دهند. چرا دوست داریم؟ چون کار می کند. چرا ما دوست نداریم؟ زیرا دائماً نسخه های جدیدی در حال انتشار هستند که از ویژگی های جدید استفاده می کنند. و باید بارها و بارها کلاستر را به روز کنید. و نسخه های قدیمی کار نمی کنند، زیرا یک توطئه و یک شمنیسم مرموز بزرگ وجود دارد.

اما توسعه دهندگان ادعا می کنند که با cert-manager 1.0 همه چیز دگرگون خواهد شد.

آیا باور خواهیم کرد؟

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 ما رسماً اعلام می کنیم که مدیر گواهی یک پروژه بالغ است. ما همچنین قول می دهیم که API خود را سازگار نگه داریم v1.

با تشکر فراوان از همه کسانی که در تمام این سه سال به ما کمک کردند تا مدیر گواهینامه ایجاد کنیم! اجازه دهید نسخه 1.0 اولین نسخه از بسیاری از چیزهای عالی باشد.

نسخه 1.0 یک نسخه پایدار با چندین حوزه اولویت است:

  • v1 API;

  • تیم kubectl cert-manager statusبرای کمک به تجزیه و تحلیل مشکلات؛

  • استفاده از آخرین APIهای پایدار Kubernetes؛

  • ورود به سیستم بهبود یافته؛

  • بهبودهای ACME

حتما یادداشت های به روز رسانی را قبل از ارتقا بخوانید.

API نسخه 1

نسخه v0.16 با API کار می کرد v1beta1. این تغییرات ساختاری را اضافه کرد و همچنین اسناد فیلد API را بهبود بخشید. نسخه 1.0 همه اینها را با یک API ساخته شده است v1. این API اولین API پایدار ما است، در عین حال ما قبلاً ضمانت‌های سازگاری داده‌ایم، اما با API v1 ما قول می دهیم که سازگاری را برای سال های آینده حفظ کنیم.

تغییرات ایجاد شده (توجه داشته باشید: ابزارهای تبدیل ما از همه چیز برای شما مراقبت می کنند):

گواهینامه:

  • emailSANs اکنون نامیده می شود emailAddresses

  • uriSANs - uris

این تغییرات سازگاری با SAN های دیگر (نام های جایگزین موضوع، تقریبا مترجمو همچنین با Go API. ما در حال حذف این عبارت از API خود هستیم.

بروز رسانی

اگر از Kubernetes 1.16+ استفاده می کنید - تبدیل webhook ها به شما امکان می دهد با نسخه های API به طور همزمان و یکپارچه کار کنید. v1alpha2, v1alpha3, v1beta1 и v1. با استفاده از آنها، می توانید از نسخه جدید API بدون تغییر یا استقرار مجدد منابع قدیمی خود استفاده کنید. ما قویاً توصیه می‌کنیم مانیفست‌های خود را به API ارتقا دهید v1، زیرا نسخه های قبلی به زودی منسوخ می شوند. کاربران legacy نسخه‌های cert-manager همچنان فقط به آن دسترسی خواهند داشت v1، مراحل به روز رسانی را می توان یافت اینجا.

دستور وضعیت cert-manager kubectl

با پیشرفت های جدید در گسترش ما به 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 یکی از اولین کسانی بود که Kubernetes CRD را پیاده سازی کرد. این، همراه با پشتیبانی ما از نسخه های Kubernetes تا 1.11، به این معنی بود که ما باید از نسخه قدیمی پشتیبانی کنیم. apiextensions.k8s.io/v1beta1 برای CRD های ما نیز admissionregistration.k8s.io/v1beta1 برای وب هوک های ما این موارد اکنون منسوخ شده اند و از نسخه 1.22 در Kubernetes حذف خواهند شد. با 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 به اطلاعات اشکال‌زدایی نیاز ندارید، تعداد گزارش‌ها را کاهش داده‌ایم.

نکته: به طور پیش فرض مدیر گواهی در سطح 2 اجرا می شود (Info)، می توانید با استفاده از آن، آن را لغو کنید global.logLevel در نمودار هلم

توجه: بررسی گزارش‌ها آخرین راه حل برای عیب‌یابی است. برای اطلاعات بیشتر ما را بررسی کنید رهبری.

NB سردبیر: برای کسب اطلاعات بیشتر در مورد نحوه عملکرد همه چیز تحت پوشش Kubernetes، دریافت توصیه های ارزشمند از معلمان تمرین، و همچنین پشتیبانی فنی با کیفیت بالا، می توانید در دوره های فشرده آنلاین شرکت کنید. پایگاه کوبرنتیس، که 28 تا 30 سپتامبر برگزار می شود و Kubernetes Mega، که از 14 تا 16 اکتبر برگزار می شود.

بهبودهای ACME

رایج ترین استفاده از cert-manager احتمالاً مربوط به صدور گواهینامه از Let's Encrypt با استفاده از ACME است. نسخه 1.0 به دلیل استفاده از بازخورد جامعه برای افزودن دو پیشرفت کوچک اما مهم به صادرکننده ACME ما قابل توجه است.

غیرفعال کردن تولید کلید حساب

اگر از گواهینامه های ACME در حجم زیاد استفاده می کنید، احتمالاً از یک حساب در چندین خوشه استفاده می کنید، بنابراین محدودیت های صدور گواهی شما برای همه آنها اعمال می شود. این قبلاً در مدیر گواهی هنگام کپی کردن راز مشخص شده در آن امکان پذیر بود privateKeySecretRef. این مورد استفاده کاملاً باگ بود، زیرا مدیر گواهی سعی کرد مفید باشد و اگر کلید حساب جدیدی را پیدا نکرد، با خوشحالی یک کلید حساب جدید ایجاد کرد. به همین دلیل اضافه کردیم 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 سپتامبر بیایید رمزگذاری کنیم عبور خواهد به مرجع گواهی ریشه خود 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

اضافه کردن نظر