ProHoster > Блог > Администриране > Излезе cert-manager 1.0.

Излезе cert-manager 1.0.

Ако питате опитен многомудър инженер какво мисли за cert-manager и защо всички го използват, той ще въздъхне, доверително ще ви прегърне и уморено ще каже: „Всички го използват, защото нямаме нормални алтернативи. Нашите мишки плачат, но продължават да живеят с този кактус. Защо го обичаме? Защото работи. Защо не го обичаме? Защото постоянно излизат нови версии с нови функции. И трябва да актуализираме кластера отново и отново. А старите версии спират да работят, защото има заговор и велико мистериозно шаманство.

Но разработчиците уверяват, че с 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 официално заявяваме, че cert-manager е зрял проект. Също така обещаваме да поддържаме съвместимостта на нашето API v1.

Огромна благодарност на всички, които ни помогнаха да направим cert-manager такъв през трите години! Нека версия 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 v1 обещаваме да поддържаме съвместимост за години напред.

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

Сертификат:

  • emailSANs сега се нарича emailAddresses

  • uriSANs — uris

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

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

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

Екипът kubectl cert-manager статус

С новите подобрения в нашето разширение към kubectl стана по-лесно да се изследват проблеми, свързани с неиздаването на сертификати. kubectl cert-manager status сега предоставя значително повече информация относно това, което се случва с сертификатите, и показва етапа на издаване на сертификата.

След инсталирането на разширението можете да стартирате kubectl cert-manager статус сертификат <име-на-сертификата>, което ще доведе до търсене на сертификат с указаното име и всички свързани ресурси, като CertificateRequest, Secret, Issuer, а също и Order и 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: 
Not After: 
Renewal Time: 
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:  
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. Има пет (всъщност — шест, прим. преводача) нива на логиране, започващи от Грешка (ниво 0), което извежда само важни грешки, и завършва с Проследяване (ниво 5), което ще помогне да разберете точно какво се случва. С това изменение намалихме броя на логовете, ако не Ви е нужна информация за отстраняване на грешки при работа с cert-manager.

Съвет: по подразбиране cert-manager работи на ниво 2 (Информация), можете да го преопределите, използвайки global.logLevel в Helm chart.

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

N.B. редактора: За повече информация как всичко това работи зад кулисите в Kubernetes, получаване на ценни съвети от практици-преподаватели, както и качествено съдействие от техническата поддръжка, можете да участвате в онлайн интензиви Kubernetes База, който ще се проведе от 28 до 30 септември, и Kubernetes Мега, който ще се проведе от 14 до 16 октомври.

Подобрения ACME

Най-честото приложение на cert-manager вероятно е свързано с издаването на сертификати от Let’s Encrypt, използвайки ACME. Версия 1.0 е забележителна с използването на отзиви от общността за добавяне на две малки, но важни подобрения в нашия ACME issuer.

Отключване на създаване на ключа на акаунта

Ако използвате ACME сертификати в големи количества, вероятно използвате същия акаунт на няколко клъстера, така че вашите ограничения за издаване на сертификати ще важат за всички тях. Това вече беше възможно в cert-manager при копиране на секрет, който е указан в privateKeySecretRef. Такъв случай на употреба беше доста проблематичен, тъй като cert-manager се опитваше да бъде полезен и радостно създаваше нов ключ на акаунта, ако не го намереше. Затова добавихме disableAccountKeyGeneration, за да ви предпази от такова поведение, ако зададете този параметър на истинно — 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. Това изменение не изисква корекции в настройките на cert-manager, всички актуализирани или нови сертификати, издадени след тази дата, ще използват новия коренов CA.

Let’s Encrypt вече подписва сертификати чрез този CA и ги предлага като "алтернативна верига сертификати" чрез ACME. В тази версия на cert-manager има възможност за задаване на достъп до тези вериги в настройките на issuer. В параметъра preferredChain можете да посочите името на използвания CA, чрез който ще бъде издаден сертификатът. Ако има наличен CA сертификат, съответстващ на заявката, той ще ви издаде сертификат. Обърнете внимание, че това е предпочитаната опция, ако нищо не бъде намерено — сертификат по подразбиране ще бъде издаден. Това ще гарантира, че все пак ще актуализирате сертификата си след премахването на алтернативната верига от страна на ACME issuer.

Вече днес можете да получавате сертификати, подписани 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"

Обърнете внимание, че този коренов център за сертификация скоро ще изтече, Let’s Encrypt ще поддържа тази верига активна до 29 септември 2021 година.

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster