Menggunakan APISIX Ingress Controller dengan AWS ACM

Xin Rong

December 30, 2022

Ecosystem

Mengapa kita membutuhkan AWS ACM?

Masalah yang disebabkan oleh manajemen manual

Sertifikat berisi informasi seperti pemegang, penerbit, dan tanggal kedaluwarsa, sementara sertifikat yang telah kedaluwarsa tidak dapat digunakan dan perlu diperbarui sebelum kedaluwarsa. Oleh karena itu, informasi sertifikat harus dicatat, misalnya, dicatat secara manual ke dalam spreadsheet, untuk memastikan bahwa sertifikat dapat dicabut dan diperbarui tepat waktu.

Namun, karena semakin banyak sertifikat, metode manajemen manual tidak dapat mengelola sertifikat dengan benar dan efisien. Spreadsheet tidak dapat mengirim notifikasi otomatis, juga tidak akan memperbarui sertifikat secara otomatis saat kedaluwarsa, sehingga menimbulkan risiko yang tidak perlu.

Untuk menghindari risiko gangguan sertifikat dan menjaga pembaruan otomatis sesuai dengan informasi dan peraturan baru, manajemen sertifikat otomatis muncul, mengurangi risiko kedaluwarsa sertifikat dan mengurangi beban pengembang.

ACM mengelola sertifikat secara otomatis

AWS Certificate Manager (ACM) dapat dengan mudah menyediakan, mengelola, menerapkan, dan memperbarui sertifikat SSL/TLS. Anda dapat langsung menerbitkan sertifikat melalui ACM untuk melindungi situs web dan aplikasi AWS Anda atau mengimpor sertifikat pihak ketiga ke dalam sistem manajemen ACM.

Dengan ACM, Anda tidak perlu lagi melalui proses manual yang panjang terkait penggunaan dan manajemen sertifikat SSL/TLS seperti sebelumnya. Anda juga dapat mengekspor sertifikat ACM yang ditandatangani oleh AWS Private CA untuk digunakan di lokasi mana pun dalam PKI internal Anda. Selain itu, ACM terintegrasi dengan AWS Elastic Load Balancing (ELB).

acm

Masalah apa yang diatasi oleh ACM Private CA?

Sertifikat yang ditandatangani sendiri digunakan untuk menerapkan aplikasi internal tanpa CA pribadi dalam suatu organisasi. Ketika aplikasi ini mencoba mengakses satu sama lain, mereka mungkin menolak akses satu sama lain karena sertifikat mereka tidak dipercaya. Mempercayai sumber aplikasi yang tidak dikenal secara membabi buta dapat menimbulkan risiko keamanan. Dalam hal ini, kita membutuhkan layanan Private CA yang dihosting untuk membuat dan mengelola hierarki CA guna memastikan bahwa semua aplikasi dalam organisasi dipercaya.

ACM Private CA adalah layanan yang dihosting dengan ketersediaan tinggi yang membuat dan memelihara PKI internal untuk organisasi Anda, menghilangkan biaya pemeliharaan berkelanjutan. Kunci pribadi disimpan dalam Hardware Security Modules (HSM) yang dihosting oleh AWS dan divalidasi oleh FIPS 140-2, yang menawarkan solusi organisasi penerbitan sertifikat yang lebih aman dibandingkan dengan CA default di Kubernetes.

pca

Bagaimana cara menggunakan ACM dengan Kubernetes?

Ada dua konfigurasi berbeda untuk mengakhiri sertifikat TLS di Kubernetes:

Configurations

  • Mengakhiri sertifikat TLS di Ingress: Ketika ada kebutuhan untuk enkripsi antara aplikasi, kita perlu mengakhiri TLS di controller Ingress. Setiap aplikasi dapat mengelola sertifikatnya sendiri melalui Ingress tanpa gangguan satu sama lain. Metode ini lebih mudah untuk dikonfigurasi dan dikelola serta memastikan bahwa komunikasi antara aplikasi dipercaya.
  • Mengakhiri sertifikat TLS di NLB: Mengakhiri sertifikat TLS di tingkat NLB adalah kasus penggunaan paling umum untuk menggunakan sertifikat yang dipercaya publik. Metode ini mudah untuk mengkonfigurasi dan mengikat sertifikat ACM yang dipercaya publik ke NLB. Akses ke aplikasi internal cluster masih menggunakan HTTP tanpa operasi enkripsi dan dekripsi tambahan.

Dalam contoh berikut, Anda dapat mengkonfigurasi APISIX Ingress langsung di Amazon EKS. Dengan menggunakan dua metode ini, kami akan menunjukkan bagaimana APISIX Ingress bekerja dengan ACM (dan ACM Private CA).

Prasyarat

Sebelum kita mulai, kita harus memenuhi persyaratan berikut:

  • AWS Akun AWS dan antarmuka baris perintah AWS (AWS CLI)
  • Anda harus memiliki izin untuk menggunakan peran IAM Amazon EKS dan peran terkait layanan AWS CloudFormation, Amazon Virtual Private Cloud (Amazon VPC) dan sumber daya terkait. Silakan periksa artikel ini di manual pengguna IAM "Operasi, sumber daya, dan kunci kondisi untuk Amazon Elastic Container Service for Kubernetes" dan gunakan peran terkait layanan. Selain itu, prinsip keamanan IAM ini perlu memiliki kebijakan IAM yang dikelola AWSCertificateManagerPrivateCAFullAccess yang dilampirkan.
  • Instal dan konfigurasi kubectl dan eksctl tools.

Kluster Amazon EKS

