Verwendung des APISIX Ingress Controllers mit AWS ACM

Xin Rong

December 30, 2022

Ecosystem

Warum benötigen wir AWS ACM?

Probleme durch manuelle Verwaltung

Ein Zertifikat enthält Informationen wie den Inhaber, den Aussteller und das Ablaufdatum, während ein abgelaufenes Zertifikat nicht mehr verwendet werden kann und vor Ablauf erneuert werden muss. Daher müssen die Zertifikatsinformationen aufgezeichnet werden, beispielsweise manuell in einer Tabelle, um sicherzustellen, dass Zertifikate rechtzeitig widerrufen und erneuert werden können.

Allerdings kann die manuelle Verwaltungsmethode bei einer immer größer werdenden Anzahl von Zertifikaten diese nicht mehr korrekt und effizient verwalten. Die Tabelle kann keine automatischen Benachrichtigungen senden, noch wird sie die automatische Erneuerung von Zertifikaten bei Ablauf durchführen, was unnötige Risiken mit sich bringt.

Um das Risiko von Zertifikatsunterbrechungen zu vermeiden und automatische Aktualisierungen gemäß neuen Informationen und Vorschriften zu gewährleisten, wurde die automatisierte Zertifikatsverwaltung eingeführt, die das Risiko von Zertifikatsabläufen reduziert und die Entwickler entlastet.

ACM verwaltet Zertifikate automatisch

AWS Certificate Manager (ACM) ermöglicht die einfache Bereitstellung, Verwaltung, Bereitstellung und Erneuerung von SSL/TLS-Zertifikaten. Sie können Zertifikate direkt über ACM ausstellen, um Ihre AWS-Websites und Anwendungen zu schützen, oder Drittanbieter-Zertifikate in das ACM-Verwaltungssystem importieren.

Mit ACM müssen Sie nicht mehr die umfangreichen manuellen Prozesse durchlaufen, die früher mit der Verwendung und Verwaltung von SSL/TLS-Zertifikaten verbunden waren. Sie können auch ACM-Zertifikate, die von AWS Private CA signiert wurden, exportieren, um sie an jedem Ort innerhalb Ihrer internen PKI zu verwenden. Darüber hinaus ist es in AWS Elastic Load Balancing (ELB) integriert.

acm

Welche Probleme löst ACM Private CA?

Selbstsignierte Zertifikate werden verwendet, um interne Anwendungen ohne eine private CA innerhalb einer Organisation bereitzustellen. Wenn diese Anwendungen versuchen, aufeinander zuzugreifen, können sie sich gegenseitig den Zugriff verweigern, da ihre Zertifikate nicht vertrauenswürdig sind. Das blinde Vertrauen in unbekannte Quellen von Anwendungen könnte Sicherheitsrisiken mit sich bringen. In diesem Fall benötigen wir einen gehosteten Private CA-Dienst, um eine CA-Hierarchie zu erstellen und zu verwalten, um sicherzustellen, dass alle Anwendungen innerhalb der Organisation vertrauenswürdig sind.

ACM Private CA ist ein hochverfügbarer gehosteter Dienst, der eine interne PKI für Ihre Organisation erstellt und verwaltet, wodurch die Kosten für kontinuierliche Wartung entfallen. Private Schlüssel werden in AWS-gehosteten Hardware Security Modules (HSM) gespeichert, die von FIPS 140-2 validiert sind, was eine sicherere Lösung für Zertifikatsausstellungsorganisationen im Vergleich zur Standard-CA in Kubernetes bietet.

pca

Wie verwendet man ACM mit Kubernetes?

Es gibt zwei verschiedene Konfigurationen, um TLS-Zertifikate in Kubernetes zu terminieren:

Konfigurationen

  • Terminierung von TLS-Zertifikaten in Ingress: Wenn eine Verschlüsselung zwischen Anwendungen erforderlich ist, müssen wir TLS im Ingress-Controller terminieren. Jede Anwendung kann ihr Zertifikat über Ingress verwalten, ohne sich gegenseitig zu beeinträchtigen. Diese Methode ist einfacher zu konfigurieren und zu verwalten und stellt sicher, dass die Kommunikation zwischen Anwendungen vertrauenswürdig ist.
  • Terminierung von TLS-Zertifikaten in NLB: Die Terminierung von TLS-Zertifikaten auf der NLB-Ebene ist der häufigste Anwendungsfall für die Verwendung öffentlich vertrauenswürdiger Zertifikate. Diese Methode ist einfach zu konfigurieren und bindet ein öffentlich vertrauenswürdiges ACM-Zertifikat an die NLB. Der Zugriff auf Anwendungen innerhalb des Clusters verwendet weiterhin HTTP ohne zusätzliche Verschlüsselungs- und Entschlüsselungsoperationen.

