प्रमाणपत्र-प्रबन्धक 1.0 जारी गरियो

यदि तपाईंले एक अनुभवी, बुद्धिमान इन्जिनियरलाई प्रमाणपत्र-प्रबन्धकको बारेमा के सोच्नुहुन्छ र किन सबैले यसलाई प्रयोग गर्नुहुन्छ भनेर सोध्नुहोस्, तब विशेषज्ञले सास फेर्नेछन्, उसलाई विश्वासमा अँगालो हाल्नेछन् र थकित भएर भन्छन्: "सबैले यसलाई प्रयोग गर्छन्, किनकि त्यहाँ कुनै विवेकी विकल्पहरू छैनन्। हाम्रो मुसा रुन्छ, चुच्चो, तर यो क्याक्टस संग बाँच्न जारी छ। हामी किन माया गर्छौं? किनभने यसले काम गर्छ। हामी किन माया गर्दैनौं? किनभने नयाँ संस्करणहरू लगातार बाहिर आउँदैछन् जसले नयाँ सुविधाहरू प्रयोग गर्दछ। र तपाईले क्लस्टरलाई बारम्बार अपडेट गर्नुपर्छ। र पुरानो संस्करणहरू काम गर्न बन्द छन्, किनभने त्यहाँ एक षड्यन्त्र र एक ठूलो रहस्यमय shamanism छ।

तर, विकासकर्ताहरुले भने यस्तो दाबी गरेका छन् प्रमाणपत्र-प्रबन्धक 1.0 सबै परिवर्तन हुनेछ।

के हामी पत्याउने?

Cert-manager मूल Kubernetes प्रमाणपत्र व्यवस्थापन नियन्त्रक हो। यसलाई विभिन्न स्रोतहरूबाट प्रमाणपत्रहरू जारी गर्न प्रयोग गर्न सकिन्छ: Let's Encrypt, HashiCorp Vault, Venafi, हस्ताक्षर र स्व-हस्ताक्षरित कुञ्जी जोडीहरू। यसले तपाइँलाई म्याद समाप्ति मिति द्वारा कुञ्जीहरू अप-टु-डेट राख्न अनुमति दिन्छ, र तिनीहरूको म्याद समाप्त हुनु अघि निश्चित समयमा स्वचालित रूपमा प्रमाणपत्रहरू नवीकरण गर्ने प्रयास गर्दछ। Cert-manager kube-lego मा आधारित छ र kube-cert-manager जस्ता अन्य समान परियोजनाहरूबाट केही चालहरू पनि प्रयोग गरेको छ।

रिलिज नोटहरू

संस्करण १.० को साथ, हामीले प्रमाणपत्र-प्रबन्धक परियोजनाको विकासको तीन वर्षको लागि विश्वासको चिन्ह राख्यौं। यस समयमा, यसले कार्यक्षमता र स्थिरतामा उल्लेखनीय रूपमा विकसित भएको छ, तर सबै भन्दा धेरै समुदायमा। आज, हामी धेरै मानिसहरूले यसलाई आफ्नो Kubernetes क्लस्टरहरू सुरक्षित गर्नका साथै इकोसिस्टमका विभिन्न भागहरूमा प्रयोग गरिरहेको देख्छौं। पछिल्लो 1.0 रिलीजहरूमा धेरै बगहरू फिक्स गरिएको छ। र के टुट्नु पर्छ त्यो टुट्यो। API सँग काम गर्न धेरै भ्रमणहरूले प्रयोगकर्ताहरूसँग यसको अन्तरक्रियामा सुधार गरेको छ। हामीले 16 सामुदायिक सदस्यहरूबाट थप पुल अनुरोधहरूको साथ GitHub मा 1500 मुद्दाहरू समाधान गरेका छौं।

१.० को रिलीज संग, हामी आधिकारिक रूपमा घोषणा गर्छौं कि प्रमाणपत्र-प्रबन्धक एक परिपक्व परियोजना हो। हामी हाम्रो API संगत राख्ने वाचा पनि गर्छौं v1.

हामीलाई यी तीन वर्षमा प्रमाणपत्र-प्रबन्धक बनाउन मद्दत गर्ने सबैलाई धेरै धेरै धन्यवाद! संस्करण 1.0 आउन धेरै ठूला चीजहरू मध्ये पहिलो हुन दिनुहोस्।

रिलीज 1.0 धेरै प्राथमिकता क्षेत्रहरु संग एक स्थिर रिलीज छ:

• v1 API;

• टोली kubectl cert-manager status, समस्या विश्लेषण संग मद्दत गर्न;

• नवीनतम स्थिर Kubernetes APIs प्रयोग गर्दै;

• सुधारिएको लगिङ;

• ACME सुधारहरू।

अपग्रेड गर्नु अघि अपग्रेड नोटहरू पढ्न निश्चित हुनुहोस्।

एपीआई v1

संस्करण v0.16 ले API सँग काम गर्यो v1beta1। यसले केही संरचनात्मक परिवर्तनहरू थप्यो र एपीआई क्षेत्र कागजातमा पनि सुधार गर्यो। संस्करण 1.0 यसमा API को साथ बनाउँछ v1। यो API हाम्रो पहिलो स्थिर हो, एकै समयमा हामीले पहिले नै अनुकूलता ग्यारेन्टीहरू दिएका छौं, तर API संग v1 हामी आउने वर्षहरूको लागि अनुकूलता कायम राख्न वाचा गर्छौं।

गरिएका परिवर्तनहरू (नोट: हाम्रा रूपान्तरण उपकरणहरूले तपाईंको लागि सबै कुराको ख्याल राख्छन्):

प्रमाणपत्र:

• emailSANs अहिले बोलाइएको छ emailAddresses

• uriSANs - uris

यी परिवर्तनहरूले अन्य SAN सँग अनुकूलता थप्छन् (विषय alt नामहरू, लगभग। अनुवादक), साथै Go API सँग। हामी हाम्रो API बाट यो शब्द हटाइरहेका छौं।

अद्यावधिक गर्नुहोस्

यदि तपाइँ Kubernetes 1.16+ प्रयोग गर्दै हुनुहुन्छ भने, वेबहुकहरू रूपान्तरण गर्नाले तपाइँलाई API संस्करणहरूसँग एकैसाथ र निर्बाध रूपमा काम गर्न अनुमति दिनेछ। v1alpha2, v1alpha3, v1beta1 и v1। यीसँग, तपाइँ तपाइँको पुरानो स्रोतहरू परिवर्तन वा पुन: प्रयोग नगरी API को नयाँ संस्करण प्रयोग गर्न सक्षम हुनुहुनेछ। हामी तपाईको manifests लाई API मा स्तरवृद्धि गर्न सिफारिस गर्छौं v1, अघिल्लो संस्करणहरू चाँडै नै बहिष्कार गरिनेछ। प्रयोगकर्ताहरू legacy cert-manager को संस्करणहरूमा अझै पनि पहुँच हुनेछ v1, अपग्रेड चरणहरू फेला पार्न सकिन्छ यहाँ.

kubectl cert-manager स्थिति आदेश

हाम्रो विस्तार मा नयाँ सुधार संग kubectl प्रमाणपत्र नदिने समस्याको छानबिन गर्न सजिलो भएको छ । kubectl cert-manager status अब प्रमाणपत्रहरूसँग के भइरहेको छ भन्ने बारे धेरै जानकारी दिन्छ र प्रमाणपत्र जारी गर्ने चरण पनि देखाउँदछ।

विस्तार स्थापना पछि, तपाईं चलाउन सक्नुहुन्छ kubectl cert-manager status certificate <имя-сертификата>, जसले 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 APIs प्रयोग गर्दै

Cert-manager Kubernetes CRDs लागू गर्ने पहिलो मध्ये एक थिए। यो, र 1.11 सम्म Kubernetes संस्करणहरूको लागि हाम्रो समर्थन, यसको मतलब हामीले विरासतलाई समर्थन गर्न आवश्यक छ। apiextensions.k8s.io/v1beta1 हाम्रो CRD को लागि पनि admissionregistration.k8s.io/v1beta1 हाम्रो वेबहुकहरूको लागि। तिनीहरू अहिले बहिष्कृत छन् र संस्करण 1.22 बाट Kubernetes मा हटाइनेछ। हाम्रो 1.0 को साथ हामी अब पूर्ण समर्थन प्रस्ताव गर्दछौं apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 Kubernetes 1.16 को लागि (जहाँ तिनीहरू थपिएका थिए) र नयाँ। अघिल्लो संस्करणका प्रयोगकर्ताहरूका लागि, हामी समर्थन प्रस्ताव गर्न जारी राख्छौं v1beta1 हाम्रो मा legacy संस्करणहरू।

सुधारिएको लगिङ

यस विमोचनमा, हामीले लगिङ लाइब्रेरीलाई अद्यावधिक गरेका छौं klog/v2, Kubernetes 1.19 मा प्रयोग गरियो। हामीले लेख्ने प्रत्येक जर्नललाई उपयुक्त स्तर तोकिएको छ भनी सुनिश्चित गर्न हामी समीक्षा पनि गर्छौं। हामी यसबाट निर्देशित भयौं Kubernetes बाट निर्देशन। त्यहाँ पाँच (वास्तवमा छ, लगभग। अनुवादक) लगिङ स्तरहरू देखि सुरु हुन्छ Error (स्तर ०), जसले महत्त्वपूर्ण त्रुटिहरू मात्र छाप्छ, र समाप्त हुन्छ Trace (स्तर ५) जसले तपाईलाई के भइरहेको छ भन्ने कुरा जान्न मद्दत गर्नेछ। यस परिवर्तनको साथ, हामीले लगहरूको संख्या घटाएका छौं यदि तपाईंलाई प्रमाणपत्र-प्रबन्धक चलाउँदा डिबग जानकारी आवश्यक पर्दैन।

सुझाव: प्रमाणपत्र-प्रबन्धक पूर्वनिर्धारित रूपमा स्तर 2 मा चल्छ (Info), तपाइँ यसलाई प्रयोग गरेर ओभरराइड गर्न सक्नुहुन्छ global.logLevel Helmchart मा।

नोट: समस्या निवारण गर्दा लगहरू हेर्नु अन्तिम उपाय हो। थप जानकारीको लागि हाम्रो जाँच गर्नुहोस् नेतृत्व.

सम्पादकको n.b.: Kubernetes को हुड अन्तर्गत यो सबै कसरी काम गर्दछ भन्ने बारे थप जान्नको लागि, अभ्यास गर्ने शिक्षकहरूबाट बहुमूल्य सल्लाह, साथै गुणस्तरीय प्राविधिक सहयोग मद्दत प्राप्त गर्नुहोस्, तपाइँ अनलाइन गहनहरूमा भाग लिन सक्नुहुन्छ। Kubernetes आधार, जुन सेप्टेम्बर 28-30 मा आयोजित हुनेछ, र Kubernetes मेगाजुन अक्टोबर 14-16 सम्म हुनेछ।

ACME सुधारहरू

प्रमाणपत्र-प्रबन्धकको सबैभन्दा सामान्य प्रयोग ACME प्रयोग गरेर Let's Encrypt बाट प्रमाणपत्र जारी गर्न सम्बन्धित छ। संस्करण 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

रुचाइएको चेन

सेप्टेम्बर २९ एन्क्रिप्ट गरौं पास हुनेछ आफ्नो रूट CA मा ISRG Root। क्रस-हस्ताक्षरित प्रमाणपत्रहरू द्वारा प्रतिस्थापन गरिनेछ Identrust। यो परिवर्तनलाई प्रमाणपत्र-प्रबन्धक सेटिङहरूमा परिवर्तनहरू आवश्यक पर्दैन, यो मिति पछि जारी गरिएका सबै अद्यावधिक वा नयाँ प्रमाणपत्रहरूले नयाँ रूट CA प्रयोग गर्नेछ।

यस CA सँग प्रमाणपत्रहरू पहिले नै इन्क्रिप्ट गरौं र तिनीहरूलाई ACME मार्फत "वैकल्पिक प्रमाणपत्र श्रृंखला" को रूपमा प्रस्ताव गर्दछ। प्रमाणपत्र-प्रबन्धकको यस संस्करणमा, जारीकर्ता सेटिङहरूमा यी चेनहरूमा पहुँच सेट गर्न सम्भव छ। प्यारामिटर मा 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