🥉 🛀🏿 🤹 आइए, Kubernetes में प्रमाणपत्र-प्रबंधक के साथ SSL प्रमाणपत्रों को एन्क्रिप्ट करें 👩‍❤️‍👩 🍨 🧔🏻

इस लेख में, मैं ऐड-ऑन सर्टिफिकेट-प्रबंधक का उपयोग करके कुबेरनेट्स में इनग्रेड के लिए लेट्स एनक्रिप्ट (और न केवल) से प्रमाण पत्र के आदेश और नवीनीकरण को स्वचालित करने के बारे में बात करूंगा। लेकिन मैं समस्या के सार से संक्षिप्त परिचय के साथ शुरू करूँगा।

थोड़ा शैक्षिक कार्यक्रम

पिछली शताब्दी के शुरुआती 90 के दशक में विकसित HTTP प्रोटोकॉल ने हमारे रोजमर्रा के जीवन में इतनी मजबूती से प्रवेश किया कि इसका उपयोग किए बिना कम से कम एक दिन की कल्पना करना कठिन है। हालांकि, अपने आप में, यह किसी उपयोगकर्ता और वेब सर्वर के बीच सूचनाओं का आदान-प्रदान करते समय एक न्यूनतम स्तर की सुरक्षा भी प्रदान नहीं करता है। HTTPS ("S" - सुरक्षित) बचाव के लिए आता है: एसएसएल / टीएलएस में संचरित डेटा की पैकेजिंग का उपयोग करते हुए, इस प्रोटोकॉल ने जानकारी को अवरोधन से बचाने में खुद को साबित किया है और उद्योग द्वारा सक्रिय रूप से प्रचारित किया जाता है।

उदाहरण के लिए, Google ने 2014 का पालन किया है"HTTPS हर जगह" स्थिति और यहां तक कि खोज परिणामों में इसके बिना साइटों की प्राथमिकता को कम करती है। यह "प्रचार" आम उपभोक्ताओं को या तो बाईपास नहीं करता है: आधुनिक ब्राउज़रों ने अपने उपयोगकर्ताओं को विज़िट की गई साइटों के लिए एसएसएल प्रमाणपत्रों की उपस्थिति और शुद्धता के बारे में चेतावनी दी है।

एक व्यक्तिगत साइट के लिए एक प्रमाण पत्र की लागत दसियों डॉलर से शुरू होती है। हमेशा इसे खरीदना उचित और उचित नहीं है। सौभाग्य से, 2015 के अंत से, लेट्स एनक्रिप्ट (LE) प्रमाण पत्र के रूप में एक मुफ्त विकल्प उपलब्ध है । यह गैर-लाभकारी परियोजना मोज़िला के उत्साही लोगों द्वारा बनाई गई थी ताकि अधिकांश वेबसाइटों को एन्क्रिप्शन के साथ कवर किया जा सके।

प्रमाणपत्र प्राधिकरण डोमेन-मान्य प्रमाणपत्र जारी करता है(बाजार में उपलब्ध लोगों के बीच सबसे सरल) 90 दिनों की वैधता अवधि के साथ, और कई वर्षों के लिए अब कई उपडोमेन के लिए तथाकथित वाइल्डकार्ड प्रमाणपत्र जारी किया गया है।

प्रमाण पत्र प्राप्त करने के लिए, साइट विशेष रूप से लेट्स एनक्रिप्ट के लिए बनाई गई स्वचालित प्रमाणपत्र प्रबंधन पर्यावरण (ACME) प्रोटोकॉल में वर्णित एल्गोरिदम का उपयोग करती है । इसका उपयोग करते समय, डोमेन स्वामित्व की पुष्टि एक विशिष्ट HTTP कोड (जिसे HTTP-01 कहा जाता है ) या DNS रिकॉर्ड्स (DNS-01) की स्थापना के माध्यम से अनुरोध के द्वारा किया जाता है - उनके बारे में और अधिक नीचे दिया जाएगा।

प्रमाणन प्रबंधक

प्रमाणपत्र-प्रबंधक कुबेरनेट्स के लिए एक विशेष परियोजना है, जो सीए कॉन्फ़िगरेशन (प्रमाणन प्राधिकरण) के लिए CustomResourceDefinitions (इसलिए K8s - v1.12 के न्यूनतम समर्थित संस्करण पर सीमा ) और प्रमाणपत्रों के प्रत्यक्ष आदेश का एक सेट है। क्लस्टर में CRD स्थापित करना तुच्छ है और एक YAML फ़ाइल का उपयोग करने के लिए नीचे आता है :

kubectl create ns cert-manager
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v0.13.0/cert-manager.yaml

