Cara Menggunakan cert-manager dan HashiCorp Vault untuk Mengelola Sertifikat?

Jintao Zhang

March 2, 2023

Products

Masalah Apa yang Dipecahkan oleh cert-manager

Diumumkan sebagai proyek open-source oleh JETSTACK pada tahun 2017, cert-manager kemudian disumbangkan ke CNCF (Cloud Native Computing Foundation) dan menjadi proyek tingkat sandbox. Pada Oktober 2022, cert-manager menjadi proyek inkubasi CNCF.

cert-manager dapat secara otomatis mengelola sertifikat x.509 di Kubernetes dan OpenShift. Ini membuat sertifikat dan permintaan penandatanganan sertifikat menjadi jenis sumber daya pertama yang didukung di Kubernetes, yang prosesnya diimplementasikan melalui CRD. Selain itu, cert-manager memungkinkan pengembang untuk mengajukan sertifikat dengan cepat guna meningkatkan keamanan akses aplikasi.

Mari kita lihat bagaimana sertifikat dikelola di Kubernetes sebelum cert-manager muncul.

Bagaimana Sertifikat Dikelola di Kubernetes

Ada dua cara utama untuk menyimpan data di Kubernetes:

  • ConfigMap
  • Secret

Namun, semua informasi dalam ConfigMap adalah teks biasa. Oleh karena itu, menyimpan beberapa informasi konfigurasi umum mungkin tidak masalah; tetapi tidak cocok untuk informasi pribadi seperti sertifikat.

Ketika Kubernetes dirancang, disarankan untuk menggunakan Secret untuk menyimpan informasi terkait seperti sertifikat, dan juga menyediakan dukungan untuk ini. Kita dapat dengan mudah menyimpan informasi sertifikat melalui kubectl create secret tls. Contohnya:

➜  ~ 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

Melalui perintah di atas, sebuah sumber daya secret bernama moelove-tls, dengan tipe kubernetes.io/tls, dibuat di Kubernetes.

Sumber daya ini dapat langsung dirujuk untuk mendapatkan informasi sertifikat yang sesuai jika aplikasi membutuhkannya. Dalam kebanyakan kasus, kita akan menggunakannya dalam skenario Ingress Controller. Contohnya:

➜  ~ 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: {}

Melalui perintah di atas, sebuah sumber daya ingress bernama moelove-ing dibuat. Domain name-nya dideklarasikan sebagai moelove.info, dan perlindungan sertifikat ditambahkan ke domain name ini menggunakan moelove-tls. Setelah komponen Ingress controller yang sesuai mendapatkan sumber daya Ingress, komponen tersebut dapat secara otomatis mengonfigurasi sertifikat untuk domain name ini, sehingga meningkatkan keamanan situs web.

Masalah Apa yang Kita Hadapi

Proses Penerbitan Sertifikat yang Rumit

Dalam konten di atas, saya tidak menunjukkan cara menerbitkan sertifikat. Jika tertarik, Anda dapat memeriksa Dokumentasi OpenSSL. Selama proses penerbitan sertifikat, banyak konsep yang perlu dipahami. Selain itu, proses penandatanganan terjadi di luar kluster Kubernetes, dan tidak mungkin untuk memahami apa yang terjadi secara spesifik melalui metode konfigurasi "deklaratif". Terutama, sertifikat dapat memiliki banyak algoritma enkripsi, konfigurasi, dll.

Jadi jika Anda menggunakan metode default, Anda hanya dapat menyimpan sertifikat dan kunci yang dihasilkan di Kubernetes Secrets.

Proses Pembaruan/Penandatanganan Ulang Sertifikat yang Rumit

Kita semua tahu bahwa sertifikat memiliki masa berlaku. Sebelum sertifikat kedaluwarsa atau dicabut, sertifikat baru harus disiapkan, dan masa berlaku sertifikat baru harus lebih lama dari yang lama.

Manajemen sertifikat di Kubernetes Secrets perlu ditingkatkan karena:

  • Tidak ada pemeriksaan otomatis terhadap masa berlaku: Anda dapat menyimpan sertifikat apa pun di Kubernetes, terlepas dari apakah sertifikat tersebut sudah kedaluwarsa atau belum.

  • Tidak ada pemeriksaan untuk data yang tidak valid: Jika data yang disimpan di Kubernetes Secrets rusak atau tidak valid, tidak ada penanganan khusus di Kubernetes.

Kurangnya Keamanan

Sertifikat dan informasi kunci yang disimpan di Kubernetes Secrets hanya dienkode dengan base64. Oleh karena itu, siapa pun yang mendapatkan data tersebut dapat mendekode base64 untuk mendapatkan data asli. Contohnya:

➜  ~ 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-----

Data asli terkait sertifikat dapat diperoleh melalui perintah di atas.

Di sisi lain, ketika kita ingin memperbarui data sertifikat dan kunci, itu dapat diperbarui langsung tanpa proses konfirmasi ulang.

Ini tidak sesuai dengan kebijakan keamanan di sebagian besar skenario.

Selanjutnya, mari kita lihat bagaimana cert-manager memecahkan masalah ini.

Bagaimana cert-manager Memecahkan Masalah Ini

Penerbitan Otomatis

Cert-manager dikembangkan dan diperluas melalui CRD, yang menambahkan dan mengimplementasikan sumber daya Issuers dan ClusterIssuers, yang mewakili CA (certificate authority) dari sertifikat.

Ini juga mendukung berbagai jenis bawaan dan dapat dengan mudah diintegrasikan dengan komponen eksternal, seperti:

  • SelfSigned: Sertifikat yang ditandatangani sendiri

  • CA: Menyediakan CA untuk penerbitan

  • Vault: Menggunakan HashiCorp Vault untuk penerbitan

  • Venafi: Menggunakan Venafi untuk penerbitan

  • External: Menggunakan beberapa komponen eksternal untuk penandatanganan, seperti:

  • ACME (Automated Certificate Management Environment)

Komponen-komponen ini dapat digunakan untuk menerbitkan sertifikat dengan mudah. Konten selanjutnya akan mengambil Vault sebagai contoh untuk pengenalan spesifik.

Pembaruan/Penandatanganan Ulang Otomatis

Di cert-manager, kita dapat dengan mudah memperbarui sertifikat secara manual melalui cmctl, dan pada saat yang sama, cert-manager akan secara otomatis memeriksa masa berlaku dan integritas sertifikat.

Jika sertifikat kedaluwarsa atau data sertifikat tidak lengkap, itu dapat secara otomatis memicu penerbitan ulang sertifikat, menghemat biaya tenaga kerja dan pemeliharaan.

Jaminan Keamanan

Di cert-manager, sumber daya signers ditambahkan melalui CRD (CustomResourceDefinitions), yang memungkinkan permintaan sertifikat untuk dikonfirmasi, Disetujui, atau Ditolak. Hanya setelah Disetujui, itu akan berlaku, dan sertifikat akan diterbitkan. Ini adalah cara yang lebih aman.

Bagaimana APISIX Ingress Controller Berintegrasi dengan cert-manager

Instalasi

Apache APISIX Ingress Controller adalah Kubernetes Ingress Controller yang dapat mendukung konfigurasi aturan proxy melalui Ingress, sumber daya kustom, dan Gateway API.

Selanjutnya, kita akan mendemonstrasikan bagaimana mengintegrasikan APISIX Ingress Controller dengan cert-manager untuk menambahkan sertifikat TLS ke domain name proxy guna meningkatkan keamanan.

Pada saat yang sama, kita menggunakan Vault untuk menerbitkan sertifikat.

Menyebarkan APISIX Ingress Controller

Menyebarkan APISIX Ingress Controller sangat sederhana: Anda hanya perlu melakukan langkah-langkah berikut:

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

Ketika semua Pod dalam status running, penyebaran berhasil.

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

Menyebarkan Vault

Saat menyebarkan Vault, Helm juga dapat digunakan. Di sini saya menambahkan konfigurasi --set "server.dev.enabled=true" sehingga dapat digunakan langsung setelah penyebaran tanpa operasi tambahan. (Perhatikan bahwa konfigurasi ini tidak boleh digunakan di lingkungan produksi.)

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

Setelah penyebaran selesai, Pod dalam status Running menunjukkan bahwa penyebaran telah selesai.

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

Selanjutnya, masuk ke Vault untuk mengoperasikan, di mana kemampuan pki diaktifkan dan kebijakan yang sesuai dikonfigurasi.

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

Selanjutnya, konfigurasikan autentikasi 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

Setelah menyelesaikan operasi di atas, langkah selanjutnya adalah menyebarkan cert-manager.

Menyebarkan cert-manager

Sekarang Anda dapat menginstal cert-manager melalui Helm, dan proses instalasinya relatif sederhana.

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/

Periksa status 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

Kemudian kita dapat memulai konfigurasi dan validasi.

Bagaimana Mengonfigurasi dan Memvalidasi?

Mengonfigurasi dan Menerbitkan Sertifikat

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

Membuat Issuer

Melalui konfigurasi ini, Vault akan digunakan sebagai otoritas sertifikat, dan penerbitan otomatis akan dilakukan dengan merujuk pada peran dan secret yang dikonfigurasi di 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

Membuat Sertifikat

Melalui konfigurasi di sini, sertifikat dapat diterbitkan secara otomatis dan dapat dirujuk melalui moelove-info-tls selama penggunaan selanjutnya.

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

Validasi

Selanjutnya, verifikasi dengan memproksi layanan HTTPBIN.

Pertama, buat aplikasi HTTPBIN dan buat Service yang sesuai.

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

Kemudian definisikan sumber daya berikut untuk memproksi dan merujuk sertifikat:

# Define ApisixTls Objects
apiVersion: apisix.apache.org/v2
kind: ApisixTls
metadata:
  name: moelove
spec:
  hosts:
  - moelove.info
  secret:
    name: moelove-info-tls

---
# Define the route to access the backend
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: moelove
spec:
  http:
  - name: httpbin
    match:
      paths:
      - /*
      hosts:
      - moelove.info
    backends:
    - serviceName: httpbin
      servicePort: 80

Terapkan sumber daya ini ke kluster. Kemudian gunakan kubectl port-forward untuk meneruskan port 443 dari APISIX ke lokal dan lakukan pengujian akses:

$ ~ 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"
}

Dapat dilihat bahwa sertifikat HTTPS telah dikonfigurasi dengan benar untuk domain name moelove.info, dan proxy telah dikonfigurasi untuknya melalui APISIX Ingress Controller.

Kesimpulan

Ada dua metode penyimpanan default sertifikat di Kubernetes: ConfigMap dan Secret. Namun, penerbitan dan pembaruan/penandatanganan ulang sertifikat rumit, dan keamanannya perlu ditingkatkan.

Cert-manager memecahkan masalah ini dan secara bertahap menjadi standar de facto dalam bidang penerbitan/manajemen sertifikat di ekosistem Kubernetes. Selain itu, ini dapat diintegrasikan dengan alat seperti Vault, yang lebih aman.

Apache APISIX Ingress Controller berkomitmen untuk membuat Ingress Controller yang ramah pengguna, sehingga kemampuan integrasi cert-manager yang lengkap ditambahkan sejak awal. Pengguna dapat menggunakan cert-manager untuk menerbitkan sertifikat melalui Vault di Apache APISIX Ingress Controller dan menyediakan proxy HTTPS untuk aplikasi.

Tags:
APISIX Ingress Controller
Certificate Management
HashiCorp Vault