استخدام APISIX Ingress Controller مع AWS ACM

Xin Rong

December 30, 2022

Ecosystem

لماذا نحتاج إلى AWS ACM؟

المشكلات الناتجة عن الإدارة اليدوية

تحتوي الشهادة على معلومات مثل الحامل والمصدر وتاريخ انتهاء الصلاحية، ولا يمكن استخدام الشهادة المنتهية الصلاحية ويجب تجديدها قبل انتهاء صلاحيتها. لذلك، يجب تسجيل معلومات الشهادة، على سبيل المثال، تسجيلها يدويًا في جدول بيانات، لضمان إمكانية إلغاء الشهادات وتجديدها في الوقت المناسب.

ومع ذلك، مع زيادة عدد الشهادات، لا يمكن للإدارة اليدوية إدارة الشهادات بشكل صحيح وفعال. لا يمكن لجدول البيانات إرسال إشعار تلقائي، ولن يقوم بتجديد الشهادة تلقائيًا عند انتهاء صلاحيتها، مما يجلب مخاطر غير ضرورية.

لتجنب مخاطر انقطاع الشهادة والحفاظ على التحديثات التلقائية وفقًا للمعلومات واللوائح الجديدة، ظهرت إدارة الشهادات التلقائية، مما يقلل من مخاطر انتهاء صلاحية الشهادات ويخفف العبء عن المطورين.

إدارة الشهادات تلقائيًا مع ACM

يمكن لـ AWS Certificate Manager (ACM) توفير وإدارة ونشر وتجديد شهادات SSL/TLS بسهولة. يمكنك إصدار الشهادات مباشرة من خلال ACM لحماية مواقعك وتطبيقاتك على AWS أو استيراد شهادات طرف ثالث إلى نظام إدارة ACM.

مع ACM، لم تعد بحاجة إلى المرور بالعمليات اليدوية المكثفة المرتبطة باستخدام وإدارة شهادات SSL/TLS كما كان من قبل. يمكنك أيضًا تصدير شهادات ACM الموقعة من قبل AWS Private CA لاستخدامها في أي مكان داخل PKI الداخلي الخاص بك. بالإضافة إلى ذلك، يتم دمجها مع AWS Elastic Load Balancing (ELB).

acm

ما هي المشكلات التي يحلها ACM Private CA؟

تُستخدم الشهادات الموقعة ذاتيًا لنشر التطبيقات الداخلية دون أي CA خاص داخل المنظمة. عندما تحاول هذه التطبيقات الوصول إلى بعضها البعض، قد ترفض الوصول إلى بعضها البعض لأن شهاداتها غير موثوقة. الوثوق بشكل أعمى بمصادر غير معروفة للتطبيقات يمكن أن يجلب مخاطر أمنية. في هذه الحالة، نحتاج إلى خدمة CA خاصة مستضافة لإنشاء وإدارة تسلسل هرمي لـ CA لضمان أن جميع التطبيقات داخل المنظمة موثوقة.

ACM Private CA هي خدمة مستضافة عالية التوفر تقوم بإنشاء والحفاظ على PKI داخلي لمنظمتك، مما يلغي تكلفة الصيانة المستمرة. يتم تخزين المفاتيح الخاصة في وحدات أمان الأجهزة (HSM) المستضافة على AWS والتي تم التحقق منها بواسطة FIPS 140-2، مما يوفر حلًا أكثر أمانًا لمنظمات إصدار الشهادات مقارنة بـ CA الافتراضي في Kubernetes.

pca

كيفية استخدام ACM مع Kubernetes؟

هناك تكوينان مختلفان لإنهاء شهادات TLS في Kubernetes:

Configurations

  • إنهاء شهادات TLS في Ingress: عندما تكون هناك حاجة للتشفير بين التطبيقات، نحتاج إلى إنهاء TLS في متحكم Ingress. يمكن لكل تطبيق إدارة شهادته من خلال Ingress دون أي تدخل من بعضها البعض. هذه الطريقة أسهل في التكوين والإدارة وتضمن أن الاتصال بين التطبيقات موثوق به.
  • إنهاء شهادات TLS في NLB: إنهاء شهادات TLS على مستوى NLB هو الحالة الأكثر شيوعًا لاستخدام الشهادات الموثوقة بشكل عام. هذه الطريقة سهلة التكوين وربط شهادة ACM الموثوقة بشكل عام بـ NLB. الوصول إلى التطبيقات داخل الكتلة لا يزال يستخدم HTTP دون أي عمليات تشفير وفك تشفير إضافية.

في الأمثلة التالية، يمكنك تكوين APISIX Ingress مباشرة على Amazon EKS. باستخدام هاتين الطريقتين، سنوضح كيفية عمل APISIX Ingress مع ACM (و ACM Private CA).

المتطلبات الأساسية

