كيفية استخدام cert-manager و HashiCorp Vault لإدارة الشهادات؟

Jintao Zhang

March 2, 2023

Products

ما هي المشكلة التي يحلها cert-manager

تم إصدار cert-manager كمشروع مفتوح المصدر من قبل JETSTACK في عام 2017، وتم التبرع به إلى CNCF (Cloud Native Computing Foundation) وأصبح مشروعًا على مستوى الحضانة. وفي أكتوبر 2022، أصبح مشروعًا في مرحلة الحضانة في CNCF.

يمكن لـ cert-manager إدارة شهادات x.509 تلقائيًا في Kubernetes وOpenShift. حيث يجعل الشهادات وطلبات توقيع الشهادات أول نوع من الموارد المدعومة في Kubernetes، وقد تم تنفيذ هذه العملية باستخدام CRD. بالإضافة إلى ذلك، يسمح cert-manager للمطورين بطلب شهادة لتحسين أمان الوصول إلى التطبيقات بسرعة.

لنلقي نظرة على كيفية إدارة الشهادات في Kubernetes قبل ظهور cert-manager.

كيفية إدارة الشهادات في Kubernetes

هناك طريقتان رئيسيتان لتخزين البيانات في Kubernetes:

  • ConfigMap
  • Secret

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

عند تصميم Kubernetes، كان يُوصى باستخدام Secret لتخزين المعلومات ذات الصلة مثل الشهادات، كما يوفر دعمًا لذلك. يمكننا بسهولة تخزين معلومات الشهادة من خلال kubectl create secret tls. على سبيل المثال:

➜  ~ kubectl create secret tls moelove-tls --cert=./cert.pem --key=./cert-key.pem
secret/moelove-tls created
➜  ~ kubectl get secret moelove-tls -oyaml
apiVersion: v1
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNFekNDQWJtZ0F3SUJBZ0lVVHhCTC9aQkdpOEJCOUFVN2JRWi9jK3c2L1Rzd0NnWUlLb1pJemowRUF3SXcKVFRFTE1Ba0dBMVVFQmhNQ1EwNHhFREFPQmdOVkJBY1RCMEpsYVdwcGJtY3hGVEFUQmdOVkJBb1RERTF2WlV4dgpkbVVnU1U1R1R6RVZNQk1HQTFVRUF4TU1iVzlsYkc5MlpTNXBibVp2TUI0WERUSXlNVEF4T1RBM01UY3dNRm9YCkRUSXpNVEF4T1RBM01UY3dNRm93VFRFTE1Ba0dBMVVFQmhNQ1EwNHhFREFPQmdOVkJBY1RCMEpsYVdwcGJtY3gKRlRBVEJnTlZCQW9UREUxdlpVeHZkbVVnU1U1R1R6RVZNQk1HQTFVRUF4TU1iVzlsYkc5MlpTNXBibVp2TUZrdwpFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVVTcEFjNGE1UXQwQ0NVa2hGSGY3WnZvR1FReVVPUUxSClJhZG0rSUUrV1ZkOThyWkc5NFpob08ybDZSWkY2MnVPN3FpZ2VsaUJwY0FGQ3FzWU9HNnVLcU4zTUhVd0RnWUQKVlIwUEFRSC9CQVFEQWdXZ01CMEdBMVVkSlFRV01CUUdDQ3NHQVFVRkJ3TUJCZ2dyQmdFRkJRY0RBakFNQmdOVgpIUk1CQWY4RUFqQUFNQjBHQTFVZERnUVdCQlFnS01icnBUb3k4NVcvRy9hMGZtYzlDMUJRbURBWEJnTlZIUkVFCkVEQU9nZ3h0YjJWc2IzWmxMbWx1Wm04d0NnWUlLb1pJemowRUF3SURTQUF3UlFJZ1EzTzhJZ0N2MlRkNUhhV00KcE1LWmRCLzNXdEMreERlSVdPbER6L2hCdzE0Q0lRRExQNG0weFpmSkJvRGc5cERocThGdHN5VDdVZVhVdlZGQQpsS0tReFZNOXFBPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  tls.key: LS0tLS1CRUdJTiBFQyBQUklWQVRFIEtFWS0tLS0tCk1IY0NBUUVFSUsyZjZHQlNZQ0R4eVoycnB2bVZ1YW5MNDhxeW9SK1NiWmxiQzNqSUZybzhvQW9HQ0NxR1NNNDkKQXdFSG9VUURRZ0FFVVNwQWM0YTVRdDBDQ1VraEZIZjdadm9HUVF5VU9RTFJSYWRtK0lFK1dWZDk4clpHOTRaaApvTzJsNlJaRjYydU83cWlnZWxpQnBjQUZDcXNZT0c2dUtnPT0KLS0tLS1FTkQgRUMgUFJJVkFURSBLRVktLS0tLQo=
kind: Secret
metadata:
  creationTimestamp: "2022-10-19T07:24:26Z"
  name: moelove-tls
  namespace: default
  resourceVersion: "2103326"
  uid: 14f86514-a1d1-4d99-b000-9ed8b5189d56