In den folgenden Beispielen können Sie APISIX Ingress direkt auf Amazon EKS konfigurieren. Mit diesen beiden Methoden werden wir demonstrieren, wie APISIX Ingress mit ACM (und ACM Private CA) zusammenarbeitet.

Voraussetzungen

Bevor wir beginnen, sollten die folgenden Anforderungen erfüllt sein:

  • AWS Ein AWS-Konto und die AWS-Befehlszeilenschnittstelle (AWS CLI)
  • Sie müssen über die Berechtigung verfügen, die Amazon EKS IAM-Rolle und dienstbezogene Rollen zu verwenden AWS CloudFormation, Amazon Virtual Private Cloud (Amazon VPC) und verwandte Ressourcen. Bitte überprüfen Sie diesen Artikel im IAM-Benutzerhandbuch "Operations, resources, and condition keys for Amazon Elastic Container Service for Kubernetes" und verwenden Sie dienstbezogene Rollen. Darüber hinaus muss dieser IAM-Sicherheitsprinzipal die AWSCertificateManagerPrivateCAFullAccess IAM-verwaltete Richtlinie angehängt haben.
  • Installieren und konfigurieren Sie die kubectl- und eksctl-Tools.

Amazon EKS-Cluster

Amazon EKS ist ein gehosteter Dienst, der es Ihnen ermöglicht, Kubernetes auf AWS auszuführen und Ihre Kubernetes-Cluster einfach bereitzustellen und zu verwalten. In diesem Artikel wird das eksctl-Befehlsprogramm zur Verwaltung von Clustern verwendet.

  • Verwenden Sie die eksctl-Standardkonfiguration, um Cluster zu erstellen (bitte ignorieren Sie diesen Teil, wenn Sie bereits über einen EKS-Cluster verfügen)
eksctl create cluster

Installieren von APISIX Ingress

  1. Installieren Sie APISIX Ingress im EKS-Cluster und setzen Sie ihn auf den Typ 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

Hinweis:

Bitte stellen Sie sicher, dass Ihr Cluster persistente Volumes hinzufügen kann; weitere Details finden Sie unter Amazon EKS Storage. Wenn Sie dieses Tutorial nur ausprobieren möchten, konfigurieren Sie --set etcd.persistence.enabled=false während der Installation, um anzugeben, dass keine persistenten Volumes verwendet werden.

  1. Führen Sie die folgenden Befehle aus, um den Status zu überprüfen, und stellen Sie sicher, dass alle Pods den Status Running haben.
$ 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. Überprüfen Sie den NLB-Status; achten Sie auf PORT(S) und 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

Terminierung von TLS-Zertifikaten in NLB

Vorbereiten des ACM-Zertifikats

  1. Öffnen Sie die ACM-Konsole und beantragen Sie ein öffentliches ACM-Zertifikat für Ihre benutzerdefinierte Domain oder importieren Sie ein benutzerdefiniertes Zertifikat.

acm

Konfigurieren des LoadBalancer-Zertifikats

  1. Öffnen Sie die EC2-Konsole und wählen Sie Ihre Load Balancers -> Listener -> Bearbeiten

nlb-1

  1. Setzen Sie das NLB-Protokoll auf HTTPS, den Port auf 443, das Instanzprotokoll auf HTTP und den Port auf 30851

nlb-2

  1. Hängen Sie das TLS-Zertifikat von ACM an die NLB an.

nlb-3

Verknüpfen der benutzerdefinierten Domain mit dem LoadBalancer-Namen

Sie können die Konsole Ihres DNS-Anbieters verwenden, um den DNS-Eintrag Ihrer Anwendung über CNAME auf die URL der NLB umzuleiten. Zum Beispiel Route53 und konfigurieren Sie die CNAME-Einträge, die auf Ihre NLB verweisen.

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

Zugriff auf die Anwendungsdomain

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

