AWS ACM के साथ APISIX Ingress Controller का उपयोग करना

Xin Rong

December 30, 2022

Ecosystem

हमें AWS ACM की आवश्यकता क्यों है?

मैनुअल प्रबंधन से उत्पन्न समस्याएं

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

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

प्रमाणपत्र के बाधित होने के जोखिम से बचने और नई जानकारी और नियमों के अनुसार स्वचालित अपडेट रखने के लिए, स्वचालित प्रमाणपत्र प्रबंधन सामने आया है, जो प्रमाणपत्र समाप्ति के जोखिम को कम करता है और डेवलपर्स के बोझ को कम करता है।

ACM प्रमाणपत्रों को स्वचालित रूप से प्रबंधित करता है

AWS Certificate Manager (ACM) SSL/TLS प्रमाणपत्रों को आसानी से प्रावधान, प्रबंधन, तैनात और नवीनीकृत कर सकता है। आप ACM के माध्यम से सीधे प्रमाणपत्र जारी कर सकते हैं ताकि आपकी AWS वेबसाइट्स और एप्लिकेशन्स को सुरक्षित किया जा सके या तीसरे पक्ष के प्रमाणपत्रों को ACM प्रबंधन प्रणाली में आयात कर सकते हैं।

ACM के साथ, आपको पहले की तरह SSL/TLS प्रमाणपत्रों का उपयोग और प्रबंधन करने से जुड़े व्यापक मैनुअल प्रक्रियाओं से गुजरने की आवश्यकता नहीं है। आप AWS Private CA द्वारा हस्ताक्षरित ACM प्रमाणपत्रों को अपने आंतरिक PKI के भीतर किसी भी स्थान पर उपयोग करने के लिए निर्यात भी कर सकते हैं। इसके अलावा, यह AWS Elastic Load Balancing (ELB) के साथ एकीकृत है।

acm

ACM Private CA किन समस्याओं का समाधान करता है?

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

ACM Private CA एक उच्च उपलब्धता वाली होस्टेड सेवा है जो आपके संगठन के लिए एक आंतरिक PKI बनाती और बनाए रखती है, जो निरंतर रखरखाव की लागत को समाप्त करती है। निजी कुंजियों को AWS द्वारा होस्टेड हार्डवेयर सुरक्षा मॉड्यूल (HSM) में संग्रहीत किया जाता है जो FIPS 140-2 द्वारा मान्य होते हैं, जो Kubernetes में डिफ़ॉल्ट CA की तुलना में अधिक सुरक्षित प्रमाणपत्र जारी करने वाले संगठनों का समाधान प्रदान करता है।

pca

Kubernetes के साथ ACM का उपयोग कैसे करें?

Kubernetes में TLS प्रमाणपत्रों को समाप्त करने के लिए दो अलग-अलग कॉन्फ़िगरेशन हैं:

Configurations

  • Ingress में TLS प्रमाणपत्रों को समाप्त करना: जब एप्लिकेशन्स के बीच एन्क्रिप्शन की आवश्यकता होती है, तो हमें Ingress कंट्रोलर में TLS को समाप्त करने की आवश्यकता होती है। प्रत्येक एप्लिकेशन Ingress के माध्यम से अपने प्रमाणपत्र का प्रबंधन कर सकता है बिना एक-दूसरे के हस्तक्षेप के। यह विधि कॉन्फ़िगर और प्रबंधित करने में आसान है और यह सुनिश्चित करती है कि एप्लिकेशन्स के बीच संचार विश्वसनीय है।
  • NLB में TLS प्रमाणपत्रों को समाप्त करना: NLB स्तर पर TLS प्रमाणपत्रों को समाप्त करना सार्वजनिक रूप से विश्वसनीय प्रमाणपत्रों का उपयोग करने का सबसे आम उपयोग मामला है। यह विधि NLB को ACM सार्वजनिक रूप से विश्वसनीय प्रमाणपत्र को बांधने के लिए कॉन्फ़िगर करने में आसान है। आंतरिक क्लस्टर में एप्लिकेशन्स तक पहुंच अभी भी HTTP का उपयोग करती है बिना किसी अतिरिक्त एन्क्रिप्शन और डिक्रिप्शन ऑपरेशन के।

निम्नलिखित उदाहरणों में, आप Amazon EKS पर सीधे APISIX Ingress को कॉन्फ़िगर कर सकते हैं। इन दोनों विधियों का उपयोग करके, हम प्रदर्शित करेंगे कि APISIX Ingress ACM (और ACM Private CA) के साथ कैसे काम करता है।