Amazon EKS adalah layanan yang dihosting yang memungkinkan Anda menjalankan Kubernetes di AWS dan dengan mudah menerapkan dan mengelola kluster Kubernetes Anda. Artikel ini akan menggunakan alat perintah eksctl untuk mengelola kluster.

  • gunakan konfigurasi default eksctl untuk membuat kluster (Silakan abaikan bagian ini jika Anda sudah memiliki kluster EKS)
eksctl create cluster

Instal APISIX Ingress

  1. Instal APISIX Ingress di kluster EKS, dan atur ke tipe 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

Catatan:

Pastikan kluster Anda dapat menambahkan volume persisten; silakan lihat Amazon EKS Storage untuk detail lebih lanjut. Jika Anda hanya ingin mencoba tutorial ini, konfigurasikan --set etcd.persistence.enabled=false selama instalasi untuk menyatakan bahwa volume persisten tidak akan digunakan.

  1. Jalankan perintah berikut untuk memeriksa status, dan pastikan semua pod dalam status 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. Periksa status NLB; perhatikan PORT(S) dan 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

Mengakhiri sertifikat TLS di NLB

Siapkan sertifikat ACM

  1. Buka konsol ACM, dan ajukan sertifikat ACM publik untuk domain kustom Anda atau impor sertifikat kustom.

acm

Konfigurasi sertifikat LoadBalancer

  1. Buka konsol EC2, dan pilih load balancers Anda -> listener -> edit

nlb-1

  1. Atur protokol NLB ke HTTPS, port ke 443, protokol instance ke HTTP dan port ke 30851

nlb-2

  1. Lampirkan sertifikat TLS dari ACM ke NLB.

nlb-3

Asosiasikan domain kustom dengan nama load balancer

Anda dapat menggunakan konsol penyedia DNS Anda untuk mengarahkan rekaman DNS aplikasi Anda ke URL NLB melalui CNAME. Misalnya, Route53 dan konfigurasikan rekaman CNAME yang mengarah ke NLB Anda.

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

Akses domain aplikasi

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

Mengakhiri sertifikat TLS di Ingress

Sebelum memulai contoh ini, pastikan konfigurasi AWS NLB telah dipulihkan, seperti yang ditunjukkan pada gambar berikut.

nls-0

Instal cert-manager

Cert-manager adalah add-on Kubernetes yang dapat secara otomatis mengelola dan menerbitkan sertifikat TLS dari berbagai sumber. Anda dapat menggunakan cara umum untuk menginstal cert-manager.

Buat ACM Private CA

  1. Buka konsol ACM PCA, pilih "Create a private CA", dan instal.

pca-1

  1. Setelah CA berhasil dibuat, dan statusnya aktif. ARN PCA akan sering digunakan di bagian selanjutnya.

pca-2

Atur izin node EKS untuk ACM Private CA

Secara default, tidak ada izin penerbitan. Untuk menerbitkan sertifikat dari ACM Private CA, Anda harus menambahkan kebijakan IAM ke EKS NodeInstanceRole, termasuk peran layanan iamserviceaccount.

  1. Buat file pca-iam-policy.json, dan Anda perlu mengganti ${PCA_ARN} dengan PCA_ARN Anda sendiri.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "${PCA_ARN}"
        }
    ]
}
  1. Buat IAM dan iamserviceaccount berdasarkan pca-iam-policy.json, dan perlu mengganti ${account_id} dengan ID AWS Anda.
aws iam create-policy \
    --policy-name AWSPCAIssuerIAMPolicy \
    --policy-document file://pca-iam-policy.json
# buat namespace
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

Instal aws-privateca-issuer

AWS PrivateCA Issuer berfungsi sebagai add-on cert-manager (External Issuers untuk menandatangani permintaan sertifikat.

  1. Gunakan Helm untuk menginstal
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. Periksa status
$ 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

Buat issuer dan ajukan sertifikat

  1. Ganti ${PCA_ARN} dalam file issuer-cert.yaml dengan konfigurasi Anda dan jalankan perintah berikut:
  • 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 # perlu diganti dengan nama domain kustom Anda
  dnsNames:
    - httpbin.example-test.org # perlu diganti dengan nama domain kustom Anda
  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. Jalankan perintah berikut untuk memverifikasi bahwa sertifikat telah diterbitkan dan rahasia telah dihasilkan.
$ 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

Publikasikan dan lindungi aplikasi httpbin

Pastikan APISIX Ingress telah berhasil diinstal. Silakan periksa bagian ini

  1. Terapkan aplikasi httpbin
kubectl run httpbin --image kennethreitz/httpbin --port 80
kubectl expose pod httpbin --port 80
  1. Buat Ingress untuk mempublikasikan dan melindungi aplikasi 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. Akses nama domain aplikasi

Pastikan nama domain kustom Anda dan nama load balancer telah diasosiasikan. Silakan periksa bagian ini

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

Kesimpulan

Artikel ini menunjukkan penggunaan APISIX Ingress dengan komponen AWS ACM dan ACM Private CA melalui contoh praktis dan memperkenalkan dua konfigurasi untuk mengakhiri sertifikat TLS di Kubernetes: Mengakhiri sertifikat TLS di NLB dan Ingress. Konfigurasi ACM + NLB lebih cocok untuk sertifikat yang dipercaya publik. Jika ada persyaratan untuk enkripsi antara aplikasi, ACM Private CA dapat menyediakan layanan manajemen yang dihosting yang lebih aman.

Kami berharap artikel praktis ini dapat membantu pembaca mengkonfigurasi dan mengelola lalu lintas TLS di kluster AWS EKS mereka dengan lebih efektif. Untuk informasi lebih lanjut tentang API gateway, silakan kunjungi blog atau Hubungi Kami.

Tags:
APISIX Ingress Controller
AWS
Kubernetes