издаден е 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.

Благодарим много на всички, които ни помогнаха да създадем cert-manager през тези три години! Нека версия 1.0 бъде първото от многото страхотни неща, които предстоят.

Версия 1.0 е стабилна версия с няколко приоритетни области:

• v1 ОГЪН;

• Отбор kubectl cert-manager status, за подпомагане на анализа на проблемите;

• Използване на най-новите стабилни API на Kubernetes;

• Подобрено регистриране;

• Подобрения на ACME.

Не забравяйте да прочетете бележките за актуализация, преди да надстроите.

API v1

Версия v0.16 работи с API v1beta1. Това добави някои структурни промени и също така подобри документацията на API полето. Версия 1.0 надгражда всичко това с API v1. Този API е първият ни стабилен, като в същото време вече сме дали гаранции за съвместимост, но с API v1 Обещаваме да поддържаме съвместимост за години напред.

Направени промени (забележка: нашите инструменти за конвертиране ще се погрижат за всичко вместо вас):

Сертификат:

• emailSANs сега се обажда emailAddresses

• uriSANs - uris

Тези промени добавят съвместимост с други SAN (алтернативни имена на субекти, прибл. преводач), както и с Go API. Ние премахваме този термин от нашия API.

Актуализация

Ако използвате Kubernetes 1.16+ - конвертирането на webhooks ще ви позволи да работите с версии на API едновременно и безпроблемно v1alpha2, v1alpha3, v1beta1 и v1. С тях можете да използвате новата версия на API, без да променяте или преразпределяте старите си ресурси. Силно препоръчваме да надстроите вашите манифести до API v1, тъй като предишните версии скоро ще бъдат оттеглени. Потребители legacy версиите на cert-manager все още ще имат достъп само до v1, можете да намерите стъпки за актуализиране тук.

kubectl cert-manager status команда

С нови подобрения в нашето разширение за 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 беше един от първите, които внедриха CRD на Kubernetes. Това, съчетано с нашата поддръжка за версии на Kubernetes до 1.11, означаваше, че трябва да поддържаме наследени apiextensions.k8s.io/v1beta1 и за нашите CRD admissionregistration.k8s.io/v1beta1 за нашите уебкукички. Те вече са отхвърлени и ще бъдат премахнати в 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 в диаграмата на Хелм.

Забележка: Прегледът на регистрационните файлове е последната ви възможност при отстраняване на неизправности. За повече информация вижте нашия лидерство.

NB на редактора: За да научите повече за това как работи всичко под капака на 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 септември Let's Encrypt ще се движи към вашия собствен основен сертификатен орган 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