type: kubernetes.io/tls

من خلال الأمر أعلاه، تم إنشاء مورد سري باسم moelove-tls من نوع kubernetes.io/tls في Kubernetes.

يمكن الرجوع إلى هذا المورد مباشرة للحصول على معلومات الشهادة المقابلة إذا كان التطبيق يحتاج إلى استخدامها. في معظم الحالات، سنستخدمها في سياق Ingress Controller. على سبيل المثال:

➜  ~ kubectl create ingress moelove-ing --rule="moelove.info/=moelove:8080,tls=moelove-tls"
ingress.networking.k8s.io/moelove-ing created
➜  ~ kubectl get ing moelove-ing -oyaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  creationTimestamp: "2022-10-19T07:32:43Z"
  generation: 1
  name: moelove-ing
  namespace: default
  resourceVersion: "2104268"
  uid: b90f09f7-8036-4b9f-9744-a247141ea8da
spec:
  rules:
  - host: moelove.info
    http:
      paths:
      - backend:
          service:
            name: moelove
            port:
              number: 8080
        path: /
        pathType: Exact
  tls:
  - hosts:
    - moelove.info
    secretName: moelove-tls
status:
  loadBalancer: {}

من خلال الأمر أعلاه، تم إنشاء مورد ingress باسم moelove-ing. تم تعريف النطاق باسم moelove.info، وتمت إضافة حماية الشهادة لهذا النطاق باستخدام moelove-tls. بعد أن يحصل مكون Ingress controller المقابل على مورد Ingress، يمكن للمكون تكوين الشهادة تلقائيًا لهذا النطاق، مما يحسن أمان الموقع.

ما هي المشاكل التي واجهناها

إصدار الشهادات معقد

في المحتوى أعلاه، لم أشرح كيفية إصدار الشهادات. إذا كنت مهتمًا، يمكنك الاطلاع على OpenSSL Documentation. خلال عملية إصدار الشهادات، هناك العديد من المفاهيم التي يجب فهمها. علاوة على ذلك، تحدث عملية التوقيع خارج مجموعة Kubernetes، ولا يمكن فهم ما حدث بالضبط من خلال طريقة التكوين "التصريحية". خاصة أن الشهادات يمكن أن تحتوي على العديد من خوارزميات التشفير المختلفة، والتكوينات، إلخ.

لذلك إذا كنت تستخدم الطريقة الافتراضية، يمكنك فقط تخزين الشهادة والمفتاح الذي تم إنشاؤه في Kubernetes Secrets.

تجديد/إعادة توقيع الشهادات معقد

نعلم جميعًا أن الشهادات لها تاريخ انتهاء صلاحية. قبل انتهاء صلاحية الشهادة أو إلغائها، يجب إعداد شهادة جديدة، ويجب أن يكون تاريخ انتهاء صلاحية الشهادة الجديدة لاحقًا للشهادة القديمة.

إدارة الشهادات في Kubernetes Secrets تحتاج إلى تحسين لأن:

  • لا يوجد فحص تلقائي لتاريخ انتهاء الصلاحية: يمكنك تخزين أي شهادات في Kubernetes، بغض النظر عما إذا كانت الشهادة قد انتهت صلاحيتها أم لا.

  • لا يوجد فحص للبيانات غير الصالحة: إذا كانت البيانات المخزنة في Kubernetes Secrets تالفة أو غير صالحة، فلا يوجد معالجة خاصة في Kubernetes.