( नहीं है । यह भी पतवार का उपयोग कर स्थापित करने की संभावना)

आदेश प्रक्रिया आरंभ करने के लिए, प्रमाणीकरण अधिकारियों (सीए) के संसाधनों क्लस्टर में घोषित किया जाना चाहिए: Issuerया ClusterIssuer, - सीएसआर (प्रमाण पत्र जारी करने के अनुरोध) पर हस्ताक्षर करने के लिए उपयोग किया जाता है। पहले संसाधन और दूसरे के बीच अंतर गुंजाइश में है:

Issuer एक ही नाम स्थान के भीतर इस्तेमाल किया जा सकता है,
ClusterIssuer एक वैश्विक क्लस्टर ऑब्जेक्ट है।

प्रमाणित-प्रबंधक के साथ अभ्यास करें

नंबर 1। स्व हस्ताक्षरित प्रमाण पत्र

आइए सबसे सरल मामले से शुरू करें - एक स्व-हस्ताक्षरित प्रमाण पत्र का आदेश देना। यह विकल्प काफी आम है, उदाहरण के लिए, डेवलपर्स के लिए गतिशील परीक्षण वातावरण के लिए या बाहरी ट्रैफ़िक का उपयोग करने के मामले में जो एसएसएल ट्रैफ़िक को समाप्त करता है।

संसाधन Issuerइस तरह दिखेगा:

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: selfsigned
spec:
  selfSigned: {}

और एक प्रमाण पत्र जारी करने के लिए, संसाधन का वर्णन करना आवश्यक है Certificate, जहां यह इंगित किया जाता है कि इसे कैसे जारी किया जाए ( issuerRefनीचे अनुभाग देखें) और जहां निजी कुंजी (फ़ील्ड secretName) स्थित है। उसके बाद, Ingress को इस कुंजी को देखना होगा (अनुभाग tlsc देखें spec):

---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: selfsigned-crt
spec:
  secretName: tls-secret
  issuerRef:
    kind: Issuer
    name: selfsigned
  commonName: "yet-another.website"
  dnsNames:
  - "yet-another.website"
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: app
spec:
  tls:
  - hosts:
    - "yet-another.website"
    secretName: tls-secret
  rules:
  - host: "yet-another.website"
    http:
      paths:
      - path: /
        backend:
          serviceName: app
          servicePort: 8080

इन संसाधनों को क्लस्टर में जोड़ने के कुछ सेकंड बाद, प्रमाणपत्र जारी किया जाएगा। आप कमांड के आउटपुट में संबंधित रिपोर्ट देख सकते हैं:

kubectl -n app describe  certificate selfsigned-crt
...
  Normal  GeneratedKey  5s    cert-manager  Generated a new private key
  Normal  Requested     5s    cert-manager  Created new CertificateRequest resource "selfsigned-crt-4198958557"
  Normal  Issued        5s    cert-manager  Certificate issued successfully

यदि आप स्वयं गुप्त संसाधन को देखते हैं, तो इसमें निम्न शामिल हैं:

निजी कुंजी tls.key,
रूट प्रमाणपत्र ca.crt,
हमारे स्व-हस्ताक्षरित प्रमाण पत्र tls.crt।

इन फ़ाइलों की सामग्री को उपयोगिता का उपयोग करके देखा जा सकता है openssl, उदाहरण के लिए, इस तरह:

kubectl -n app get secret tls-secret -ojson | jq -r '.data."tls.crt"' | base64 -d | openssl x509 -dates -noout -issuer
notBefore=Feb 10 21:01:59 2020 GMT
notAfter=May 10 21:01:59 2020 GMT
issuer=O = cert-manager, CN = yet-another.website

यह ध्यान देने योग्य है कि सामान्य मामले में, इसका उपयोग करते हुए जारी किए गए प्रमाण पत्र परIssuer संबंधित ग्राहकों द्वारा भरोसा नहीं किया जाएगा । कारण सरल है: इसमें CA नहीं है ( प्रोजेक्ट वेबसाइट पर नोट देखें ) । इससे बचने के लिए, आपको Certificateगुप्त फ़ाइल के पथ में निर्दिष्ट करना होगा जहां यह निहित है ca.crt। यह एक कॉर्पोरेट सीए संगठन हो सकता है - एक कुंजी के साथ जारी किए गए प्रमाणपत्रों पर हस्ताक्षर करने के लिए जो पहले से ही अन्य सर्वर सेवाओं / सूचना प्रणालियों की जरूरतों के लिए उपयोग किया जाता है।

नंबर 2। चलो HTTP सत्यापन के साथ प्रमाणपत्र एन्क्रिप्ट करें

