Utilisation du contrôleur APISIX Ingress avec AWS ACM

Xin Rong

December 30, 2022

Ecosystem

Pourquoi avons-nous besoin d'AWS ACM ?

Problèmes causés par la gestion manuelle

Un certificat contient des informations telles que le titulaire, l'émetteur et la date d'expiration, tandis que le certificat expiré ne peut plus être utilisé et doit être renouvelé avant son expiration. Par conséquent, les informations du certificat doivent être enregistrées, par exemple, manuellement dans un tableur, pour s'assurer que les certificats peuvent être révoqués et renouvelés à temps.

Cependant, à mesure que le nombre de certificats augmente, la méthode de gestion manuelle ne peut pas gérer les certificats de manière correcte et efficace. Le tableur ne peut pas envoyer de notification automatique, ni automatiser le renouvellement des certificats lorsqu'ils expirent, ce qui entraîne des risques inutiles.

Afin d'éviter le risque d'interruption des certificats et de maintenir des mises à jour automatiques conformes aux nouvelles informations et réglementations, la gestion automatisée des certificats est apparue, réduisant les risques d'expiration des certificats et allégeant la charge des développeurs.

ACM gère les certificats automatiquement

AWS Certificate Manager (ACM) permet de provisionner, gérer, déployer et renouveler facilement les certificats SSL/TLS. Vous pouvez directement émettre des certificats via ACM pour protéger vos sites web et applications AWS ou importer des certificats tiers dans le système de gestion d'ACM.

Avec ACM, vous n'avez plus besoin de passer par les processus manuels fastidieux associés à l'utilisation et à la gestion des certificats SSL/TLS comme auparavant. Vous pouvez également exporter des certificats ACM signés par AWS Private CA pour les utiliser à n'importe quel endroit de votre PKI interne. De plus, il est intégré à AWS Elastic Load Balancing (ELB).

acm

Quels problèmes ACM Private CA résout-il ?

Les certificats auto-signés sont utilisés pour déployer des applications internes sans aucune autorité de certification (CA) privée au sein d'une organisation. Lorsque ces applications tentent d'accéder les unes aux autres, elles peuvent refuser l'accès mutuel car leurs certificats ne sont pas approuvés. Faire aveuglément confiance à des sources inconnues d'applications pourrait entraîner des risques de sécurité. Dans ce cas, nous avons besoin d'un service hébergé de CA privé pour créer et gérer une hiérarchie de CA afin de garantir que toutes les applications au sein de l'organisation sont approuvées.

ACM Private CA est un service hébergé hautement disponible qui crée et maintient une PKI interne pour votre organisation, éliminant les coûts de maintenance continue. Les clés privées sont stockées dans des modules de sécurité matérielle (HSM) hébergés par AWS et validés par FIPS 140-2, offrant une solution plus sécurisée pour les organisations émettrices de certificats par rapport à la CA par défaut dans Kubernetes.

pca

Comment utiliser ACM avec Kubernetes ?

Il existe deux configurations différentes pour terminer les certificats TLS dans Kubernetes :

Configurations

  • Terminer les certificats TLS dans Ingress : Lorsqu'il est nécessaire de chiffrer les communications entre les applications, nous devons terminer TLS dans le contrôleur Ingress. Chaque application peut gérer son certificat via Ingress sans interférence mutuelle. Cette méthode est plus facile à configurer et à gérer et garantit que la communication entre les applications est approuvée.
  • Terminer les certificats TLS dans NLB : Terminer les certificats TLS au niveau du NLB est le cas d'utilisation le plus courant pour les certificats publics approuvés. Cette méthode est facile à configurer et permet de lier un certificat ACM approuvé publiquement au NLB. L'accès aux applications internes du cluster utilise toujours HTTP sans aucune opération de chiffrement et de déchiffrement supplémentaire.

Dans les exemples suivants, vous pouvez configurer APISIX Ingress directement sur Amazon EKS. En utilisant ces deux méthodes, nous démontrerons comment APISIX Ingress fonctionne avec ACM (et ACM Private CA).

Prérequis

Avant de commencer, nous devons remplir les conditions suivantes :

  • AWS Un compte AWS et l'interface de ligne de commande AWS (AWS CLI)
  • Vous devez avoir l'autorisation d'utiliser le rôle IAM Amazon EKS et les rôles de service associés AWS CloudFormation, Amazon Virtual Private Cloud (Amazon VPC) et les ressources associées. Veuillez consulter cet article dans le manuel utilisateur IAM "Opérations, ressources et clés de condition pour Amazon Elastic Container Service for Kubernetes" et utiliser les rôles de service liés. De plus, ce principal de sécurité IAM doit avoir la politique gérée IAM AWSCertificateManagerPrivateCAFullAccess attachée.
  • Installez et configurez kubectl et eksctl.

Cluster Amazon EKS

Amazon EKS est un service hébergé qui vous permet d'exécuter Kubernetes sur AWS et de déployer et gérer facilement vos clusters Kubernetes. Cet article utilisera l'outil de commande eksctl pour gérer les clusters.

  • Utilisez la configuration par défaut d'eksctl pour créer des clusters (ignorez cette partie si vous avez déjà un cluster EKS)
