ProHoster > блог > Администрација > серт-менаџер 1.0 објавен

серт-менаџер 1.0 објавен

Ако прашате искусен, мудар инженер што мисли за серт-менаџерот и зошто сите го користат, специјалистот ќе воздивне, доверливо ќе го прегрне и ќе ви каже уморно: „Сите го користат, бидејќи нема разумни алтернативи. Нашите глувци плачат, се боцкаат, но продолжуваат да живеат со овој кактус. Зошто сакаме? Затоа што функционира. Зошто не сакаме? Бидејќи постојано се објавуваат нови верзии кои користат нови функции. И мора да го ажурирате кластерот одново и одново. И старите верзии престануваат да функционираат, бидејќи има заговор и голем мистериозен шаманизам“.

Но, програмерите тврдат дека со серт-менаџер 1.0 се ќе се смени.

Да веруваме?

серт-менаџер 1.0 објавен

Cert-manager е мајчин контролер за управување со сертификати на Kubernetes. Може да се користи за издавање сертификати од различни извори: Let's Encrypt, HashiCorp Vault, Venafi, потпишување и самопотпишани парови клучеви. Исто така, ви овозможува да ги ажурирате клучевите и се обидува автоматски да ги обновите сертификатите во одредено време пред да истечат. Серт-менаџер се базира на кубе-лего, а користел и некои техники од други слични проекти, како што е кубе-серт-менаџер.

Белешки за изданието

Со верзијата 1.0 ставаме знак на доверба во трите години на развој на проектот cert-manager. За ова време, тој значително се разви во функционалноста и стабилноста, но најмногу во заедницата. Денес гледаме дека многу луѓе го користат за да ги обезбедат своите кластери Кубернетес, како и да го имплементираат во различни делови на екосистемот. Еден куп грешки се поправени во последните 16 изданија. И тоа што требаше да се скрши беше скршено. Неколку посети на API ја подобрија неговата интеракција со корисниците. Решивме 1500 проблеми на GitHub, со уште повеќе барања за повлекување од 253 членови на заедницата.

Со објавувањето на 1.0, официјално изјавуваме дека cert-manager е зрел проект. Ние, исто така, ветуваме дека ќе го одржиме нашиот API компатибилен v1.

Голема благодарност до сите што ни помогнаа да создадеме серт-менаџер сите овие три години! Нека верзијата 1.0 биде првата од многуте одлични работи што доаѓаат.

Изданието 1.0 е стабилно издание со неколку приоритетни области:

  • v1 API;

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

  • Користење на најновите стабилни Kubernetes API;

  • Подобрено сеча;

  • Подобрувања на ACME.

Не заборавајте да ги прочитате белешките за ажурирање пред надградбата.

API v1

Верзијата v0.16 работеше со API v1beta1. Ова додаде некои структурни промени и исто така ја подобри документацијата на теренот API. Верзијата 1.0 се надоврзува на сето ова со API v1. Овој API е нашиот прв стабилен, во исто време веќе дадовме гаранции за компатибилност, но со API v1 Ветуваме дека ќе ја одржуваме компатибилноста во годините што доаѓаат.

Направени промени (забелешка: нашите алатки за конверзија ќе се погрижат за сè за вас):

Сертификат:

  • emailSANs сега повикан emailAddresses

  • uriSANs - uris

Овие промени додаваат компатибилност со други САН (имиња на алт на теми, прибл. преведувач), како и со Go API. Го отстрануваме овој термин од нашиот API.

Ажурирање

Ако користите Kubernetes 1.16+ - конвертирањето веб-куки ќе ви овозможи да работите со верзии на API истовремено и беспрекорно v1alpha2, v1alpha3, v1beta1 и v1. Со нив, можете да ја користите новата верзија на API без да ги менувате или прераспоредувате вашите стари ресурси. Силно препорачуваме да ги надградите вашите манифестати на API v1, бидејќи претходните верзии наскоро ќе бидат застарени. Корисници legacy верзиите на cert-manager сè уште ќе имаат пристап само до v1, може да се најдат чекори за ажурирање тука.

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
[...]

Искористете ги најновите стабилни Kubernetes API

Серт-менаџер беше еден од првите што ги имплементираше Kubernetes CRDs. Ова, заедно со нашата поддршка за верзиите на Kubernetes до 1.11, значеше дека треба да го поддржиме наследството apiextensions.k8s.io/v1beta1 и за нашите ЦРД admissionregistration.k8s.io/v1beta1 за нашите веб-куки. Тие сега се застарени и ќе бидат отстранети во Кубернетес од верзијата 1.22. Со нашиот 1.0 сега нудиме целосна поддршка apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 за Kubernetes 1.16 (каде што беа додадени) и подоцна. За корисниците на претходните верзии, ние продолжуваме да нудиме поддршка v1beta1 во нашата legacy верзии.

Подобрено сеча

Во оваа верзија ја ажуриравме библиотеката за логирање на klog/v2, користен во Kubernetes 1.19. Исто така, го прегледуваме секое списание што го пишуваме за да се осигураме дека му е доделено соодветното ниво. Се водевме по ова насоки од Кубернетес. Има пет (всушност - шест, прибл. преведувач) нивоа на логирање почнувајќи од Error (ниво 0), кој печати само важни грешки и завршува со Trace (ниво 5), што ќе ви помогне да дознаете што точно се случува. Со оваа промена го намаливме бројот на дневници доколку не ви требаат информации за дебагирање при извршување на cert-manager.

Совет: стандардно серт-менаџерот работи на ниво 2 (Info), можете да го отфрлите ова користејќи global.logLevel во табелата на Хелм.

Забелешка: Прегледувањето на дневниците е последното средство кога решавате проблеми. За повеќе информации проверете ја нашата лидерство.

Забелешка на уредникот: За да дознаете повеќе за тоа како сето тоа функционира под капата на Kubernetes, да добиете вредни совети од учители кои практикуваат, како и висококвалитетна техничка поддршка, можете да учествувате на онлајн интензивни курсеви База Кубернетес, кој ќе се одржи од 28-30 септември, и Кубернетес мега, што ќе се одржи од 14 до 16 октомври.

Подобрувања на ACME

Најчестата употреба на cert-manager е веројатно поврзана со издавање сертификати од Let's Encrypt користејќи ACME. Верзијата 1.0 е забележлива по користењето повратни информации од заедницата за додавање на две мали, но важни подобрувања на нашиот издавач ACME.

Оневозможи генерирање клучеви за сметка

Ако користите ACME сертификати во големи количини, веројатно ја користите истата сметка на повеќе кластери, така што ограничувањата за издавање сертификати ќе важат за сите нив. Ова веќе беше возможно кај серт-менаџерот при копирање на тајната наведена во privateKeySecretRef. Овој случај на употреба беше доста пробиен затоа што серт-менаџерот се обиде да биде корисен и среќно создаде нов клуч за сметка ако не можеше да најде. Затоа додадовме disableAccountKeyGenerationда ве заштити од ова однесување со поставување на оваа опција на true - Серт-менаџер нема да генерира клуч и ќе ве предупреди дека не му бил даден клуч за сметка.

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

Претпочитан синџир

29 септември Ајде да шифрираме ќе се движи до вашиот сопствен авторитет за сертификати за root ISRG Root. Вкрстено потпишаните сертификати ќе бидат заменети со Identrust. Оваа промена не бара промени во поставките за серт-менаџер, сите ажурирани или нови сертификати издадени по овој датум ќе го користат новиот root CA.

Ајде да криптираме веќе потпишува сертификати со овој 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