Terminierung von TLS-Zertifikaten in Ingress

Bevor wir mit diesem Beispiel beginnen, stellen Sie sicher, dass die Konfiguration der AWS NLB wiederhergestellt ist, wie im folgenden Bild gezeigt.

nls-0

Installieren von cert-manager

Cert-manager ist ein Kubernetes-Add-on, das automatisch TLS-Zertifikate aus verschiedenen Quellen verwalten und ausstellen kann. Sie verwenden eine gängige Methode, um den cert-manager zu installieren.

Erstellen einer ACM Private CA

  1. Öffnen Sie die ACM PCA-Konsole, wählen Sie "Create a private CA" und installieren Sie.

pca-1

  1. Nachdem die CA erfolgreich erstellt wurde und der Status aktiv ist, wird die ARN der PCA in den folgenden Abschnitten häufig verwendet.

pca-2

Einrichten von EKS-Knotenberechtigungen für ACM Private CA

Standardmäßig gibt es keine Ausstellungsberechtigung. Um ein Zertifikat von ACM Private CA auszustellen, müssen Sie eine IAM-Richtlinie zur EKS NodeInstanceRole hinzufügen, einschließlich der iamserviceaccount-Dienstrolle.

  1. Erstellen Sie die Datei pca-iam-policy.json, und Sie müssen ${PCA_ARN} durch Ihre eigene PCA_ARN ersetzen.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "${PCA_ARN}"
        }
    ]
}
  1. Erstellen Sie IAM und iamserviceaccount basierend auf pca-iam-policy.json, und ersetzen Sie ${account_id} durch Ihre AWS-ID.
aws iam create-policy \
    --policy-name AWSPCAIssuerIAMPolicy \
    --policy-document file://pca-iam-policy.json
# create 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

Installieren von aws-privateca-issuer

AWS PrivateCA Issuer dient als cert-manager-Add-on (Externe Aussteller), um Zertifikatsanforderungen zu signieren.

  1. Verwenden Sie Helm zur Installation
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. Überprüfen Sie den 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

Erstellen eines Ausstellers und Beantragen eines Zertifikats

  1. Ersetzen Sie ${PCA_ARN} in der Datei issuer-cert.yaml durch Ihre Konfiguration und führen Sie den folgenden Befehl aus:
  • 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 # muss durch Ihre benutzerdefinierte Domain ersetzt werden
  dnsNames:
    - httpbin.example-test.org # muss durch Ihre benutzerdefinierte Domain ersetzt werden
  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. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob das Zertifikat ausgestellt wurde und das Geheimnis generiert wurde.
$ 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

Veröffentlichen und Schützen der httpbin-Anwendung

Stellen Sie sicher, dass APISIX Ingress erfolgreich installiert wurde. Bitte überprüfen Sie diesen Abschnitt

  1. Stellen Sie die httpbin-Anwendung bereit
kubectl run httpbin --image kennethreitz/httpbin --port 80
kubectl expose pod httpbin --port 80
  1. Erstellen Sie Ingress, um die httpbin-Anwendung zu veröffentlichen und zu schützen
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. Zugriff auf die Anwendungsdomain

Stellen Sie sicher, dass Ihre benutzerdefinierte Domain und der Name des Load Balancers verknüpft sind. Bitte überprüfen Sie diesen Abschnitt

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

Fazit

Dieser Artikel demonstriert die Verwendung von APISIX Ingress mit AWS ACM und ACM Private CA-Komponenten durch praktische Beispiele und stellt zwei Konfigurationen für die Terminierung von TLS-Zertifikaten in Kubernetes vor: Terminierung von TLS-Zertifikaten in NLB und Ingress. Die ACM + NLB-Konfiguration ist besser für öffentlich vertrauenswürdige Zertifikate geeignet. Wenn eine Verschlüsselung zwischen Anwendungen erforderlich ist, kann ACM Private CA einen sichereren gehosteten Verwaltungsdienst bieten.

Wir hoffen, dass diese Praxisartikel den Lesern helfen, TLS-Datenverkehr in ihren AWS EKS-Clustern effektiver zu konfigurieren und zu verwalten. Weitere Informationen über API-Gateways finden Sie in unseren Blogs oder Kontaktieren Sie uns.

Tags:
APISIX Ingress Controller
AWS
Kubernetes