نقص الأمان

الشهادة والمعلومات الرئيسية المخزنة في Kubernetes Secrets تكون مشفرة فقط باستخدام base64. لذلك، يمكن لأي شخص يحصل على البيانات فك تشفيرها باستخدام base64 للحصول على البيانات الحقيقية. على سبيل المثال:

➜  ~ kubectl get secrets moelove-tls -o jsonpath='{ .data.tls\.crt }' |base64 -d
-----BEGIN CERTIFICATE-----
MIICEzCCAbmgAwIBAgIUTxBL/ZBGi8BB9AU7bQZ/c+w6/TswCgYIKoZIzj0EAwIw
TTELMAkGA1UEBhMCQ04xEDAOBgNVBAcTB0JlaWppbmcxFTATBgNVBAoTDE1vZUxv
dmUgSU5GTzEVMBMGA1UEAxMMbW9lbG92ZS5pbmZvMB4XDTIyMTAxOTA3MTcwMFoX
DTIzMTAxOTA3MTcwMFowTTELMAkGA1UEBhMCQ04xEDAOBgNVBAcTB0JlaWppbmcx
FTATBgNVBAoTDE1vZUxvdmUgSU5GTzEVMBMGA1UEAxMMbW9lbG92ZS5pbmZvMFkw
EwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEUSpAc4a5Qt0CCUkhFHf7ZvoGQQyUOQLR
Radm+IE+WVd98rZG94ZhoO2l6RZF62uO7qigeliBpcAFCqsYOG6uKqN3MHUwDgYD
VR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNV
HRMBAf8EAjAAMB0GA1UdDgQWBBQgKMbrpToy85W/G/a0fmc9C1BQmDAXBgNVHREE
EDAOggxtb2Vsb3ZlLmluZm8wCgYIKoZIzj0EAwIDSAAwRQIgQ3O8IgCv2Td5HaWM
pMKZdB/3WtC+xDeIWOlDz/hBw14CIQDLP4m0xZfJBoDg9pDhq8FtsyT7UeXUvVFA
lKKQxVM9qA==
-----END CERTIFICATE-----

يمكن الحصول على البيانات الأصلية المتعلقة بالشهادة من خلال الأمر أعلاه.

من ناحية أخرى، عندما نريد تحديث بيانات الشهادة والمفتاح، يمكن تحديثها مباشرة دون أي عملية تأكيد ثانوية.

هذا لا يتوافق مع سياسات الأمان في معظم السيناريوهات.

لنرى الآن كيف يحل cert-manager هذه المشاكل.

كيف يحل cert-manager هذه المشاكل

الإصدار التلقائي

تم تطوير cert-manager وتمديده من خلال CRD، حيث تمت إضافة وتنفيذ موارد Issuers وClusterIssuers، والتي تمثل CA (سلطة الشهادة) للشهادة.

كما يدعم مجموعة متنوعة من الأنواع المدمجة ويمكن دمجه بسهولة مع المكونات الخارجية، مثل:

  • SelfSigned: شهادة موقعة ذاتيًا

  • CA: توفير CA للإصدار

  • Vault: استخدام HashiCorp Vault للإصدار

  • Venafi: استخدام Venafi للإصدار

  • External: استخدام بعض المكونات الخارجية للتوقيع، مثل:

  • ACME (بيئة إدارة الشهادات التلقائية)

يمكن استخدام هذه المكونات لإصدار الشهادات بسهولة. سيتم تقديم مثال محدد باستخدام Vault في المحتوى اللاحق.

التجديد/إعادة التوقيع التلقائي

في cert-manager، يمكننا بسهولة تجديد الشهادة يدويًا من خلال cmctl، وفي نفس الوقت، سيقوم cert-manager بالتحقق تلقائيًا من صلاحية الشهادة وسلامتها.

إذا انتهت صلاحية الشهادة أو كانت بيانات الشهادة غير مكتملة، يمكن أن يؤدي ذلك إلى إعادة إصدار الشهادة تلقائيًا، مما يوفر تكاليف العمالة والصيانة.

ضمان الأمان