पूर्वापेक्षाएं

शुरू करने से पहले, हमें निम्नलिखित आवश्यकताओं को पूरा करना चाहिए:

  • AWS एक AWS खाता और AWS कमांड लाइन इंटरफ़ेस (AWS CLI)
  • आपके पास Amazon EKS IAM भूमिका और सेवा-संबंधित भूमिकाओं AWS CloudFormation, Amazon Virtual Private Cloud (Amazon VPC) और संबंधित संसाधनों का उपयोग करने की अनुमति होनी चाहिए। कृपया IAM उपयोगकर्ता मैनुअल में इस लेख की जांच करें "Amazon Elastic Container Service for Kubernetes के लिए ऑपरेशन्स, संसाधन और स्थिति कुंजियाँ" और सेवा-संबंधित भूमिकाओं का उपयोग करें। इसके अलावा, इस IAM सुरक्षा प्रिंसिपल को AWSCertificateManagerPrivateCAFullAccess IAM प्रबंधित नीति संलग्न होनी चाहिए।
  • kubectl और eksctl टूल्स को इंस्टॉल और कॉन्फ़िगर करें।

Amazon EKS क्लस्टर

Amazon EKS एक होस्टेड सेवा है जो आपको AWS पर Kubernetes चलाने और आसानी से अपने Kubernetes क्लस्टर्स को तैनात और प्रबंधित करने की अनुमति देती है। यह लेख क्लस्टर्स को प्रबंधित करने के लिए eksctl कमांड टूल का उपयोग करेगा।

  • eksctl डिफ़ॉल्ट कॉन्फ़िगरेशन का उपयोग करके क्लस्टर्स बनाएं (यदि आपके पास पहले से EKS क्लस्टर है तो इस भाग को अनदेखा करें)
eksctl create cluster

APISIX Ingress इंस्टॉल करें

  1. EKS क्लस्टर में APISIX Ingress इंस्टॉल करें, और इसे LoadBalancer प्रकार पर सेट करें।
helm repo add apisix https://charts.apiseven.com
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install apisix apisix/apisix \
  --set gateway.type=LoadBalancer \
  --set gateway.tls.enabled=true \
  --set ingress-controller.enabled=true \
  --namespace ingress-apisix \
  --create-namespace

नोट:

कृपया सुनिश्चित करें कि आपका क्लस्टर स्थायी वॉल्यूम जोड़ सकता है; अधिक जानकारी के लिए Amazon EKS Storage देखें। यदि आप केवल इस ट्यूटोरियल को आज़माना चाहते हैं, तो इंस्टॉलेशन के दौरान --set etcd.persistence.enabled=false कॉन्फ़िगर करें ताकि यह घोषित किया जा सके कि स्थायी वॉल्यूम का उपयोग नहीं किया जाएगा।

  1. निम्नलिखित कमांड्स को निष्पादित करें स्थिति की जांच करने के लिए, और सुनिश्चित करें कि सभी पॉड्स Running स्थिति में हैं।
$ kubectl get pods -n ingress-apisix
NAME                                         READY   STATUS    RESTARTS   AGE
apisix-78bfc58588-qspmm                      1/1     Running   0          103s
apisix-etcd-0                                1/1     Running   0          103s
apisix-etcd-1                                1/1     Running   0          103s
apisix-etcd-2                                1/1     Running   0          103s
apisix-ingress-controller-6ff56cd4b4-rktr9   1/1     Running   0          103s
  1. NLB स्थिति की जांच करें; कृपया PORT(S) और EXTERNAL-IP पर ध्यान दें।
$ kubectl get svc apisix-gateway -n ingress-apisix
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP                                                                    PORT(S)                      AGE
apisix-gateway   LoadBalancer   10.100.178.65   a6cffe9f6fc5c47b9929cb758610fc5a-2074689558.ap-northeast-1.elb.amazonaws.com   80:30851/TCP,443:32735/TCP   103s

NLB में TLS प्रमाणपत्रों को समाप्त करें

ACM प्रमाणपत्र तैयार करें

  1. ACM कंसोल खोलें, और अपने कस्टम डोमेन के लिए एक सार्वजनिक ACM प्रमाणपत्र के लिए आवेदन करें या एक कस्टम प्रमाणपत्र आयात करें।

acm

