🥇 Mae rheolwr tystysgrif 1.0 allan

Os gofynnwch i beiriannydd doeth profiadol beth yw ei farn am reolwr tystysgrif a pham mae pawb yn ei ddefnyddio, yna bydd yr arbenigwr yn ochneidio, yn ei gofleidio'n gyfrinachol ac yn dweud yn flinedig: “Mae pawb yn ei ddefnyddio, oherwydd nid oes unrhyw ddewisiadau call. Mae ein llygod yn crio, pigo, ond yn parhau i fyw gyda'r cactws hwn. Pam rydyn ni'n caru? Oherwydd ei fod yn gweithio. Pam nad ydym yn caru? Oherwydd bod fersiynau newydd yn dod allan yn gyson sy'n defnyddio nodweddion newydd. Ac mae'n rhaid i chi ddiweddaru'r clwstwr dro ar ôl tro. Ac mae'r hen fersiynau'n peidio â gweithio, oherwydd mae yna gynllwyn a siamaniaeth ddirgel fawr.

Ond mae'r datblygwyr yn honni hynny tystysgrif-reolwr 1.0 bydd popeth yn newid.

A fyddwn ni'n credu?

Cert-manager yw rheolwr rheoli tystysgrif Kubernetes brodorol. Gellir ei ddefnyddio i gyhoeddi tystysgrifau o wahanol ffynonellau: Let's Encrypt, HashiCorp Vault, Venafi, llofnodi a pharau allwedd hunan-lofnodi. Mae hefyd yn caniatáu ichi gadw allweddi'n gyfredol erbyn dyddiad dod i ben, ac mae hefyd yn ceisio adnewyddu tystysgrifau yn awtomatig ar amser penodol cyn iddynt ddod i ben. Mae Cert-manager yn seiliedig ar kube-lego ac mae hefyd wedi defnyddio rhai triciau o brosiectau tebyg eraill fel kube-cert-manager.

Nodiadau Rhyddhau

Gyda fersiwn 1.0, rhoesom arwydd o ymddiriedaeth am dair blynedd o ddatblygiad y prosiect rheolwr tystysgrif. Yn ystod y cyfnod hwn, mae wedi esblygu'n sylweddol o ran ymarferoldeb a sefydlogrwydd, ond yn bennaf oll yn y gymuned. Heddiw, rydym yn gweld llawer o bobl yn ei ddefnyddio i ddiogelu eu clystyrau Kubernetes yn ogystal â'i ddefnyddio i wahanol rannau o'r ecosystem. Mae llawer o fygiau wedi'u trwsio yn yr 16 datganiad diwethaf. A'r hyn sydd angen ei dorri yw torri. Mae sawl ymweliad â'r API wedi gwella ei ryngweithio â defnyddwyr. Rydym wedi datrys 1500 o faterion ar GitHub gyda mwy o geisiadau tynnu gan 253 o aelodau'r gymuned.

Gyda rhyddhau 1.0, rydym yn datgan yn swyddogol bod y rheolwr tystysgrif yn brosiect aeddfed. Rydym hefyd yn addo cadw ein API yn gydnaws v1.

Diolch yn fawr i bawb a helpodd ni i wneud tystysgrif-reolwr dros y tair blynedd yma! Gadewch i fersiwn 1.0 fod y cyntaf o lawer o bethau mawr i ddod.

Mae Release 1.0 yn ddatganiad sefydlog gyda sawl maes blaenoriaeth:

v1 API;
Tîm kubectl cert-manager status, i helpu gyda dadansoddi problemau;
Defnyddio'r APIs Kubernetes sefydlog diweddaraf;
Gwell logio;
Gwelliannau ACME.

Byddwch yn siwr i ddarllen y nodiadau uwchraddio cyn uwchraddio.

API v1

Gweithiodd fersiwn v0.16 gyda'r API v1beta1. Ychwanegodd hyn rai newidiadau strwythurol a gwella dogfennaeth maes API hefyd. Mae fersiwn 1.0 yn adeiladu ar hyn gydag API v1. Yr API hwn yw ein un sefydlog cyntaf, ar yr un pryd rydym eisoes wedi rhoi gwarantau cydnawsedd, ond gyda'r API v1 rydym yn addo cynnal cydnawsedd am flynyddoedd i ddod.

Newidiadau a wnaed (noder: mae ein hoffer trosi yn gofalu am bopeth i chi):

Tystysgrif:

emailSANs a elwir yn awr emailAddresses
uriSANs - uris

Mae'r newidiadau hyn yn ychwanegu cydnawsedd â SANs eraill (enwau alt pwnc, tua. cyfieithydd), yn ogystal â'r API Go. Rydym yn tynnu'r term hwn o'n API.

Diweddariad

Os ydych chi'n defnyddio Kubernetes 1.16+, bydd trosi bachau gwe yn caniatáu ichi weithio gyda fersiynau API ar yr un pryd ac yn ddi-dor v1alpha2, v1alpha3, v1beta1 и v1. Gyda'r rhain, byddwch yn gallu defnyddio'r fersiwn newydd o'r API heb newid neu adleoli eich hen adnoddau. Rydym yn argymell yn gryf uwchraddio'ch maniffestau i'r API v1, gan y bydd fersiynau blaenorol yn anghymeradwy cyn bo hir. Defnyddwyr legacy dim ond fersiynau o cert-manager fydd ar gael o hyd v1, gellir dod o hyd i gamau uwchraddio yma.

gorchymyn statws cert-manager kubectl

Gyda gwelliannau newydd yn ein estyniad i kubectl daeth yn haws ymchwilio i'r problemau sy'n gysylltiedig â pheidio â rhoi tystysgrifau. kubectl cert-manager status nawr yn rhoi llawer mwy o wybodaeth am yr hyn sy'n digwydd gyda'r tystysgrifau a hefyd yn dangos y cam cyhoeddi tystysgrifau.

Ar ôl gosod yr estyniad, gallwch redeg kubectl cert-manager status certificate <имя-сертификата>, a fydd yn edrych i fyny'r dystysgrif gyda'r enw a roddir ac unrhyw adnoddau cysylltiedig megis TystysgrifCais, Cyfrinach, Cyhoeddwr, a Gorchymyn a Heriau os ydych yn defnyddio tystysgrifau ACME.

Enghraifft o ddadfygio tystysgrif nad yw'n barod eto:

$ 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

Gall y gorchymyn hefyd eich helpu i ddysgu mwy am gynnwys y dystysgrif. Enghraifft fanwl ar gyfer tystysgrif a gyhoeddwyd gan 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
[...]

Gan ddefnyddio'r APIs Kubernetes sefydlog diweddaraf

Cert-manager oedd un o'r rhai cyntaf i weithredu Kubernetes CRDs. Roedd hyn, a'n cefnogaeth i fersiynau Kubernetes hyd at 1.11, yn golygu bod angen i ni gefnogi'r etifeddiaeth apiextensions.k8s.io/v1beta1 ar gyfer ein CRDs hefyd admissionregistration.k8s.io/v1beta1 ar gyfer ein bachau gwe. Maent bellach yn anghymeradwy a byddant yn cael eu tynnu yn Kubernetes o fersiwn 1.22. Gyda'n 1.0 rydym nawr yn cynnig cefnogaeth lawn apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 ar gyfer Kubernetes 1.16 (lle cawsant eu hychwanegu) a mwy newydd. Ar gyfer defnyddwyr fersiynau blaenorol, rydym yn parhau i gynnig cefnogaeth v1beta1 yn ein legacy fersiynau.

Gwell logio

Yn y datganiad hwn, rydym wedi diweddaru'r llyfrgell logio i klog/v2, a ddefnyddir yn Kubernetes 1.19. Rydym hefyd yn adolygu pob cyfnodolyn a ysgrifennwn i wneud yn siŵr ei fod yn cael y lefel briodol. Cawsom ein harwain gan hyn arweiniad gan Kubernetes. Mae pump (chwech mewn gwirionedd, tua. cyfieithydd) lefelau logio yn dechrau o Error (lefel 0), sy'n argraffu gwallau pwysig yn unig, ac yn gorffen gyda Trace (lefel 5) a fydd yn eich helpu i wybod yn union beth sy'n digwydd. Gyda'r newid hwn, rydym wedi lleihau nifer y cofnodion os nad oes angen gwybodaeth dadfygio arnoch wrth redeg cert-manager.

Awgrym: mae cert-manager yn rhedeg ar lefel 2 yn ddiofyn (Info), gallwch ddiystyru hyn gan ddefnyddio global.logLevel yn Helmchart.