eksctl create cluster

Installer APISIX Ingress

  1. Installez APISIX Ingress dans le cluster EKS et définissez-le comme type 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

Remarque :

Assurez-vous que votre cluster peut ajouter des volumes persistants ; consultez Amazon EKS Storage pour plus de détails. Si vous souhaitez simplement essayer ce tutoriel, configurez --set etcd.persistence.enabled=false lors de l'installation pour déclarer que les volumes persistants ne seront pas utilisés.

  1. Exécutez les commandes suivantes pour vérifier l'état et assurez-vous que tous les pods sont en état 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. Vérifiez l'état du NLB ; faites attention au PORT(S) et à l'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

Terminer les certificats TLS dans NLB

Préparer un certificat ACM

  1. Ouvrez la console ACM et demandez un certificat ACM public pour votre domaine personnalisé ou importez un certificat personnalisé.

acm

Configurer le certificat sur le LoadBalancer

  1. Ouvrez la console EC2, sélectionnez vos load balancers -> listener -> edit

nlb-1

  1. Définissez le protocole NLB sur HTTPS, le port sur 443, le protocole de l'instance sur HTTP et le port sur 30851

nlb-2

  1. Attachez le certificat TLS d'ACM au NLB.

nlb-3

Associer le domaine personnalisé au nom du load balancer

Vous pouvez utiliser la console de votre fournisseur DNS pour diriger l'enregistrement DNS de votre application vers l'URL du NLB via CNAME. Par exemple, Route53 et configurer les enregistrements CNAME qui pointent vers votre NLB.

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

Accéder au domaine de l'application

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

Terminer le certificat TLS dans Ingress

Avant de commencer cet exemple, assurez-vous que la configuration du NLB AWS est restaurée, comme indiqué dans l'image suivante.

nls-0

Installer cert-manager

Cert-manager est un module complémentaire Kubernetes qui peut gérer et émettre automatiquement des certificats TLS à partir de diverses sources. Vous pouvez utiliser une méthode courante pour installer cert-manager.

Créer une ACM Private CA

  1. Ouvrez la console ACM PCA, choisissez "Create a private CA" et installez.

pca-1

  1. Une fois la CA créée avec succès et que son statut est actif. L'ARN de la PCA sera fréquemment utilisé dans les sections suivantes.

pca-2

Configurer les permissions des nœuds EKS pour ACM Private CA

Par défaut, il n'y a pas de permission d'émission. Pour émettre un certificat à partir d'ACM Private CA, vous devez ajouter une politique IAM au rôle EKS NodeInstanceRole, y compris le rôle de service iamserviceaccount.

  1. Créez le fichier pca-iam-policy.json, et vous devez remplacer ${PCA_ARN} par votre propre PCA_ARN.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "${PCA_ARN}"
        }
    ]
}
  1. Créez IAM et iamserviceaccount en fonction de pca-iam-policy.json, et remplacez ${account_id} par votre ID AWS.
aws iam create-policy \
    --policy-name AWSPCAIssuerIAMPolicy \
    --policy-document file://pca-iam-policy.json
# créer un 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

Installer aws-privateca-issuer

AWS PrivateCA Issuer sert de module complémentaire à cert-manager (External Issuers pour signer les demandes de certificats.

  1. Utilisez Helm pour installer
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. Vérifiez l'état
$ 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

Créer un émetteur et demander un certificat

  1. Remplacez ${PCA_ARN} dans le fichier issuer-cert.yaml par votre configuration et exécutez la commande suivante :
  • 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 # remplacez par votre nom de domaine personnalisé
  dnsNames:
    - httpbin.example-test.org # remplacez par votre nom de domaine personnalisé
  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. Exécutez la commande suivante pour vérifier que le certificat a été émis et que le secret a été généré.
$ 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

Publier et protéger l'application httpbin

Assurez-vous qu'APISIX Ingress a été installé avec succès. Veuillez vérifier cette section

  1. Déployez l'application httpbin
kubectl run httpbin --image kennethreitz/httpbin --port 80
kubectl expose pod httpbin --port 80
  1. Créez Ingress pour publier et protéger l'application 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. Accédez au nom de domaine de l'application

Assurez-vous que votre nom de domaine personnalisé et le nom du load balancer ont été associés. Veuillez vérifier cette section

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

Conclusion

Cet article démontre l'utilisation d'APISIX Ingress avec les composants AWS ACM et ACM Private CA à travers des exemples pratiques et présente deux configurations pour terminer les certificats TLS dans Kubernetes : Terminer les certificats TLS dans NLB et Ingress. La configuration ACM + NLB est plus adaptée aux certificats publics approuvés. S'il y a une exigence de chiffrement entre les applications, ACM Private CA peut fournir un service de gestion hébergé plus sécurisé.

Nous espérons que ces articles pratiques aideront les lecteurs à configurer et gérer plus efficacement le trafic TLS dans leurs clusters AWS EKS. Pour plus d'informations sur la passerelle API, veuillez visiter blogs ou Contactez-nous.

Tags:
APISIX Ingress Controller
AWS
Kubernetes