LoadBalancer कॉन्फ़िगरेशन प्रमाणपत्र

  1. EC2 कंसोल खोलें, और अपने लोड बैलेंसर्स -> लिस्टनर -> संपादित करें चुनें

nlb-1

  1. NLB प्रोटोकॉल को HTTPS, पोर्ट को 443, इंस्टेंस प्रोटोकॉल को HTTP और पोर्ट को 30851 पर सेट करें

nlb-2

  1. ACM से TLS प्रमाणपत्र को NLB से संलग्न करें।

nlb-3

कस्टम डोमेन को लोड बैलेंसर नाम से संबद्ध करें

आप अपने DNS प्रदाता के कंसोल का उपयोग करके अपने एप्लिकेशन के DNS रिकॉर्ड को CNAME के माध्यम से NLB के URL पर निर्देशित कर सकते हैं। उदाहरण के लिए, Route53 और अपने NLB को निर्देशित करने वाले CNAME रिकॉर्ड्स को कॉन्फ़िगर करें।

httpbin.example-test.org CNAME a6cffe9f6fc5c47b9929cb758610fc5a-2074689558.ap-northeast-1.elb.amazonaws.com

एप्लिकेशन डोमेन तक पहुंचें

curl https://httpbin.example-test.org

Ingress में TLS प्रमाणपत्र समाप्त करें

इस उदाहरण को शुरू करने से पहले, सुनिश्चित करें कि AWS NLB का कॉन्फ़िगरेशन पुनर्स्थापित किया गया है, जैसा कि निम्नलिखित छवि में दिखाया गया है।

nls-0

cert-manager इंस्टॉल करें

Cert-manager एक Kubernetes ऐड-ऑन है जो विभिन्न स्रोतों से स्वचालित रूप से TLS प्रमाणपत्रों का प्रबंधन और जारी कर सकता है। आप cert-manager को इंस्टॉल करने के लिए एक सामान्य तरीके का उपयोग कर सकते हैं।

ACM Private CA बनाएं

  1. ACM PCA कंसोल खोलें, "Create a private CA" चुनें, और इंस्टॉल करें।

pca-1

  1. CA सफलतापूर्वक बन जाने के बाद, और स्थिति सक्रिय हो। PCA का ARN बाद के अनुभागों में बार-बार उपयोग किया जाएगा।

pca-2

ACM Private CA के लिए EKS नोड अनुमतियाँ सेट करें

डिफ़ॉल्ट रूप से, कोई जारी करने की अनुमति नहीं होती है। ACM Private CA से प्रमाणपत्र जारी करने के लिए, आपको EKS NodeInstanceRole में एक IAM नीति जोड़नी होगी, जिसमें iamserviceaccount सेवा भूमिका शामिल हो।

  1. pca-iam-policy.json फ़ाइल बनाएं, और आपको ${PCA_ARN} को अपने स्वयं के PCA_ARN से बदलना होगा।
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "${PCA_ARN}"
        }
    ]
}
  1. pca-iam-policy.json के आधार पर IAM और iamserviceaccount बनाएं, और ${account_id} को अपने AWS ID से बदलना होगा।
aws iam create-policy \
    --policy-name AWSPCAIssuerIAMPolicy \
    --policy-document file://pca-iam-policy.json
# नेमस्पेस बनाएं
kubectl create namespace aws-pca-issuer
eksctl create iamserviceaccount \
    --cluster=${cluster_name} \
    --namespace=aws-pca-issuer \
    --name=aws-pca-issuer \
    --attach-policy-arn=arn:aws:iam::${account_id}:policy/AWSPCAIssuerIAMPolicy \
    --override-existing-serviceaccounts \
    --approve

aws-privateca-issuer इंस्टॉल करें