Nodyn: Gweld y logiau yw'r dewis olaf wrth ddatrys problemau. Am fwy o wybodaeth edrychwch ar ein arweinyddiaeth.

Golygydd n.b.: I ddysgu mwy am sut mae'r cyfan yn gweithio o dan gwfl Kubernetes, mynnwch gyngor gwerthfawr gan athrawon wrth eu gwaith, yn ogystal â chymorth cymorth technegol o ansawdd, gallwch chi gymryd rhan mewn sesiynau dwys ar-lein Sylfaen Kubernetes, a gynhelir Medi 28-30, a Kubernetes Megaa gynhelir Hydref 14-16.

Gwelliannau ACME

Mae'n debyg bod y defnydd mwyaf cyffredin o reolwr tystysgrif yn ymwneud â rhoi tystysgrifau gan Let's Encrypt gan ddefnyddio ACME. Mae Fersiwn 1.0 yn nodedig am ddefnyddio adborth cymunedol i ychwanegu dau welliant bach ond pwysig at ein cyhoeddwr ACME.

Analluogi cynhyrchu allwedd cyfrif

Os ydych chi'n defnyddio llawer iawn o dystysgrifau ACME, rydych chi'n debygol o ddefnyddio'r un cyfrif ar glystyrau lluosog, felly bydd eich cyfyngiadau cyhoeddi tystysgrif yn berthnasol i bob un ohonyn nhw. Roedd hyn eisoes yn bosibl yn y rheolwr tystysgrif wrth gopïo'r gyfrinach a nodir yn privateKeySecretRef. Roedd yr achos defnydd hwn yn eithaf bygi, wrth i'r rheolwr tystysgrif geisio bod yn ddefnyddiol a chreu allwedd cyfrif newydd yn hapus os na ddaeth o hyd i un. Dyna pam y gwnaethom ychwanegu disableAccountKeyGenerationi'ch amddiffyn rhag yr ymddygiad hwn os ydych chi'n gosod yr opsiwn hwn i true - ni fydd cert-manager yn cynhyrchu allwedd a bydd yn eich rhybuddio na roddwyd allwedd cyfrif iddo.

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

Cadwyn Ddewisol

Medi 29 Dewch i Amgryptio bydd pasio at eich gwraidd eich hun CA ISRG Root. Bydd tystysgrifau wedi'u traws-lofnodi yn cael eu disodli gan Identrust. Nid yw'r newid hwn yn gofyn am newidiadau i'r gosodiadau rheolwr tystysgrif, bydd pob tystysgrif wedi'i diweddaru neu dystysgrif newydd a gyhoeddir ar ôl y dyddiad hwn yn defnyddio'r CA gwraidd newydd.

Mae Let's Encrypt eisoes yn llofnodi tystysgrifau gyda'r CA hwn ac yn eu cynnig fel "cadwyn dystysgrif arall" trwy ACME. Yn y fersiwn hwn o cert-manager, mae'n bosibl gosod mynediad i'r cadwyni hyn yng ngosodiadau'r cyhoeddwr. Mewn paramedr preferredChain gallwch nodi enw'r CA a ddefnyddir, y bydd y dystysgrif yn cael ei chyhoeddi ag ef. Os oes tystysgrif CA sy'n cyfateb i'r cais ar gael, bydd yn rhoi tystysgrif i chi. Sylwch mai dyma'r opsiwn a ffefrir, os na chanfyddir unrhyw beth, bydd tystysgrif ddiofyn yn cael ei chyhoeddi. Bydd hyn yn sicrhau y byddwch yn dal i adnewyddu eich tystysgrif ar ôl dileu'r gadwyn arall ar ochr y cyhoeddwr ACME.

Eisoes heddiw gallwch dderbyn tystysgrifau wedi'u llofnodi gan ISRG Root, Felly:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

Os yw'n well gennych chi adael y gadwyn IdenTrust - gosod yr opsiwn hwn i 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"

Sylwch y bydd y CA gwraidd hwn yn cael ei anghymeradwyo'n fuan, bydd Let's Encrypt yn cadw'r gadwyn hon yn weithredol tan fis Medi 29, 2021.

Ffynhonnell: hab.com

cert-manager 1.0 wedi'i ryddhau