في cert-manager، تمت إضافة مورد signers من خلال CRD (CustomResourceDefinitions)، مما يسمح بتأكيد طلب الشهادة، Approved أو Denied. فقط بعد الموافقة سيتم تفعيلها، وسيتم إصدار الشهادة. إنها طريقة أكثر أمانًا.

كيفية تكامل APISIX Ingress Controller مع cert-manager

التثبيت

Apache APISIX Ingress Controller هو Kubernetes Ingress Controller يمكنه دعم تكوين قواعد الوكيل من خلال Ingress، الموارد المخصصة، وGateway API.

سنوضح الآن كيفية تكامل APISIX Ingress Controller مع cert-manager لإضافة شهادة TLS إلى نطاق الوكيل لتحسين الأمان.

في نفس الوقت، سنستخدم Vault لإصدار الشهادات.

نشر APISIX Ingress Controller

نشر APISIX Ingress Controller بسيط جدًا: تحتاج فقط إلى تنفيذ الخطوات التالية:

tao@moelove:~$ helm repo add apisix https://charts.apiseven.com
tao@moelove:~$ helm repo add bitnami https://charts.bitnami.com/bitnami
tao@moelove:~$ helm repo update
tao@moelove:~$ helm install apisix apisix/apisix --set gateway.tls.enabled=true --set gateway.type=NodePort   --set ingress-controller.enabled=true   --set ingress-controller.config.apisix.serviceNamespace=apisix   --namespace apisix   --create-namespace   --set ingress-controller.config.apisix.serviceName=apisix-admin --set ingress-controller.config.ingressPublishService="apisix/apisix-gateway"
NAME: apisix
LAST DEPLOYED: Wed Oct 19 21:33:37 2022
NAMESPACE: apisix
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace apisix -o jsonpath="{.spec.ports[0].nodePort}" services apisix-gateway)
  export NODE_IP=$(kubectl get nodes --namespace apisix -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

عندما تكون جميع الـ Pods في حالة التشغيل، يكون النشر ناجحًا.

tao@moelove:~$ kubectl -n apisix get pods  
NAME                                         READY   STATUS    RESTARTS   AGE
apisix-777c9fdd67-rf8zs                      1/1     Running   0          6m48s
apisix-etcd-0                                1/1     Running   0          6m48s
apisix-etcd-1                                1/1     Running   0          6m48s
apisix-etcd-2                                1/1     Running   0          6m48s
apisix-ingress-controller-568544b554-k7nd4   1/1     Running   0          6m48s

نشر Vault

عند نشر Vault، يمكن أيضًا استخدام Helm. هنا أضفت عنصر تكوين --set "server.dev.enabled=true" حتى يمكن استخدامه مباشرة بعد النشر دون أي عمليات إضافية. (لاحظ أن هذا التكوين لا يجب استخدامه في بيئة الإنتاج.)

tao@moelove:~$ helm repo add hashicorp https://helm.releases.hashicorp.com
tao@moelove:~$ helm install vault hashicorp/vault --set "injector.enabled=false" --set "server.dev.enabled=true"
NAME: vault
LAST DEPLOYED: Wed Oct 19 21:53:50 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
Thank you for installing HashiCorp Vault!

Now that you have deployed Vault, you should look over the docs on using
Vault with Kubernetes available here:

https://www.vaultproject.io/docs/


Your release is named "vault". To learn more about the release, try the following:

  $ helm status vault
  $ helm get manifest vault

بعد الانتهاء من النشر، يوضح الـ Pod في حالة التشغيل أن النشر قد اكتمل.

tao@moelove:~$ kubectl get pods  
NAME      READY   STATUS    RESTARTS   AGE
vault-0   1/1     Running   0          29s
tao@moelove:~$ kubectl get svc
NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
kubernetes       ClusterIP   10.96.0.1      <none>        443/TCP             84m
vault            ClusterIP   10.96.190.88   <none>        8200/TCP,8201/TCP   4m14s
vault-internal   ClusterIP   None           <none>        8200/TCP,8201/TCP   4m14s

بعد ذلك، أدخل إلى Vault للعمل، حيث تم تمكين ميزة pki وتم تكوين السياسة المقابلة.

tao@moelove:~$ kubectl  exec -it vault-0 -- sh
/ $ vault secrets enable pki
Success! Enabled the pki secrets engine at: pki/
/ $ vault write pki/root/generate/internal common_name=moelove.info ttl=8760h
Key              Value
---              -----
certificate      -----BEGIN CERTIFICATE-----
MIIDODCCAiCgAwIBAgIUds5uMJV9rOkwFEt6Xof5T2SVFccwDQYJKoZIhvcNAQEL
...
VM4DRVgDkqY9JdHU
-----END CERTIFICATE-----
expiration       1668983612
issuer_id        8df13015-7c70-df9a-7bb7-9b3b4afe7f82
issuer_name      n/a
issuing_ca       -----BEGIN CERTIFICATE-----
MIIDODCCAiCgAwIBAgIUds5uMJV9rOkwFEt6Xof5T2SVFccwDQYJKoZIhvcNAQEL
...
VM4DRVgDkqY9JdHU
-----END CERTIFICATE-----
key_id           c9fcfcb0-3548-a9a7-e706-30510592c797
key_name         n/a
serial_number    76:ce:6e:30:95:7d:ac:e9:30:14:4b:7a:5e:87:f9:4f:64:95:15:c7
/ $
/ $ vault write pki/config/urls issuing_certificates="http://vault.default:8200/v1/pki/ca" crl_distribution_points="http://vault.default:8200/v1/pki/crl"
Success! Data written to: pki/config/urls
/ $ vault write pki/roles/moelove-dot-info allowed_domains=moelove.info allow_subdomains=true max_ttl=72h
Success! Data written to: pki/roles/moelove-dot-info
/ $
/ $ vault policy write pki - <<EOF
> path "pki*"                        { capabilities = ["read", "list"] }
> path "pki/sign/moelove-dot-info"    { capabilities = ["create", "update"] }
> path "pki/issue/moelove-dot-info"   { capabilities = ["create"] }
> EOF
Success! Uploaded policy: pki

بعد ذلك، قم بتكوين المصادقة مع Kubernetes:

/ $ vault auth enable kubernetes
Success! Enabled kubernetes auth method at: kubernetes/
/ $ vault write auth/kubernetes/config kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443"
Success! Data written to: auth/kubernetes/config
/ $ vault write auth/kubernetes/role/issuer  bound_service_account_names=issuer bound_service_account_namespaces=default policies=pki ttl=20m
Success! Data written to: auth/kubernetes/role/issuer

بعد الانتهاء من العمليات أعلاه، الخطوة التالية هي نشر cert-manager.

نشر cert-manager

الآن يمكنك تثبيت cert-manager من خلال Helm، وعملية التثبيت بسيطة نسبيًا.

tao@moelove:~$ helm repo add jetstack https://charts.jetstack.io
tao@moelove:~$ helm repo update jetstack
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "jetstack" chart repository
Update Complete. ⎈Happy Helming!⎈
tao@moelove:~$ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.10.0/cert-manager.crds.yaml
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io created
tao@moelove:~$ helm install \
>   cert-manager jetstack/cert-manager \
>   --namespace cert-manager \
>   --create-namespace \
>   --version v1.10.0

xNAME: cert-manager
LAST DEPLOYED: Wed Oct 19 22:51:06 2022
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager v1.10.0 has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.io/docs/configuration/

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.io/docs/usage/ingress/

تحقق من حالة الـ Pod:

tao@moelove:~$ kubectl -n cert-manager get pods
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-69b456d85c-znpq4              1/1     Running   0          117s
cert-manager-cainjector-5f44d58c4b-wcd27   1/1     Running   0          117s
cert-manager-webhook-566bd88f7b-7rptf      1/1     Running   0          117s

ثم يمكننا البدء في التكوين والتحقق.

كيفية التكوين والتحقق؟

تكوين وإصدار الشهادات

tao@moelove:~$ kubectl create serviceaccount issuer
serviceaccount/issuer created
tao@moelove:~$ kubectl get secret
NAME                          TYPE                 DATA   AGE
sh.helm.release.v1.vault.v1   helm.sh/release.v1   1      36m
tao@moelove:~$ vim issuer-secret.yaml
tao@moelove:~$ cat issuer-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: issuer-token-moelove
  annotations:
    kubernetes.io/service-account.name: issuer
type: kubernetes.io/service-account-token
tao@moelove:~$ kubectl apply -f issuer-secret.yaml
secret/issuer-token-moelove created
tao@moelove:~$ kubectl get sa,secret
NAME                     SECRETS   AGE
serviceaccount/default   0         118m
serviceaccount/issuer    0         2m11s
serviceaccount/vault     0         38m

NAME                                 TYPE                                  DATA   AGE
secret/issuer-token-moelove          kubernetes.io/service-account-token   3      35s
secret/sh.helm.release.v1.vault.v1   helm.sh/release.v1                    1      38m

إنشاء Issuer

من خلال هذا التكوين، سيتم استخدام Vault كسلطة الشهادة، وسيتم الإصدار التلقائي بالإشارة إلى الدور والسر المكون في Vault.

tao@moelove:~$ cat vault-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: vault-issuer
  namespace: default
spec:
  vault:
    server: http://vault.default
    path: pki/sign/moelove-dot-info
    auth:
      kubernetes:
        mountPath: /v1/auth/kubernetes
        role: moelove-dot-info
        secretRef:
          name: issuer-token-moelove
          key: token
tao@moelove:~$ kubectl apply -f vault-issuer.yaml
issuer.cert-manager.io/vault-issuer created

إنشاء الشهادة

من خلال التكوين هنا، يمكن إصدار الشهادة تلقائيًا ويمكن الرجوع إليها من خلال moelove-info-tls أثناء الاستخدام اللاحق.

tao@moelove:~$ cat moelove-dot-info-cert.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: moelove-info
  namespace: default
spec:
  secretName: moelove-info-tls
  issuerRef:
    name: vault-issuer
  commonName: www.moelove.info
  dnsNames:
  - www.moelove.info
tao@moelove:~$ kubectl apply -f moelove-dot-info-cert.yaml
certificate.cert-manager.io/moelove-info created

التحقق

بعد ذلك، تحقق من خلال وكيل خدمة HTTPBIN.

أولاً، قم بإنشاء تطبيق HTTPBIN وإنشاء الخدمة المقابلة.

kubectl run httpbin --image kennethreitz/httpbin
kubectl expose pod httpbin --port=80

ثم قم بتعريف الموارد التالية للوكيل والرجوع إلى الشهادات:

# تعريف كائنات ApisixTls
apiVersion: apisix.apache.org/v2
kind: ApisixTls
metadata:
  name: moelove
spec:
  hosts:
  - moelove.info
  secret:
    name: moelove-info-tls

---
# تعريف المسار للوصول إلى الخلفية
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: moelove
spec:
  http:
  - name: httpbin
    match:
      paths:
      - /*
      hosts:
      - moelove.info
    backends:
    - serviceName: httpbin
      servicePort: 80

قم بتطبيق هذه الموارد على المجموعة. ثم استخدم kubectl port-forward لتوجيه المنفذ 443 من APISIX إلى المحلي وإجراء اختبار الوصول:

$ ~ kubectl port-forward -n ingress-apisix svc/apisix-gateway 8443:443 &
$ ~ curl -sk https://moelove.info:8443/ip --resolve 'moelove.info:8443:127.0.0.1'
{
  "origin": "172.17.18.1"
}

يمكن ملاحظة أنه تم تكوين شهادة HTTPS بشكل صحيح لنطاق moelove.info، وتم تكوين وكيل له من خلال APISIX Ingress Controller.

الخلاصة

هناك طريقتان افتراضيتان لتخزين الشهادات في Kubernetes: ConfigMap وSecret. ومع ذلك، فإن إصدار الشهادات وتجديدها/إعادة توقيعها معقد، والأمان يحتاج إلى تحسين.

حل cert-manager هذه المشاكل وأصبح تدريجيًا المعيار الفعلي في مجال إصدار/إدارة الشهادات في نظام Kubernetes البيئي. بالإضافة إلى ذلك، يمكن دمجه مع أدوات مثل Vault، مما يجعله أكثر أمانًا.

Apache APISIX Ingress Controller ملتزم بإنشاء Ingress Controller سهل الاستخدام، لذلك تمت إضافة قدرة تكامل كاملة مع cert-manager في وقت مبكر. يمكن للمستخدمين استخدام cert-manager لإصدار الشهادات من خلال Vault في Apache APISIX Ingress Controller وتوفير وكيل HTTPS للتطبيقات.

Tags: