3,151 रीडिंग

एज़्योर के एसएसएल सर्टिफिकेट की खोज: लेट्स एनक्रिप्ट के साथ हमारी यात्रा

द्वारा Social Discovery Group10m2023/04/21

बहुत लंबा; पढ़ने के लिए

एसएसएल प्रमाणपत्रों के साथ संघर्ष कर रहे हैं? सोशल डिस्कवरी ग्रुप में लीड DevOps इंजीनियर, पावेल शापुरौ, यह सब कवर करते हैं। लेख में, वह एक अनुकूलित समाधान कॉन्फ़िगरेशन साझा करता है जो लेट्स एनक्रिप्ट सर्टिफिकेट और रास्ते में सीखे गए पाठों का उपयोग करता है।

featured image - एज़्योर के एसएसएल सर्टिफिकेट की खोज: लेट्स एनक्रिप्ट के साथ हमारी यात्रा

एक वेब परियोजना की तैनाती करते समय, एसएसएल प्रमाणपत्र कार्यान्वयन एक आम चुनौती है जिसका सामना हर इंजीनियर को करना पड़ सकता है - और मैं कोई अपवाद नहीं हूं।

आमतौर पर, स्टार्टअप लेट्स एनक्रिप्ट जैसे मुफ्त प्रमाणपत्रों का विकल्प चुनते हैं। हालाँकि, ये विचार करने के लिए सीमाओं और असुविधाओं के साथ आते हैं, जो पर विस्तृत हैं।

निःशुल्क प्रमाणपत्रों के साथ व्यक्तिगत रूप से जिन समस्याओं का मैंने सामना किया है, उन पर करीब से नज़र डालते हैं:

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

नियमित आधार पर इन मुद्दों का सामना करने के बाद, मैंने एक अनुकूलित समाधान कॉन्फ़िगरेशन विकसित किया है जो लेट्स एनक्रिप्ट प्रमाणपत्रों का उपयोग करता है। इस लेख में, मैं अपने निष्कर्षों और रास्ते में सीखे गए पाठों को साझा करूँगा।

हाल ही में, मैं एक विशिष्ट प्रौद्योगिकी स्टैक पर ध्यान केंद्रित कर रहा हूं और एज़्योर क्लाउड प्रदाता के संदर्भ में कुबेरनेट्स क्लस्टर-आधारित बुनियादी ढाँचे के समाधान पर चर्चा करना चाहता हूँ। जबकि प्रमाणित प्रबंधक इस क्षेत्र में एक लोकप्रिय समाधान है, मैं इसे अधिक सुविधा के लिए हेल्म के माध्यम से स्थापित करना पसंद करता हूं।

तो, आगे की हलचल के बिना, आइए सीधे इसमें गोता लगाएँ:

 helm repo add jetstack https: //charts.jetstack.io
helm repo update kubectl apply -f https: //github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.crds.yaml
helm install cert-manager jetstack/cert-manager -- namespace cert - manager -- create - namespace -- version v1 . 6 . 1

उसके बाद, हम निम्नलिखित YAML फ़ाइल का उपयोग करके एक ClusterIssuer बना सकते हैं:

 apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-cluster-issuer
spec:
  acme:
    server: //acme-v02.api.letsencrypt.org/directory
    email: p…[email protected]   #your e-mail
    privateKeySecretRef:
      name: letsencrypt-cluster-issuer
    solvers:
      - http01:
          ingress:
            class: nginx

आगे बढ़ते हुए, प्रमाणपत्रों को लागू करने के लिए दो विकल्प हैं:

"तरह: प्रमाणपत्र" जोड़कर प्रमाण पत्र बनाना;
अपने प्रवेश के माध्यम से प्रमाण पत्र प्रबंधित करना।

आइए दोनों विकल्पों का पता लगाएं।

पहले परिदृश्य में, मेरी YAML फाइलें इस तरह दिखती थीं:

 apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: myservice2  namespace : test
Spec :  duration : 2160h
  renewBefore : 72h
  dnsNames : - myservice2 . mydomain . org # you resources
  secretName : myservice2 - tls
  issuerRef :    name : letsencrypt - cluster - issuer
    kind : ClusterIssuer

यह उल्लेखनीय है कि किसी विशेष सेवा के लिए टीएलएस अनुभाग में प्रवेश में केवल "गुप्तनाम: myservice2-tls" का उल्लेख किया गया था। वैसे, YAML फ़ाइल में कुछ उपयोगी पैरामीटर होते हैं, जैसे:

अवधि: 48h - घंटे में प्रमाण पत्र की अवधि का संकेत
नवीनीकरण इससे पहले: 24 घंटे - यह निर्दिष्ट करते हुए कि प्रमाणपत्र समाप्त होने से कितने घंटे पहले, आप मौजूदा प्रमाणपत्र को नवीनीकृत करने का प्रयास कर सकते हैं

यदि आप कंसोल के साथ काम करने में अधिक सहज हैं, तो मैं आपको एक उदाहरण के रूप में प्रमाण पत्र का एक व्यापक दृश्य प्रदान करता हूं।

 kubectl describe certificates <cert name > -n <namespace name >

तो, आखिर में हमारे पास क्या है?

बाद में नहीं - प्रमाणपत्र की समाप्ति तिथि;
इससे पहले नहीं - प्रमाणपत्र की निर्माण तिथि (जब तक कि प्रमाणपत्र YAML संसाधन क्षेत्र में स्पष्ट रूप से निर्दिष्ट न हो);
नवीनीकरण समय - प्रमाणपत्र समाप्त होने से पहले का टाइमस्टैम्प।

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

 annotations : cert-manager .io/cluster-issuer: "letsencrypt-cluster-issuer" cert-manager .io/renew-before: 72h

और वहां आपके पास यह है, इसका जादू! इस उदाहरण में समाप्त होने से पहले तीन दिन की बफर अवधि के साथ प्रमाणपत्र अब स्वचालित रूप से फिर से जारी किए जाते हैं। यह ध्यान देने योग्य है कि लेट्स एनक्रिप्ट के मामले में, डिफ़ॉल्ट अवधि 90 दिन है। हालांकि, लेट्स एनक्रिप्ट से मुक्त प्रमाणपत्रों की सीमाओं के कारण, हमारी टीम ने अंततः एक व्यापक प्रमाणपत्र की आवश्यकता पर विचार किया जो न केवल हमारे डोमेन बल्कि उप डोमेन की भी सुरक्षा कर सके। जैसा कि हमने एज़्योर पर अपनी परियोजना को विकसित करना जारी रखा, हमने पाया कि एज़्योर की वॉल्ट ने ऐसे प्रमाणपत्रों को संग्रहीत करने के लिए एक सुविधाजनक स्थान प्रदान किया। हम अपने कुबेरनेट्स क्लस्टर के भीतर akv2k8s यूटिलिटी का उपयोग कर रहे हैं। यदि आप रुचि रखते हैं, तो मैं आपको के लिए प्रोत्साहित करता हूं।

एज़्योर की वॉल्ट क्या है

Azure में प्रमाणपत्र प्राप्त करने के बाद, अगला चरण इसे Azure Key Vault (AKV) में जोड़ना है। हालांकि यह प्रक्रिया अपेक्षाकृत सीधी है, डोमेन स्वामित्व की पुष्टि करना थोड़ा मुश्किल हो सकता है। हालाँकि, एक बार सभी पुष्टि चरणों के सफलतापूर्वक पूरा हो जाने के बाद, प्रमाणपत्र कुंजी कोष्ठ के "रहस्य" खंड में दिखाई देगा। इस दृष्टिकोण के प्रमुख लाभों में से एक स्वचालित प्रमाणपत्र नवीनीकरण है। एक वर्ष के बाद प्रमाण पत्र को फिर से जारी किया जाएगा और एकेवी में अपडेट किया जाएगा, और यह कुबेरनेट्स में गुप्त के साथ स्वचालित रूप से सिंक्रनाइज़ हो जाएगा।

