🥇გამოშვებულია cert-manager 1.0

თუ გამოცდილ, გონიერ ინჟინერს ჰკითხავთ, რას ფიქრობს ის სერტიფიცირებულ მენეჯერზე და რატომ იყენებს მას ყველა, მაშინ სპეციალისტი ამოისუნთქავს, თავდაჯერებულად ჩაეხუტება და იტყვის დაღლილად: „ყველა იყენებს მას, რადგან საღი ალტერნატივა არ არსებობს. ჩვენი თაგვები ტირიან, ჩხუბობენ, მაგრამ აგრძელებენ ცხოვრებას ამ კაქტუსით. რატომ გვიყვარს? იმიტომ რომ მუშაობს. რატომ არ გვიყვარს? რადგან მუდმივად გამოდის ახალი ვერსიები, რომლებიც იყენებენ ახალ ფუნქციებს. და თქვენ უნდა განაახლოთ კლასტერი უსასრულოდ. და ძველი ვერსიები წყვეტს მუშაობას, რადგან არის შეთქმულება და დიდი იდუმალი შამანიზმი.

მაგრამ დეველოპერები ამას ამტკიცებენ სერტიფიკატი მენეჯერი 1.0 ყველაფერი შეიცვლება.

დავიჯერებთ?

Cert-მენეჯერი არის Kubernetes-ის სერთიფიკატების მართვის კონტროლერი. მისი გამოყენება შესაძლებელია სხვადასხვა წყაროდან სერთიფიკატების გასაცემად: Let's Encrypt, HashiCorp Vault, Venafi, ხელმოწერისა და თვითხელმოწერის გასაღების წყვილი. ის ასევე საშუალებას გაძლევთ განაახლოთ გასაღებები ვადის გასვლის თარიღის მიხედვით და ასევე ცდილობს ავტომატურად განაახლოს სერთიფიკატები განსაზღვრულ დროს მათ ვადის ამოწურვამდე. Cert-manager ეფუძნება kube-lego-ს და ასევე გამოიყენა რამდენიმე ხრიკი სხვა მსგავსი პროექტებიდან, როგორიცაა kube-cert-manager.

Გამოშვების შენიშვნები

1.0 ვერსიით, ჩვენ ვაძლევთ ნდობის ნიშანს სერტიფიკატის მენეჯერის პროექტის სამწლიანი განვითარებისთვის. ამ დროის განმავლობაში, ის მნიშვნელოვნად განვითარდა ფუნქციონალურობითა და სტაბილურობით, მაგრამ ყველაზე მეტად საზოგადოებაში. დღეს ჩვენ ვხედავთ ბევრ ადამიანს, რომელიც იყენებს მას Kubernetes-ის კლასტერების დასაცავად და ასევე ეკოსისტემის სხვადასხვა ნაწილზე მისი განლაგებისთვის. ბოლო 16 გამოშვებაში ბევრი ხარვეზი გამოსწორდა. და რაც უნდა გატეხილიყო, გატეხილია. API-სთან მუშაობის რამდენიმე ვიზიტმა გააუმჯობესა მისი ურთიერთქმედება მომხმარებლებთან. ჩვენ გადავწყვიტეთ 1500 პრობლემა GitHub-ზე მეტი მოთხოვნით საზოგადოების 253 წევრისგან.

1.0-ის გამოშვებით, ჩვენ ოფიციალურად ვაცხადებთ, რომ სერტიფიკატის მენეჯერი არის მომწიფებული პროექტი. ჩვენ ასევე გპირდებით, რომ შევინარჩუნებთ ჩვენს 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

ეს ცვლილებები ამატებს თავსებადობას სხვა SAN-ებთან (subject alt names, დაახლ. მთარგმნელი), ისევე როგორც Go API-ით. ჩვენ ვშლით ამ ტერმინს ჩვენი API-დან.

განახლება

თუ იყენებთ Kubernetes 1.16+-ს, ვებჰუკების კონვერტაცია საშუალებას მოგცემთ ერთდროულად და შეუფერხებლად იმუშაოთ 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 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-ების გამოყენება

Cert-მენეჯერი იყო ერთ-ერთი პირველი, ვინც განახორციელა Kubernetes CRD. ეს და ჩვენი მხარდაჭერა 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. არის ხუთი (სინამდვილეში ექვსი, დაახლ. მთარგმნელი) შესვლის დონეები დაწყებული Error (დონე 0), რომელიც ბეჭდავს მხოლოდ მნიშვნელოვან შეცდომებს და მთავრდება Trace (დონე 5), რომელიც დაგეხმარებათ გაიგოთ ზუსტად რა ხდება. ამ ცვლილებით, ჩვენ შევამცირეთ ჟურნალების რაოდენობა, თუ არ გჭირდებათ გამართვის ინფორმაცია სერტიფიკატის მენეჯერის გაშვებისას.

რჩევა: სერტიფიკატის მენეჯერი ნაგულისხმევად მუშაობს მე-2 დონეზე (Info), შეგიძლიათ ამის აკრძალვა გამოყენებით global.logLevel ჰელმჩარტში.

შენიშვნა: ჟურნალების ნახვა არის ბოლო გამოსავალი პრობლემების მოგვარებისას. დამატებითი ინფორმაციისთვის ეწვიეთ ჩვენს ხელმძღვანელობით.

რედაქტორის ნ.ბ.: იმისათვის, რომ გაიგოთ მეტი, თუ როგორ მუშაობს ეს ყველაფერი Kubernetes-ის ქვეშ, მიიღოთ ღირებული რჩევები პრაქტიკოსი მასწავლებლებისგან, ასევე ხარისხიანი ტექნიკური დახმარებისთვის, შეგიძლიათ მიიღოთ მონაწილეობა ონლაინ ინტენსიურობაში კუბერნეტის ბაზა, რომელიც 28-30 სექტემბერს გაიმართება და Kubernetes Megaრომელიც 14-16 ოქტომბერს გაიმართება.

ACME გაუმჯობესება

სერტიფიკატის მენეჯერის ყველაზე გავრცელებული გამოყენება, ალბათ, დაკავშირებულია 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 CA-ზე 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