cert-manager 1.0 បានចេញផ្សាយ

ប្រសិនបើអ្នកសួរវិស្វករដែលមានបទពិសោធន៍ និងឈ្លាសវៃថាគាត់គិតយ៉ាងណាចំពោះអ្នកគ្រប់គ្រងវិញ្ញាបនបត្រ និងមូលហេតុដែលមនុស្សគ្រប់គ្នាប្រើវា អ្នកឯកទេសនឹងដកដង្ហើមធំ ឱបគាត់ដោយសម្ងាត់ ហើយនិយាយដោយនឿយហត់៖ “គ្រប់គ្នាប្រើវា ពីព្រោះគ្មានជម្រើសល្អទេ។ កណ្ដុរ​របស់​យើង​ស្រែក​ទ្រហោ​យំ ប៉ុន្តែ​បន្ត​រស់​នៅ​ជាមួយ​ដើម​ត្រសក់​នេះ។ ហេតុអ្វីបានជាយើងស្រឡាញ់? ព្រោះវាដំណើរការ។ ហេតុអ្វីយើងមិនស្រលាញ់? ដោយសារតែកំណែថ្មីត្រូវបានចេញផ្សាយឥតឈប់ឈរ ដែលប្រើប្រាស់មុខងារថ្មីៗ។ ហើយអ្នកត្រូវតែធ្វើបច្ចុប្បន្នភាពចង្កោមម្តងហើយម្តងទៀត។ ហើយ​កំណែ​ចាស់​ឈប់​ដំណើរការ​ទៅ​ហើយ ព្រោះ​មាន​ការ​ឃុបឃិត​គ្នា និង​មាន​អាថ៌​កំបាំង​ដ៏​អស្ចារ្យ»។

ប៉ុន្តែអ្នកអភិវឌ្ឍន៍អះអាងថាជាមួយ អ្នកគ្រប់គ្រងវិញ្ញាបនប័ត្រ 1.0 អ្វីគ្រប់យ៉ាងនឹងផ្លាស់ប្តូរ។

តើយើងគួរជឿទេ?

Cert-manager គឺជាឧបករណ៍បញ្ជាការគ្រប់គ្រងវិញ្ញាបនបត្រ Kubernetes ដើម។ វាអាចត្រូវបានប្រើដើម្បីចេញវិញ្ញាបនបត្រពីប្រភពផ្សេងៗ៖ Let's Encrypt, HashiCorp Vault, Venafi, signing and self-signed key pairs។ វាក៏អនុញ្ញាតឱ្យអ្នករក្សាសោឱ្យទាន់សម័យ និងព្យាយាមបន្តវិញ្ញាបនបត្រដោយស្វ័យប្រវត្តិនៅពេលជាក់លាក់មួយ មុនពេលពួកវាផុតកំណត់។ Cert-manager គឺផ្អែកលើ kube-lego ហើយក៏បានប្រើបច្ចេកទេសមួយចំនួនពីគម្រោងស្រដៀងគ្នាផ្សេងទៀតផងដែរ ដូចជា kube-cert-manager ។

កំណត់ចំណាំចេញផ្សាយ

ជាមួយនឹងកំណែ 1.0 យើងបានដាក់សញ្ញានៃការជឿទុកចិត្តនៅក្នុងរយៈពេលបីឆ្នាំនៃការអភិវឌ្ឍន៍គម្រោងអ្នកគ្រប់គ្រងវិញ្ញាបនបត្រ។ ក្នុងអំឡុងពេលនេះ វាបានអភិវឌ្ឍយ៉ាងខ្លាំងនៅក្នុងមុខងារ និងស្ថេរភាព ប៉ុន្តែភាគច្រើននៅក្នុងសហគមន៍។ សព្វថ្ងៃនេះយើងឃើញមនុស្សជាច្រើនប្រើប្រាស់វាដើម្បីធានាបាននូវចង្កោម Kubernetes របស់ពួកគេ ក៏ដូចជាអនុវត្តវាទៅក្នុងផ្នែកផ្សេងៗនៃប្រព័ន្ធអេកូ។ កំហុសជាច្រើនត្រូវបានជួសជុលនៅក្នុងការចេញផ្សាយ 16 ចុងក្រោយ។ ហើយអ្វីដែលគួរត្រូវបានខូចត្រូវបានខូច។ ការចូលមើល API ជាច្រើនលើកធ្វើអោយអន្តរកម្មរបស់វាប្រសើរឡើងជាមួយអ្នកប្រើប្រាស់។ យើងបានដោះស្រាយបញ្ហាចំនួន 1500 នៅលើ GitHub ដោយមានសំណើទាញកាន់តែច្រើនពីសមាជិកសហគមន៍ចំនួន 253 នាក់។

តាមរយៈការចេញផ្សាយ 1.0 យើងប្រកាសជាផ្លូវការថាអ្នកគ្រប់គ្រងវិញ្ញាបនបត្រគឺជាគម្រោងចាស់ទុំ។ យើងក៏សន្យាថានឹងរក្សា API របស់យើងឱ្យត្រូវគ្នា។ v1.

អរគុណអ្នកគ្រប់គ្នាដែលបានជួយយើងបង្កើត cert-manager ទាំងបីឆ្នាំនេះ! សូមឱ្យកំណែ 1.0 ក្លាយជារឿងដ៏អស្ចារ្យដំបូងគេបង្អស់ដែលនឹងមកដល់។

ការចេញផ្សាយ 1.0 គឺជាការចេញផ្សាយដែលមានស្ថេរភាពជាមួយនឹងផ្នែកអាទិភាពជាច្រើន៖

• v1 API

• ក្រុមការងារ kubectl cert-manager statusដើម្បីជួយវិភាគបញ្ហា;

• ការប្រើប្រាស់ APIs Kubernetes ដែលមានស្ថេរភាពចុងក្រោយបំផុត;

• ការកាប់ឈើប្រសើរឡើង;

• ការកែលម្អ ACME ។

ត្រូវប្រាកដថាបានអានកំណត់ចំណាំធ្វើបច្ចុប្បន្នភាពមុននឹងធ្វើបច្ចុប្បន្នភាព។

API v1

កំណែ v0.16 ដំណើរការជាមួយ API v1beta1. វាបានបន្ថែមការផ្លាស់ប្តូររចនាសម្ព័ន្ធមួយចំនួន និងបានធ្វើឱ្យប្រសើរឡើងនូវឯកសារវាល API ផងដែរ។ កំណែ 1.0 បង្កើតនៅលើទាំងអស់នេះជាមួយនឹង API v1. API នេះគឺជាស្ថេរភាពដំបូងរបស់យើង ក្នុងពេលជាមួយគ្នានេះ យើងបានផ្តល់ការធានាភាពឆបគ្នារួចហើយ ប៉ុន្តែជាមួយនឹង API v1 យើងសន្យាថានឹងរក្សាភាពឆបគ្នាសម្រាប់ឆ្នាំខាងមុខ។

ការផ្លាស់ប្តូរដែលបានធ្វើឡើង (ចំណាំ៖ ឧបករណ៍បំប្លែងរបស់យើងនឹងថែរក្សាអ្វីៗគ្រប់យ៉ាងសម្រាប់អ្នក)៖

វិញ្ញាបនបត្រ៖

• emailSANs ឥឡូវនេះបានហៅ emailAddresses

• uriSANs - uris

ការផ្លាស់ប្តូរទាំងនេះបន្ថែមភាពឆបគ្នាជាមួយ SANs ផ្សេងទៀត (ឈ្មោះប្រធានបទ alt, ប្រហែល អ្នកបកប្រែ) ក៏ដូចជា Go API ផងដែរ។ យើងកំពុងលុបពាក្យនេះចេញពី API របស់យើង។

ធ្វើបច្ចុប្បន្នភាព

ប្រសិនបើអ្នកកំពុងប្រើ Kubernetes 1.16+ - ការបំប្លែង webhooks នឹងអនុញ្ញាតឱ្យអ្នកធ្វើការជាមួយកំណែ API ក្នុងពេលដំណាលគ្នា និងគ្មានថ្នេរ។ v1alpha2, v1alpha3, v1beta1 и v1. ជាមួយពួកគេ អ្នកអាចប្រើកំណែថ្មីនៃ API ដោយមិនចាំបាច់ផ្លាស់ប្តូរ ឬប្រើប្រាស់ធនធានចាស់របស់អ្នកឡើងវិញ។ យើងសូមផ្តល់អនុសាសន៍យ៉ាងមុតមាំឱ្យធ្វើឱ្យប្រសើរឡើងនូវ manifests របស់អ្នកទៅ API v1ដូចដែលកំណែមុននឹងត្រូវបានបដិសេធក្នុងពេលឆាប់ៗនេះ។ អ្នកប្រើប្រាស់ legacy កំណែរបស់ cert-manager នឹងនៅតែមានសិទ្ធិចូលប្រើប៉ុណ្ណោះ។ v1ជំហានធ្វើបច្ចុប្បន្នភាពអាចរកបាន នៅទីនេះ.

ពាក្យបញ្ជាស្ថានភាពអ្នកគ្រប់គ្រង cert kubectl

ជាមួយនឹងការកែលម្អថ្មីនៅក្នុងផ្នែកបន្ថែមរបស់យើងទៅ kubectl វាកាន់តែងាយស្រួលក្នុងការស៊ើបអង្កេតបញ្ហាដែលទាក់ទងនឹងការមិនចេញវិញ្ញាបនបត្រ។ kubectl cert-manager status ឥឡូវនេះផ្តល់ព័ត៌មានបន្ថែមជាច្រើនអំពីអ្វីដែលកំពុងកើតឡើងជាមួយវិញ្ញាបនបត្រ ហើយក៏បង្ហាញដំណាក់កាលដែលវិញ្ញាបនបត្រត្រូវបានចេញផងដែរ។

បន្ទាប់ពីដំឡើងកម្មវិធីបន្ថែមអ្នកអាចដំណើរការបាន។ kubectl cert-manager status certificate <имя-сертификата>ដែលនឹងស្វែងរកវិញ្ញាបនបត្រដែលមានឈ្មោះដែលបានបញ្ជាក់ និងធនធានដែលពាក់ព័ន្ធដូចជា CertificateRequest, Secret, Issuer, and 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
[...]

ប្រើប្រាស់ APIs Kubernetes ដែលមានស្ថេរភាពចុងក្រោយបំផុត។

Cert-manager គឺជាអ្នកដំបូងគេដែលអនុវត្ត Kubernetes CRDs ។ នេះរួមជាមួយនឹងការគាំទ្ររបស់យើងសម្រាប់កំណែ Kubernetes រហូតដល់ 1.11 មានន័យថាយើងត្រូវការដើម្បីគាំទ្រកេរ្តិ៍ដំណែល apiextensions.k8s.io/v1beta1 សម្រាប់ CRDs របស់យើងផងដែរ។ 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) ដែលនឹងជួយអ្នកឱ្យដឹងច្បាស់នូវអ្វីដែលកំពុងកើតឡើង។ ជាមួយនឹងការផ្លាស់ប្តូរនេះ យើងបានកាត់បន្ថយចំនួនកំណត់ហេតុ ប្រសិនបើអ្នកមិនត្រូវការព័ត៌មានបំបាត់កំហុស នៅពេលដំណើរការកម្មវិធីគ្រប់គ្រងវិញ្ញាបនបត្រ។

គន្លឹះ៖ តាមលំនាំដើម អ្នកគ្រប់គ្រងវិញ្ញាបនបត្រដំណើរការនៅកម្រិត 2 (Info) អ្នកអាចបដិសេធវាដោយប្រើ global.logLevel នៅក្នុងតារាង Helm ។

ចំណាំ៖ ការពិនិត្យមើលកំណត់ហេតុគឺជាមធ្យោបាយចុងក្រោយរបស់អ្នកនៅពេលដោះស្រាយបញ្ហា។ សម្រាប់ព័ត៌មានបន្ថែម សូមពិនិត្យមើលរបស់យើង។ ភាពជាអ្នកដឹកនាំ.

អ្នកនិពន្ធ n.b.៖ ដើម្បីស្វែងយល់បន្ថែមអំពីរបៀបដែលវាដំណើរការទាំងអស់នៅក្រោមក្រណាត់របស់ Kubernetes ទទួលបានដំបូន្មានដ៏មានតម្លៃពីគ្រូដែលអនុវត្ត ក៏ដូចជាជំនួយបច្ចេកទេសដែលមានគុណភាពខ្ពស់ អ្នកអាចចូលរួមក្នុងវគ្គសិក្សាដែលពឹងផ្អែកខ្លាំងលើអ៊ីនធឺណិត មូលដ្ឋាន Kubernetesដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃទី 28-30 ខែកញ្ញា និង Kubernetes Megaដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃទី ១៤-១៦ ខែតុលា។

ការកែលម្អ ACME

ការប្រើប្រាស់ជាទូទៅបំផុតរបស់អ្នកគ្រប់គ្រងវិញ្ញាបនបត្រគឺប្រហែលទាក់ទងទៅនឹងការចេញវិញ្ញាបនបត្រពី Let's Encrypt ដោយប្រើ ACME។ កំណែ 1.0 គឺគួរឱ្យកត់សម្គាល់សម្រាប់ការប្រើប្រាស់មតិកែលម្អសហគមន៍ដើម្បីបន្ថែមការកែលម្អតូច ប៉ុន្តែសំខាន់ពីរដល់អ្នកចេញ ACME របស់យើង។

បិទការបង្កើតកូនសោគណនី

ប្រសិនបើអ្នកប្រើវិញ្ញាបនបត្រ ACME ក្នុងបរិមាណច្រើន អ្នកទំនងជាប្រើគណនីដូចគ្នានៅលើចង្កោមច្រើន ដូច្នេះការរឹតបន្តឹងការចេញវិញ្ញាបនបត្ររបស់អ្នកនឹងអនុវត្តចំពោះពួកវាទាំងអស់។ វាអាចទៅរួចរួចហើយនៅក្នុងអ្នកគ្រប់គ្រងវិញ្ញាបនប័ត្រនៅពេលចម្លងការសម្ងាត់ដែលបានបញ្ជាក់នៅក្នុង privateKeySecretRef. ករណីនៃការប្រើប្រាស់នេះពិតជាមានកំហុស ដោយសារតែអ្នកគ្រប់គ្រងវិញ្ញាបនបត្របានព្យាយាមជួយ និងបង្កើតសោគណនីថ្មីដោយរីករាយ ប្រសិនបើវារកមិនឃើញ។ នោះហើយជាមូលហេតុដែលយើងបន្ថែម 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 ខែកញ្ញា ចូរយើងអ៊ិនគ្រីប នឹងផ្លាស់ទី ទៅអាជ្ញាធរវិញ្ញាបនបត្រ 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"

សូមចំណាំថា root CA នេះនឹងត្រូវបានបដិសេធក្នុងពេលឆាប់ៗនេះ Let's Encrypt នឹងបន្តដំណើរការខ្សែសង្វាក់នេះរហូតដល់ថ្ងៃទី 29 ខែកញ្ញា ឆ្នាំ 2021។

ប្រភព: www.habr.com