Kubernetes क्लस्टर के लिए अधिग्रहीत प्रमाणपत्र का उपयोग करने के लिए, आपको इसे कुछ अनुमतियाँ और पहुँच अधिकार देने होंगे। ऐसा करने के लिए, आपको सबसे पहले क्लस्टर की identityProfile.kubeletidentity.objectId प्राप्त करनी होगी। आप निम्न कमांड का उपयोग करके ऐसा कर सकते हैं:

 az aks show -g < RG > -n < AKS_name >

संसाधन समूह (RG) वह स्थान है जहाँ क्लस्टर संग्रहीत है, और AKS_name आपके क्लस्टर का नाम है। IdentityProfile.kubeletidentity.objectId प्राप्त करने के बाद, आपको इसे कॉपी करना होगा। अगला, गुप्त पहुँच अनुमतियाँ प्रदान करने के लिए कमांड में मान जोड़ें:

 az keyvault set-policy --name < name AKV > --object-id < get from first step value > --secret-permissions get

इसके बाद, आप akv2k8s की स्थापना के साथ आगे बढ़ सकते हैं, जो में वर्णित हेल्म या अन्य पसंदीदा विधियों के माध्यम से किया जा सकता है। के बाद, आप अपने Azure Key Vault प्रमाणपत्र को एक विशेष Kubernetes नामस्थान में गुप्त के साथ सिंक्रनाइज़ कर सकते हैं। यहाँ मेरी YAML फ़ाइल है:

 apiVersion: spv.no/v1 kind: AzureKeyVaultSecret metadata: name: wildcard-cert #any name  namespace : default
spec :  vault :    name : SandboxKeyVault # name you keyvault in Azure
    object :      name : name_object_id # name object id from Azure AKV this cert
      type : secret
  output :    secret :      name : wildcard - cert # any name for secret in your namespace
      type : kubernetes . io / tls
      chainOrder : ensureserverfirst # very important values !!!

मुझे अंतिम पंक्ति के महत्व पर जोर देना चाहिए, क्योंकि इसने मेरे सामने आई एक समस्या को हल करने में महत्वपूर्ण भूमिका निभाई। प्रारंभ में, मैं प्रमाण पत्र को कुबेरनेट्स में सफलतापूर्वक अपलोड करने में सक्षम था, लेकिन यह अपेक्षा के अनुरूप काम नहीं करता था। समस्या के निदान में कुछ समय लगा। जैसा कि यह निकला, कुंजी वॉल्ट से पीएफएक्स प्रमाणपत्र निर्यात करते समय, सर्वर प्रमाणपत्र कभी-कभी श्रृंखला के अंत में स्थित होता है, जहां यह होना चाहिए। इंग्रेस-एनजीएनएक्स जैसे मापदंडों के साथ उपयोग करने पर यह समस्या पैदा कर सकता है, क्योंकि प्रमाणपत्र लोड करने में विफल रहता है और अपने मूल मूल्य पर वापस आ जाता है। हालांकि, सर्वरफर्स्ट सुनिश्चित करने के लिए चेनऑर्डर सेट करके, सर्वर सर्टिफिकेट को पहले चेन में रखा जाता है। प्रमाणपत्र के करीब से निरीक्षण करने पर, मैंने पाया कि श्रृंखला को निम्नलिखित क्रम में व्यवस्थित किया गया था:

मध्यम
जड़
सर्वर

तकनीकी पहलुओं और कॉन्फ़िगरेशन पर चर्चा करने के बाद, आइए एज़्योर प्रमाणपत्रों की ख़ासियत पर वापस जाएँ।