AWS PrivateCA Issuer cert-manager ऐड-ऑन (External Issuers के रूप में कार्य करता है जो प्रमाणपत्र अनुरोधों पर हस्ताक्षर करता है।

  1. Helm का उपयोग करके इंस्टॉल करें
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm repo update
helm install aws-pca-issuer awspca/aws-privateca-issuer \
    -n aws-pca-issuer \
    --set serviceAccount.create=false \
    --set serviceAccount.name=aws-pca-issuer
  1. स्थिति की जांच करें
$ kubectl get pods -n aws-pca-issuer
NAME                                                   READY   STATUS    RESTARTS   AGE
aws-pca-issuer-aws-privateca-issuer-5cdd4b4687-z52n7   1/1     Running   0          20s

Issuer बनाएं और प्रमाणपत्र के लिए आवेदन करें

  1. issuer-cert.yaml फ़ाइल में ${PCA_ARN} को अपने कॉन्फ़िगरेशन से बदलें और निम्नलिखित कमांड निष्पादित करें:
  • kubectl apply -f issuer-cert.yaml
# issuer-cert.yaml
apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
  name: demo-test-root-ca
spec:
  arn: ${PCA_ARN}
---

kind: Certificate
apiVersion: cert-manager.io/v1
metadata:
  name: nlb-lab-tls-cert
spec:
  commonName: httpbin.example-test.org # अपने कस्टम डोमेन नाम से बदलें
  dnsNames:
    - httpbin.example-test.org # अपने कस्टम डोमेन नाम से बदलें
  duration: 2160h0m0s
  issuerRef:
    group: awspca.cert-manager.io
    kind: AWSPCAClusterIssuer
    name: demo-test-root-ca
  renewBefore: 360h0m0s
  secretName: nlb-tls-app-secret
  usages:
    - server auth
    - client auth
  privateKey:
    algorithm: "RSA"
    size: 2048
  1. निम्नलिखित कमांड निष्पादित करें यह सत्यापित करने के लिए कि प्रमाणपत्र जारी किया गया है और सीक्रेट जनरेट हो गया है।
$ kubectl get cert
NAME                READY   SECRET                AGE
nlb-lab-tls-cert    True    nlb-tls-app-secret    10s
$ kubectl get secret
NAME                  TYPE                                  DATA   AGE
nlb-tls-app-secret    kubernetes.io/tls                     3      8s

httpbin एप्लिकेशन को सार्वजनिक और सुरक्षित करें

सुनिश्चित करें कि APISIX Ingress सफलतापूर्वक इंस्टॉल हो गया है। कृपया इस अनुभाग की जांच करें।

  1. httpbin एप्लिकेशन तैनात करें
kubectl run httpbin --image kennethreitz/httpbin --port 80
kubectl expose pod httpbin --port 80
  1. httpbin एप्लिकेशन को सार्वजनिक और सुरक्षित करने के लिए Ingress बनाएं
kubectl apply -f ingress-httpbin.yaml

```yaml
# ingress-httpbin.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-demo-apisix
spec:
  ingressClassName: apisix
  tls:
  - hosts:
    - httpbin.example-test.org
    secretName: nlb-tls-app-secret
  rules:
  - host: httpbin.example-test.org
    http:
      paths:
      - backend:
          service:
            name: httpbin
            port:
              number: 80
        path: /
        pathType: Prefix
  1. एप्लिकेशन डोमेन नाम तक पहुंचें

सुनिश्चित करें कि आपका कस्टम डोमेन नाम और लोड बैलेंसर का नाम संबद्ध हो गया है। कृपया इस अनुभाग की जांच करें।

$ curl https://httpbin.example-test.org/headers --cacert acm-pca/cacert.pem
{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.example-test.org",
    "User-Agent": "curl/7.74.0",
    "X-Forwarded-Host": "httpbin.example-test.org"
  }
}

निष्कर्ष

यह लेख APISIX Ingress के साथ AWS ACM और ACM Private CA घटकों के उपयोग को व्यावहारिक उदाहरणों के माध्यम से प्रदर्शित करता है और Kubernetes में TLS प्रमाणपत्रों को समाप्त करने के लिए दो कॉन्फ़िगरेशन: NLB और Ingress में TLS प्रमाणपत्रों को समाप्त करना का परिचय देता है। ACM + NLB कॉन्फ़िगरेशन सार्वजनिक रूप से विश्वसनीय प्रमाणपत्रों के लिए अधिक उपयुक्त है। यदि एप्लिकेशन्स के बीच एन्क्रिप्शन की आवश्यकता होती है, तो ACM Private CA एक अधिक सुरक्षित होस्टेड प्रबंधन सेवा प्रदान कर सकता है।

हम आशा करते हैं कि ये व्यावहारिक लेख पाठकों को उनके AWS EKS क्लस्टर्स में TLS ट्रैफ़िक को अधिक प्रभावी ढंग से कॉन्फ़िगर और प्रबंधित करने में मदद करेंगे। API गेटवे के बारे में अधिक जानकारी के लिए कृपया ब्लॉग्स या हमसे संपर्क करें पर जाएं।

Tags:
APISIX Ingress Controller
AWS
Kubernetes