cert-manager और HashiCorp Vault का उपयोग करके सर्टिफिकेट कैसे प्रबंधित करें?

cert-manager कौन सी समस्या हल करता है

2017 में JETSTACK द्वारा ओपन-सोर्स किया गया, cert-manager को CNCF (Cloud Native Computing Foundation) को दान कर दिया गया और यह सैंडबॉक्स-स्तरीय प्रोजेक्ट बन गया। अक्टूबर 2022 में यह CNCF इन्क्यूबेटिंग प्रोजेक्ट बन गया।

cert-manager Kubernetes और OpenShift में x.509 प्रमाणपत्रों को स्वचालित रूप से प्रबंधित कर सकता है। यह प्रमाणपत्र और प्रमाणपत्र हस्ताक्षर अनुरोधों को Kubernetes पर समर्थित संसाधनों का पहला प्रकार बनाता है, जिसकी प्रक्रिया CRD द्वारा लागू की गई थी। इसके अलावा, cert-manager डेवलपर्स को एप्लिकेशन एक्सेस सुरक्षा को बेहतर बनाने के लिए जल्दी से प्रमाणपत्र के लिए आवेदन करने की अनुमति देता है।

तो आइए देखें कि cert-manager के आने से पहले Kubernetes में प्रमाणपत्रों को कैसे प्रबंधित किया जाता था।

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

उपरोक्त कमांड के माध्यम से, Kubernetes में moelove-tls नामक एक secret संसाधन बनाया गया है, जिसका प्रकार kubernetes.io/tls है।

यदि एप्लिकेशन को इसका उपयोग करने की आवश्यकता होती है, तो इस संसाधन को सीधे संदर्भित किया जा सकता है ताकि संबंधित प्रमाणपत्र जानकारी प्राप्त की जा सके। अधिकांश मामलों में, हम इसे 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: {}

उपरोक्त कमांड के माध्यम से, moelove-ing नामक एक ingress संसाधन बनाया गया है। इसका डोमेन नाम moelove.info के रूप में घोषित किया गया है, और इस डोमेन नाम को moelove-tls का उपयोग करके प्रमाणपत्र सुरक्षा जोड़ी गई है। संबंधित Ingress controller घटक Ingress संसाधन प्राप्त करने के बाद, घटक इस डोमेन नाम के लिए स्वचालित रूप से प्रमाणपत्र कॉन्फ़िगर कर सकता है, जिससे वेबसाइट की सुरक्षा में सुधार होता है।

हमें कौन सी समस्याएं आईं

प्रमाणपत्र जारी करने की जटिलता

उपरोक्त सामग्री में, मैंने प्रमाणपत्र जारी करने का प्रदर्शन नहीं किया। यदि आप रुचि रखते हैं, तो आप OpenSSL डॉक्यूमेंटेशन देख सकते हैं। प्रमाणपत्र जारी करने की प्रक्रिया में, कई अवधारणाओं को समझने की आवश्यकता होती है। इसके अलावा, हस्ताक्षर प्रक्रिया 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 (Automated Certificate Management Environment)

इन घटकों का उपयोग करके प्रमाणपत्रों को आसानी से जारी किया जा सकता है। बाद की सामग्री में Vault को एक विशिष्ट परिचय के लिए उदाहरण के रूप में लिया जाएगा।

स्वचालित नवीनीकरण/पुनः हस्ताक्षर

cert-manager में, हम cmctl के माध्यम से मैन्युअल रूप से प्रमाणपत्र को नवीनीकृत कर सकते हैं, और साथ ही cert-manager प्रमाणपत्र की वैधता अवधि और अखंडता की स्वचालित रूप से जांच करेगा।

यदि प्रमाणपत्र की समाप्ति तिथि समाप्त हो जाती है या प्रमाणपत्र डेटा अधूरा है, तो यह स्वचालित रूप से प्रमाणपत्र के पुनः जारी करने को ट्रिगर कर सकता है, जिससे श्रम और रखरखाव लागत बचती है।

सुरक्षा गारंटी

cert-manager में, CRD (CustomResourceDefinitions) के माध्यम से signers संसाधन जोड़ा गया है, जो प्रमाणपत्र अनुरोध की पुष्टि, Approved, या Denied करने की अनुमति देता है। केवल Approve होने के बाद ही यह प्रभावी होगा, और प्रमाणपत्र जारी किया जाएगा। यह एक अधिक सुरक्षित तरीका है।

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

तैनाती पूरी होने के बाद, Running स्थिति में 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 को तैनात करें

अब आप Helm के माध्यम से cert-manager को स्थापित कर सकते हैं, और स्थापना प्रक्रिया अपेक्षाकृत सरल है।

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 में कॉन्फ़िगर की गई भूमिका