Azure प्रमाणपत्र ऑर्डर करने के लिए दो विकल्प प्रदान करता है, जिनमें से दोनों GoDaddy द्वारा प्रदान किए जाते हैं:

किसी विशिष्ट डोमेन या उपडोमेन के लिए प्रमाणपत्र;
एक वाइल्डकार्ड प्रमाणपत्र।

हमने बाद वाला विकल्प चुना, उम्मीद है कि यह हमारे सभी एप्लिकेशन और सेवाओं की रक्षा करेगा। हालाँकि, कुछ बारीकियाँ थीं।

Azure वाइल्डकार्ड प्रमाणपत्र केवल प्रथम-स्तरीय उप डोमेन की सुरक्षा करता है। उदाहरण के लिए, यदि हमारे पास mydomain.com नाम का एक डोमेन है, तो प्रमाणपत्र केवल .mydomain.com के रूप में प्रथम-स्तरीय उप डोमेन को कवर करेगा।

इसलिए, प्रमाणपत्र service1.mydomain.com, service2.mydomain.com, service3.mydomain.com जैसे संसाधनों के लिए काम करेगा, लेकिन यह service1.test.mydomain.com या mail.service1.mydomain.com को कवर नहीं करेगा।

फिर हमारे पास क्या विकल्प हैं?

सभी आवश्यक उप डोमेन के लिए अलग वाइल्डकार्ड प्रमाणपत्र खरीदना;
प्रमाणपत्र में SAN ( विषय वैकल्पिक नाम ) रिकॉर्ड जोड़ना।

पहला विकल्प व्यावहारिक होने की संभावना नहीं है, क्योंकि उपडोमेन की संख्या, विशेष रूप से दूसरे स्तर पर, बहुत अधिक हो सकती है। इस प्रकार, प्रत्येक उपडोमेन ( .service1.mydomain.com, *.dev.mydomain.com… ) के लिए वाइल्डकार्ड प्रमाणपत्र के लिए भुगतान करना सबसे उचित समाधान नहीं है।

दूसरे विकल्प के रूप में, मैंने इस मामले के बारे में एज़्योर सपोर्ट टीम के साथ लंबी बातचीत की, इनकार, हताशा और क्रोध के सभी चरणों से गुजरते हुए, केवल अंत में यह महसूस किया कि प्रमाणपत्रों के लिए सैन क्षमता अभी तक लागू नहीं की गई है। अंत तक, मैंने आशा की थी कि Azure पर ऐसा कोई मुद्दा कभी नहीं होगा। इसके विपरीत, उनके प्रतियोगी, AWS Amazon, अपने AWS सर्टिफिकेट मैनेजर (ACM) के माध्यम से प्रमाणपत्र प्रदान करते हैं जो वाइल्डकार्ड सहित 10 वैकल्पिक विषय नामों तक का समर्थन करते हैं। यह आपको वाइल्डकार्ड कैरेक्टर (*) के साथ 10 सबडोमेन बनाने की अनुमति देता है, और यहां तक कि 100k तक के AWS पर कोटा बढ़ाने का अनुरोध भी करता है। समाप्त करने के लिए, मैं साझा करूँगा कि आप Azure पर फ्रंट डोर सेवा के साथ प्रमाणपत्रों का उपयोग कैसे कर सकते हैं।

Azure फ्रंट डोर (AFD) को समझना

मेरे लिए, एज़्योर फ्रंट डोर (AFD) एक वैश्विक और स्केलेबल गेटवे है जो आने वाले ट्रैफ़िक को उपयुक्त एंडपॉइंट्स पर निर्देशित करने के लिए Microsoft के विश्वव्यापी एज नेटवर्क का लाभ उठाता है, जो वेब एप्लिकेशन या सेवाएं हो सकती हैं। एचटीटीपी/एचटीटीपीएस लेयर (लेयर 7) पर काम करते हुए फ्रंट डोर क्लाइंट रिक्वेस्ट को पूल से उपलब्ध एप्लिकेशन सर्वर तक पहुंचाता है। एप्लिकेशन का सर्वर-साइड कोई भी इंटरनेट-सुलभ सेवा हो सकती है, चाहे वह Azure के अंदर या बाहर होस्ट की गई हो।

प्रलेखन वेबसाइट से एक उदाहरण

एज़्योर फ्रंट डोर एक सुविधाजनक उपकरण है जो आपको दुनिया भर में वितरित अनुप्रयोगों और सेवाओं तक पहुँचने वाले आने वाले ट्रैफ़िक को संतुलित और प्रॉक्सी करने की अनुमति देता है। यह नियम हैंडलर को कॉन्फ़िगर करके, नीतियों में शामिल होने और फ़ायरवॉल सेटिंग्स द्वारा विभिन्न नियमों को बाध्य करने की क्षमता सहित कई सुविधाएँ प्रदान करता है। मैं इस लेख में AFD सेवा की बारीकियों में बहुत गहराई तक नहीं जाऊँगा, बल्कि प्रमाणपत्रों की सेवा विशिष्टताओं पर ध्यान केंद्रित करूँगा।

जैसा कि आप उम्मीद कर सकते हैं, एज़्योर फ्रंट डोर पर आने वाला ट्रैफ़िक या तो http या https हो सकता है। यदि आप https चुनते हैं, तो आपके पास तीन विकल्प हैं: Azure फ्रंट डोर सेवा पर ही एक प्रमाणपत्र जनरेट करें, अपना स्वयं का प्रमाणपत्र अपलोड करें, या अपने मौजूदा प्रमाणपत्र को Azure Key Vault में सिंक करें। फ़्रंट डोर सेवा को की वॉल्ट तक पहुँचने की अनुमति देने के लिए, आपको आवश्यक अनुमतियाँ कॉन्फ़िगर करने की आवश्यकता होगी।

मैं अंतिम विकल्प का उपयोग करने और प्रमाण पत्र के नवीनतम संस्करण का चयन करने की सलाह देता हूं ताकि इसे मैन्युअल रूप से नवीनीकृत या पुन: उत्पन्न करने से बचा जा सके। एकेवी से सर्टिफिकेट जोड़ने से सब कुछ अपने आप अपडेट रहेगा।

यह सेटअप आपको निम्न परिणाम देगा:

एज़्योर फ्रंट डोर से एकेएस तक ट्रैफ़िक निर्देशित करते समय यहां एक और ख़ासियत है।

एचटीटीपी ट्रैफ़िक को संभालना कोई समस्या नहीं है, लेकिन संसाधन पूल सेट करते समय और एकेएस क्लस्टर के बाहरी आईपी पते को निर्दिष्ट करते समय ध्यान में रखने के लिए एक सूक्ष्म विवरण है। यह सुनिश्चित करने के लिए "सर्वर घटक नोड हेडर" फ़ील्ड को खाली छोड़ना सुनिश्चित करें कि यह "आईपी या नोड नाम" फ़ील्ड में दर्ज किए गए मानों से स्वचालित रूप से पॉप्युलेट हो गया है।

मान लें कि आपके पास AKV के माध्यम से एक डोमेन वाइल्डकार्ड प्रमाणपत्र संलग्न है, जिसका उपयोग दोनों फ्रंट डोर सेवा द्वारा किया जाता है और akv2k8s के माध्यम से AKS क्लस्टर में फ़्लश किया जाता है। आपके सभी एप्लिकेशन और फ्रंट डोर के माध्यम से सुलभ सेवाओं के लिए इंटरफ़ेस होस्टनाम (और DNS में CNAME रिकॉर्ड) निम्नलिखित होगा:

*.mydomain.com - "सर्वर कंपोनेंट नोड हेडर" फ़ील्ड के साथ खाली छोड़ दिया गया;
आपके बाहरी एकेएस आईपी पते में / के लिए एक डिफ़ॉल्ट http रीडायरेक्ट नियम होगा।

यह *.mydomain.com प्रारूप में सभी सेवाओं को ठीक से कार्य करने की अनुमति देगा। एक बार जब आप इस कॉन्फ़िगरेशन को पूरा कर लेते हैं, तो आप पूरी तरह से तैयार हो जाते हैं।

कुछ परिदृश्यों में, एज़्योर फ्रंट डोर से एकेएस को https के माध्यम से ट्रैफ़िक पुनर्निर्देशित करना अधिक लाभप्रद हो सकता है। सर्वर पूल सेटिंग्स में एज़्योर फ्रंट डोर के सही कामकाज को सुनिश्चित करने के लिए, आपके एकेएस क्लस्टर के अनुरूप डीएनएस नाम निर्दिष्ट करना महत्वपूर्ण है, जो एसएनआई और स्वास्थ्य जांच से संबंधित है। अन्यथा, सेटअप काम नहीं करेगा।

मेरे मामले में, मेरे AKS समूहों को कोई नाम नहीं दिया गया था, मेरे पास केवल ऐसी सेवाएँ थीं जो पहले सीधे काम करती थीं लेकिन उन्हें Azure Front Door के माध्यम से कार्य करना पड़ता था। इसे संबोधित करने के लिए, मुझे एकेएस क्लस्टर के लिए एक अलग डीएनएस नाम बनाना था, डीएनएस को कॉन्फ़िगर करना था, और प्रवेश से जुड़े प्रमाणपत्र के साथ एक अलग सेवा स्थापित करनी थी। तभी मैं https ट्रैफ़िक को AKS क्लस्टर पर पुनर्निर्देशित कर सकता था और यह सुनिश्चित कर सकता था कि यह सभी उपलब्ध सेवाओं के लिए सही तरीके से काम करे।

AKS के लिए कनेक्शन अनुमति सेट करते समय सुरक्षा उपायों पर विचार करना महत्वपूर्ण है। एक सुरक्षित कनेक्शन सुनिश्चित करने के लिए, आप AKS के लिए नेटवर्क सुरक्षा समूह में केवल Azure Front Door IP पतों से AKS से कनेक्ट करने की अनुमति को सीमित कर सकते हैं (जैसा कि नीचे दी गई तस्वीर में दिखाया गया है)।

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

अंतिम नोट और सलाह का एक टुकड़ा

1. एज़्योर अपने प्रमाणपत्रों की विशेषताओं और कमियों के बारे में व्यापक जानकारी प्रदान नहीं करता है। हालांकि, यह उल्लेखनीय है कि उन्होंने खरीदे गए प्रमाणपत्र के लिए हमें तुरंत वापस कर दिया। 2. अपनी विकास प्रक्रिया के दौरान, हम लेट्स एनक्रिप्ट का उपयोग करना जारी रखते हैं। हालाँकि इसकी अपनी सीमाएँ हैं, यह उपलब्ध सबसे खराब विकल्प नहीं है। 3. यदि आपकी परियोजना को विभिन्न संसाधन स्तरों के साथ कई उपडोमेन की आवश्यकता है, तो आप तीसरे पक्ष के विक्रेताओं के "वाइल्डकार्ड (मल्टीडोमेन के रूप में भी जाना जाता है) SAN" प्रमाणपत्रों पर विचार करना चाह सकते हैं। इन प्रमाणपत्रों को एज़्योर में आयात किया जा सकता है और उनकी पूरी क्षमता का उपयोग किया जा सकता है। 4. सही ढंग से कॉन्फ़िगर किए जाने पर, एज़्योर फ्रंट डोर एक उत्कृष्ट सेवा है। मैं इसकी पुरजोर सलाह देता हूँ।