LE प्रमाणपत्र जारी करने के लिए, जैसा कि पहले उल्लेख किया गया है, दो प्रकार के डोमेन स्वामित्व की पुष्टि उपलब्ध है : HTTP-01 और DNS-01।

पहले दृष्टिकोण (HTTP-01) है एक अलग तैनाती, लिंक के माध्यम से इंटरनेट से भेज दिया जाएगा साथ एक छोटी सी वेब सर्वर शुरू करने के लिए <your_domain > /। प्रसिद्ध / एक्मे-चुनौती / <टोकन> कुछ डेटा प्रमाणीकरण सर्वर से अनुरोध किया। इसलिए, यह विधि पोर्ट 80 पर बाहर से आईएनजी की उपलब्धता और डोमेन के DNS रिकॉर्ड को सार्वजनिक आईपी पते में हल करने का मतलब है।

जारी प्रमाणपत्र (DNS-01) को सत्यापित करने का दूसरा विकल्प आता हैडोमेन रिकॉर्ड की मेजबानी करने वाले DNS सर्वर के लिए एपीआई होने से। जारीकर्ता, संकेतित टोकन का उपयोग करते हुए, डोमेन पर TXT रिकॉर्ड बनाता है, जिसे ACME सर्वर तब पुष्टि के दौरान प्राप्त करता है। आधिकारिक तौर पर समर्थित DNS प्रदाताओं में CloudFlare, AWS Route53, Google CloudDNS और अन्य हैं, जिनमें इसका स्वयं का कार्यान्वयन ( acme-dns ) भी शामिल है।

नोट : मान लें कि Encrypt के पास ACME सर्वर के अनुरोधों पर काफी सख्त सीमाएँ हैं। लंबे प्रतिबंध में नहीं आने के लिए, डिबगिंग के लिए लेटेन्सक्रिप्ट-स्टेजिंग प्रमाणपत्र प्रकार का उपयोग करने की सिफारिश की जाती है (अंतर केवल एसीएमई सर्वर में है)।

इसलिए, हम संसाधनों का वर्णन करते हैं:

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory 
    privateKeySecretRef:
      name: letsencrypt
    solvers:
    - http01:
       ingress:
         class: nginx
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: le-crt
spec:
  secretName: tls-secret
  issuerRef:
    kind: Issuer
    name: letsencrypt
  commonName: yet-another.website
  dnsNames:
  - yet-another.website

ध्यान दें कि स्टेजिंग सर्वर का पता servery acme(c Issuer) के रूप में निर्दिष्ट है । इसे एक लड़ाई के साथ बदलें बाद में संभव होगा। इस कॉन्फ़िगरेशन को लागू करते हुए, हम पूरे ऑर्डर पथ का पता लगाते हैं:

सृजन Certificateने एक नया संसाधन पैदा किया CertificateRequest:
```
kubectl -n app describe certificate le-crt
...
Created new CertificateRequest resource "le-crt-1127528680"
```

उनके विवरण में - निर्माण पर एक निशान Order:

kubectl -n app describe certificaterequests le-crt-1127528680
…
Created Order resource app/le-crt-1127528680-1805948596

यह Orderबताता है कि परीक्षण किन मापदंडों से गुजरता है और इसकी वर्तमान स्थिति क्या है। इस तरह का सत्यापन संसाधन द्वारा किया जाता है Challenge:
```
kubectl -n app describe order le-crt-1127528680-1805948596
…
Created Challenge resource "le-crt-1127528680-1805948596-1231544594" for domain "yet-another.website"
```

अंत में, इस संसाधन के विवरण में स्कैन की स्थिति के बारे में जानकारी है:

kubectl -n app describe challenges le-crt-1127528680-1805948596-1231544594
...
  Reason:      Successfully authorized domain                                                                                                                                                                      
...
  Normal  Started         2m45s  cert-manager  Challenge scheduled for processing
  Normal  Presented       2m45s  cert-manager  Presented challenge using http-01 challenge mechanism
  Normal  DomainVerified  2m22s  cert-manager  Domain "yet-another.website" verified with "http-01" validation

यदि सभी शर्तों को पूरा किया गया है (यानी डोमेन बाहर से सुलभ है, तो LE से कोई प्रतिबंध नहीं है ...) - एक मिनट से भी कम समय में, प्रमाण पत्र जारी किया जाएगा। सफल होने पर आउटपुट में एक describe certificate le-crtरिकॉर्ड दिखाई देगा Certificate issued successfully।