قبل أن نبدأ، يجب أن نفي بالمتطلبات التالية:

  • AWS حساب AWS وواجهة سطر أوامر AWS (AWS CLI)
  • يجب أن يكون لديك إذن لاستخدام دور IAM لـ Amazon EKS والأدوار المتعلقة بالخدمة AWS CloudFormation, Amazon Virtual Private Cloud (Amazon VPC) والموارد ذات الصلة. يرجى التحقق من هذه المقالة في دليل المستخدم IAM "العمليات والموارد ومفاتيح الشرط لـ Amazon Elastic Container Service for Kubernetes" واستخدام الأدوار المتعلقة بالخدمة. بالإضافة إلى ذلك، يحتاج هذا المبدأ الأمني IAM إلى إرفاق سياسة IAM المدارة AWSCertificateManagerPrivateCAFullAccess.
  • تثبيت وتكوين kubectl و eksctl.

مجموعة Amazon EKS

Amazon EKS هي خدمة مستضافة تسمح لك بتشغيل Kubernetes على AWS ونشر وإدارة مجموعات Kubernetes الخاصة بك بسهولة. ستستخدم هذه المقالة أداة سطر الأوامر eksctl لإدارة المجموعات.

  • استخدام التكوين الافتراضي لـ eksctl لإنشاء المجموعات (يرجى تجاهل هذا الجزء إذا كان لديك بالفعل مجموعة EKS)
eksctl create cluster

تثبيت APISIX Ingress

  1. تثبيت APISIX Ingress في مجموعة EKS، وتعيينها كنوع 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

إنهاء شهادات TLS في NLB

إعداد شهادة ACM

  1. افتح ACM console، وقم بطلب شهادة ACM عامة لنطاقك المخصص أو استيراد شهادة مخصصة.

acm

تكوين شهادة LoadBalancer

  1. افتح EC2 console، واختر load balancers -> listener -> edit

nlb-1

  1. قم بتعيين بروتوكول NLB إلى HTTPS، والمنفذ إلى 443، وبروتوكول المثيل إلى HTTP والمنفذ إلى 30851

nlb-2

  1. إرفاق شهادة TLS من ACM إلى NLB.

nlb-3

ربط النطاق المخصص باسم موزع التحميل

يمكنك استخدام وحدة تحكم موفر DNS الخاص بك لتوجيه سجل DNS الخاص بتطبيقك إلى عنوان URL الخاص بـ NLB عبر CNAME. على سبيل المثال، Route53 و تكوين سجلات CNAME التي تشير إلى NLB الخاص بك.

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

الوصول إلى نطاق التطبيق

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

إنهاء شهادة TLS في Ingress

قبل أن نبدأ هذا المثال، تأكد من استعادة تكوين AWS NLB، كما هو موضح في الصورة التالية.

nls-0

تثبيت cert-manager

Cert-manager هو إضافة لـ Kubernetes يمكنها إدارة وإصدار شهادات TLS تلقائيًا من مصادر مختلفة. يمكنك استخدام طريقة شائعة لتثبيت cert-manager.

إنشاء ACM Private CA

  1. افتح وحدة تحكم ACM PCA، واختر "إنشاء CA خاص"، وقم بالتثبيت.

pca-1

  1. بعد إنشاء CA بنجاح، وتكون الحالة نشطة. سيتم استخدام ARN الخاص بـ PCA بشكل متكرر في الأقسام اللاحقة.

pca-2

تعيين أذونات عقدة EKS لـ ACM Private CA

بشكل افتراضي، لا يوجد إذن إصدار. لإصدار شهادة من ACM Private CA، يجب إضافة سياسة IAM إلى EKS NodeInstanceRole، بما في ذلك دور الخدمة 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. إنشاء IAM و iamserviceaccount بناءً على pca-iam-policy.json، ويجب استبدال ${account_id} بمعرف AWS الخاص بك.
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 (مصادر خارجية لتوقيع طلبات الشهادات.

  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

إنشاء المصدر وطلب الشهادة

  1. استبدل ${PCA_ARN} في ملف issuer-cert.yaml بتكوينك وقم بتنفيذ الأمر التالي:
  • 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. إنشاء Ingress لنشر وحماية تطبيق httpbin
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 من خلال أمثلة عملية وتقدم تكوينين لإنهاء شهادات TLS في Kubernetes: إنهاء شهادات TLS في NLB و Ingress. تكوين ACM + NLB أكثر ملاءمة للشهادات الموثوقة بشكل عام. إذا كانت هناك حاجة للتشفير بين التطبيقات، يمكن لـ ACM Private CA توفير خدمة إدارة مستضافة أكثر أمانًا.

نأمل أن تساعد هذه المقالات العملية القراء على تكوين وإدارة حركة TLS في مجموعات AWS EKS الخاصة بهم بشكل أكثر فعالية. لمزيد من المعلومات حول بوابة API، يرجى زيارة المدونات أو الاتصال بنا.

Tags:
APISIX Ingress Controller
AWS
Kubernetes