🥇Выйшаў 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 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+ - канвертуючыя 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 і 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 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 у Helm chart.

Заўвага: прагляд часопісаў - апошні сродак пры ўхіленні непаладак. Для дадатковай інфармацыі азнаёмцеся з нашым кіраўніцтвам.

NB рэдактара: Каб больш падрабязна даведацца, як гэта ўсё працуе пад капотам у 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, каб абараніць вас ад такіх паводзін, калі ўсталяваць гэты параметр у 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. Гэтая змена не патрабуе правак у наладах 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

Выйшаў cert-manager 1.0