अब आप सुरक्षित रूप से मुकाबला करने के लिए सर्वर पते को बदल सकते हैं ( https://acme-v02.api.letsencrypt.org/directory) और पहले से ही हस्ताक्षरित असली प्रमाण पत्रों को फिर से ऑर्डर करें Fake LE Intermediate X1, लेकिन नहीं Let's Encrypt Authority X3।

ऐसा करने के लिए, आपको पहले संसाधन को हटाने की आवश्यकता है Certificate: अन्यथा, कोई भी आदेश प्रक्रिया सक्रिय नहीं है, क्योंकि प्रमाणपत्र पहले से मौजूद है और यह प्रासंगिक है। एक रहस्य को हटाने से एक संदेश के साथ इसकी तत्काल वापसी होगी describe certificate:

  Normal  PrivateKeyLost  44s                   cert-manager  Lost private key for CertificateRequest "le-crt-613810377", deleting old resource

यह Issuerपहले से ही ऊपर वर्णित Certificate(यह नहीं बदला गया है) के लिए "मुकाबला" घोषणापत्र लागू करने के लिए रहता है :

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt
    solvers:
    - http01:
       ingress:
         class: nginx

संदेश प्राप्त करने के बाद Certificate issued successfully, describeइसे जांचें:

kubectl -n app get secret tls-secret -ojson | jq -r '.data."tls.crt"' | base64 -d | openssl x509 -dates -noout -issuer
notBefore=Feb 10 21:11:48 2020 GMT
notAfter=May 10 21:11:48 2020 GMT
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

संख्या 3। डीएनएस सत्यापन के साथ वाइल्डकार्ड ले

हम साइट के सभी उप-डोमेन के लिए तुरंत एक प्रमाण पत्र लिखकर और इस बार DNS चेक (CloudFlare के माध्यम से) का उपयोग करके कार्य को जटिल करेंगे।

सबसे पहले, एपीआई के माध्यम से काम करने के लिए CloudFlare कंट्रोल पैनल में टोकन प्राप्त करें:

प्रोफ़ाइल → एपीआई टोकन → टोकन बनाएँ।
अनुमतियाँ निम्नानुसार सेट करें:
- अनुमतियां:
  - क्षेत्र - DNS - संपादित करें
  - जोन - ज़ोन - पढ़ें
- क्षेत्र संसाधन:
  - शामिल करें - सभी क्षेत्र
बचत के बाद प्राप्त टोकन की प्रतिलिपि बनाएँ (उदाहरण के लिए :) y_JNkgQwkroIsflbbYqYmBooyspN6BskXZpsiH4M।

एक सीक्रेट बनाएं जिसमें यह टोकन स्टोर किया जाएगा, और इसे जारीकर्ता में देखें:

apiVersion: v1
kind: Secret
metadata:
  name: cloudflare-api-token
type: Opaque
stringData:
  api-token: y_JNkgQwkroIsflbbYqYmBooyspN6BskXZpsiH4M
---
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory 
    privateKeySecretRef:
      name: letsencrypt
    solvers:
    - dns01:
        cloudflare:
          email: my-cloudflare-acc@example.com
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token

---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: le-crt
spec:
  secretName: tls-secret
  issuerRef:
    kind: Issuer
    name: letsencrypt
  commonName: yet-another.website
  dnsNames:
  - "yet-another.website"
  - "*.yet-another.website"

(यदि आप प्रयोग कर रहे हैं, तो मंचन का उपयोग करना न भूलें!)

डोमेन के स्वामित्व की पुष्टि करने की प्रक्रिया के माध्यम से जाने दें:

kubectl -n app describe challenges.acme.cert-manager.io le-crt-613810377-1285319347-3806582233
...
Status:
  Presented:   true
  Processing:  true
  Reason:      Waiting for dns-01 challenge propagation: DNS record for "yet-another.website" not yet propagated
  State:       pending
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Started    54s   cert-manager  Challenge scheduled for processing
  Normal  Presented  53s   cert-manager  Presented challenge using dns-01 challenge mechanism

पैनल में एक TXT रिकॉर्ड दिखाई देगा:

... और थोड़ी देर बाद स्थिति बदल जाएगी:

Domain "yet-another.website" verified with "dns-01" validation

सुनिश्चित करें कि प्रमाण पत्र किसी भी उपडोमेन के लिए मान्य है:

kubectl -n app get secret tls-secret -ojson | jq -r '.data."tls.crt"' | base64 -d | openssl x509 -dates -noout -text |grep DNS:
          DNS:*.yet-another.website, DNS:yet-another.website

डीएनएस द्वारा सत्यापन, एक नियम के रूप में, जल्दी से नहीं होता है, क्योंकि अधिकांश डीएनएस प्रदाताओं में एक डेटा अपडेट अवधि होती है, जो यह दर्शाती है कि डीएनएस रिकॉर्ड को पल भर में कितना समय बीत जाता है, यह सभी प्रदाता के डीएनएस सर्वर के वास्तविक अपडेट में बदल जाता है। हालांकि, ACME मानक दो सत्यापन विकल्पों का एक संयोजन भी प्रदान करता है, जिसका उपयोग मुख्य डोमेन के लिए प्रमाण पत्र की प्राप्ति में तेजी लाने के लिए किया जा सकता है। इस मामले में, विवरण Issuerइस प्रकार होगा:

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt
    solvers:
    - selector:
        dnsNames:
        - "*.yet-another.website"
      dns01:
        cloudflare:
          email: my-cloudflare-acc@example.com
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token            
    - selector:
        dnsNames:
        - "yet-another.website"
      http01:
        ingress:
          class: nginx

यदि आप इस कॉन्फ़िगरेशन को लागू करते हैं, तो दो संसाधन बनाए जाएंगे Challenge:

kubectl -n app describe orders le-crt-613810377-1285319347
…
  Normal  Created  3m29s  cert-manager  Created Challenge resource "le-crt-613810377-1285319347-3996324737" for domain "yet-another.website"                 
  Normal  Created  3m29s  cert-manager  Created Challenge resource "le-crt-613810377-1285319347-1443470517" for domain "yet-another.website"

चार नंबर। इनग्रेशन स्पेशल एनोटेशन का उपयोग करना

सर्टिफिकेट-मैनेजर में प्रमाण पत्र बनाने के लिए सीधे रास्ते के अलावा, इंग्रेस-शिम नामक एक घटक का उपयोग करना संभव है और स्पष्ट रूप से संसाधन बनाना नहीं है Certificate। विचार यह है कि विशेष इनग्रेड एनोटेशन की मदद से, सर्टिफिकेट को स्वचालित रूप से उनके द्वारा इंगित किए गए का उपयोग करके ऑर्डर किया जाएगा Issuer। परिणाम लगभग निम्नलिखित संसाधन है:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  tls:
  - hosts:
    - "yet-another.website"
    secretName: tls-secret
  rules:
  - host: "yet-another.website"
    http:
      paths:
      - path: /
        backend:
          serviceName: app
          servicePort: 8080

सही संचालन के लिए, केवल जारीकर्ता की उपस्थिति यहां पर्याप्त है, अर्थात एक कम इकाई का निर्माण।

इसके अलावा, एक अप्रचलित एनोटेशन क्यूब-लेगो है - kubernetes.io/tls-acme: "true", - जिसे Issuerहेल्म मापदंडों (या प्रबंधक कंटेनर लॉन्च विकल्पों में) का उपयोग करके प्रमाणित-प्रबंधक स्थापित करते समय डिफ़ॉल्ट नौकरी की आवश्यकता होती है ।

हम कंपनी में इन विकल्पों का उपयोग नहीं करते हैं और एसएसएल प्रमाणपत्र (और एक ही समय में विभिन्न समस्याओं के लिए एक ही समय में ) का उपयोग करने के लिए उपयोग किए जाने वाले दृष्टिकोण की अस्पष्टता के कारण उन्हें सलाह नहीं दे सकते हैं , लेकिन फिर भी अधिक संपूर्ण चित्र के लिए लेख में उल्लेख करने का निर्णय लिया।

एक निष्कर्ष के बजाय

CRD के साथ सरल जोड़तोड़ के माध्यम से, हमने सीखा कि ऑटो-अक्षय, स्व-हस्ताक्षरित, और Kubernetes समूहों में Ingresss के हिस्से के रूप में शुरू की गई वेबसाइट डोमेन के लिए एनक्रिप्ट प्रोजेक्ट से फ्री SSL प्रमाणपत्र कैसे बनाए जाते हैं।

लेख हमारे अभ्यास में सबसे आम समस्याओं को हल करने के उदाहरण प्रदान करता है। हालांकि, प्रमाणित-प्रबंधक फ़ंक्शन ऊपर वर्णित सुविधाओं तक सीमित नहीं हैं। उपयोगिता वेबसाइट पर आप अन्य सेवाओं के साथ काम करने के उदाहरण पा सकते हैं - उदाहरण के लिए, वॉल्ट के साथ एक बंडल या बाहरी जारी करने वाले केंद्र (जारीकर्ता) का उपयोग।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

आइए, Kubernetes में प्रमाणपत्र-प्रबंधक के साथ SSL प्रमाणपत्रों को एन्क्रिप्ट करें