Usando o APISIX Ingress Controller com AWS ACM

Xin Rong

December 30, 2022

Ecosystem

Por que precisamos do AWS ACM?

Problemas causados pelo gerenciamento manual

Um certificado contém informações como o titular, o emissor e a data de expiração, enquanto o certificado expirado não pode ser usado e precisa ser renovado antes de expirar. Portanto, as informações do certificado devem ser registradas, por exemplo, manualmente em uma planilha, para garantir que os certificados possam ser revogados e renovados a tempo.

No entanto, à medida que há cada vez mais certificados, o método de gerenciamento manual não consegue gerenciar os certificados de forma correta e eficiente. A planilha não pode enviar uma notificação automática, nem automatizar a renovação do certificado quando ele expirar, trazendo riscos desnecessários.

Para evitar o risco de interrupção do certificado e manter atualizações automáticas de acordo com novas informações e regulamentações, o gerenciamento automatizado de certificados surge, reduzindo os riscos de expiração dos certificados e aliviando a carga dos desenvolvedores.

O ACM gerencia certificados automaticamente

O AWS Certificate Manager (ACM) pode provisionar, gerenciar, implantar e renovar facilmente certificados SSL/TLS. Você pode emitir certificados diretamente por meio do ACM para proteger seus sites e aplicativos na AWS ou importar certificados de terceiros para o sistema de gerenciamento do ACM.

Com o ACM, você não precisa mais passar pelos extensos processos manuais associados ao uso e gerenciamento de certificados SSL/TLS como antes. Você também pode exportar certificados do ACM assinados pela AWS Private CA para usar em qualquer local dentro de sua PKI interna. Além disso, ele é integrado ao AWS Elastic Load Balancing (ELB).

acm

Quais problemas o ACM Private CA resolve?

Certificados autoassinados são usados para implantar aplicativos internos sem nenhuma CA privada dentro de uma organização. Quando esses aplicativos tentam acessar uns aos outros, eles podem recusar o acesso um do outro porque seus certificados não são confiáveis. Confiar cegamente em fontes desconhecidas de aplicativos pode trazer riscos de segurança. Nesse caso, precisamos de um serviço de CA privada hospedado para criar e gerenciar uma hierarquia de CA, garantindo que todos os aplicativos dentro da organização sejam confiáveis.

O ACM Private CA é um serviço hospedado altamente disponível que cria e mantém uma PKI interna para sua organização, eliminando o custo de manutenção contínua. As chaves privadas são armazenadas em Módulos de Segurança de Hardware (HSM) hospedados pela AWS validados pelo FIPS 140-2, o que oferece uma solução mais segura para organizações emissoras de certificados em comparação com a CA padrão no Kubernetes.

pca

Como usar o ACM com o Kubernetes?

Existem duas configurações diferentes para terminar certificados TLS no Kubernetes:

Configurações

  • Terminar certificados TLS no Ingress: Quando há necessidade de criptografia entre aplicativos, precisamos terminar o TLS no controlador Ingress. Cada aplicativo pode gerenciar seu certificado por meio do Ingress sem interferência um do outro. Esse método é mais fácil de configurar e gerenciar e garante que a comunicação entre os aplicativos seja confiável.
  • Terminar certificados TLS no NLB: Terminar certificados TLS no nível do NLB é o caso de uso mais comum para usar certificados publicamente confiáveis. Esse método é fácil de configurar e vincular um certificado publicamente confiável do ACM ao NLB. O acesso aos aplicativos internos do cluster ainda usa HTTP sem nenhuma operação adicional de criptografia e descriptografia.

Nos exemplos a seguir, você pode configurar o APISIX Ingress diretamente no Amazon EKS. Usando esses dois métodos, demonstraremos como o APISIX Ingress funciona com o ACM (e o ACM Private CA).

Pré-requisitos

Antes de começarmos, devemos atender aos seguintes requisitos:

  • AWS Uma conta AWS e a interface de linha de comando da AWS (AWS CLI)
  • Você deve ter permissão para usar a função IAM do Amazon EKS e as funções de serviço relacionadas AWS CloudFormation, Amazon Virtual Private Cloud (Amazon VPC) e recursos relacionados. Por favor, verifique este artigo no manual do usuário IAM "Operações, recursos e chaves de condição para o Amazon Elastic Container Service for Kubernetes" e use funções de serviço relacionadas. Além disso, esse principal de segurança IAM precisa ter a política gerenciada IAM AWSCertificateManagerPrivateCAFullAccess anexada.
  • Instale e configure as ferramentas kubectl e eksctl.

Cluster Amazon EKS

O Amazon EKS é um serviço hospedado que permite executar o Kubernetes na AWS e implantar e gerenciar facilmente seus clusters Kubernetes. Este artigo usará a ferramenta de comando eksctl para gerenciar clusters.

  • use a configuração padrão do eksctl para criar clusters (Ignore esta parte se você já tiver um cluster EKS)
eksctl create cluster

Instalar o APISIX Ingress

  1. Instale o APISIX Ingress no cluster EKS e defina-o como tipo 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

Observação:

Certifique-se de que seu cluster possa adicionar volumes persistentes; consulte Amazon EKS Storage para mais detalhes. Se você apenas deseja experimentar este tutorial, configure --set etcd.persistence.enabled=false durante a instalação para declarar que volumes persistentes não serão usados.

  1. Execute os seguintes comandos para verificar o status e certifique-se de que todos os pods estejam no 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. Verifique o status do NLB; preste atenção ao PORT(S) e 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

Terminar certificados TLS no NLB

Preparar o certificado ACM

  1. Abra o console ACM e solicite um certificado ACM público para seu domínio personalizado ou importe um certificado personalizado.

acm

Configurar o certificado no LoadBalancer

  1. Abra o console EC2 e selecione seus load balancers -> listener -> edit

nlb-1

  1. Defina o protocolo do NLB como HTTPS, a porta como 443, o protocolo da instância como HTTP e a porta como 30851.

nlb-2

  1. Anexe o certificado TLS do ACM ao NLB.

nlb-3

Associar o domínio personalizado ao nome do load balancer

Você pode usar o console do seu provedor de DNS para direcionar o registro DNS do seu aplicativo para o URL do NLB via CNAME. Por exemplo, Route53 e configurar os registros CNAME que direcionam para o seu NLB.

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

Acessar o domínio do aplicativo

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

Terminar o certificado TLS no Ingress

Antes de começarmos este exemplo, certifique-se de que a configuração do AWS NLB foi restaurada, conforme mostrado na imagem a seguir.

nls-0

Instalar o cert-manager

O cert-manager é um complemento do Kubernetes que pode gerenciar e emitir automaticamente certificados TLS de várias fontes. Você usa uma maneira comum para instalar o cert-manager.

Criar o ACM Private CA

  1. Abra o console ACM PCA, escolha "Create a private CA" e instale.

pca-1

  1. Após a criação bem-sucedida da CA e o status estar ativo. O ARN da PCA será frequentemente usado nas seções posteriores.

pca-2

Configurar permissões do nó EKS para o ACM Private CA

Por padrão, não há permissão de emissão. Para emitir um certificado do ACM Private CA, você deve adicionar uma política IAM ao EKS NodeInstanceRole, incluindo a função de serviço iamserviceaccount.

  1. Crie o arquivo pca-iam-policy.json e você precisa substituir ${PCA_ARN} pelo seu próprio 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. Crie IAM e iamserviceaccount com base no pca-iam-policy.json e substitua ${account_id} pelo seu ID da AWS.
aws iam create-policy \
    --policy-name AWSPCAIssuerIAMPolicy \
    --policy-document file://pca-iam-policy.json
# criar 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

Instalar o aws-privateca-issuer

O AWS PrivateCA Issuer serve como um complemento do cert-manager (Emissores Externos para assinar solicitações de certificados.

  1. Use o Helm para instalar
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. Verifique o 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

Criar emissor e solicitar certificado

  1. Substitua ${PCA_ARN} no arquivo issuer-cert.yaml com sua configuração e execute o seguinte comando:
  • 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 # substitua com seu domínio personalizado
  dnsNames:
    - httpbin.example-test.org # substitua com seu domínio personalizado
  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. Execute o seguinte comando para verificar se o certificado foi emitido e o segredo foi gerado.
$ 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

Publicar e proteger o aplicativo httpbin

Certifique-se de que o APISIX Ingress foi instalado com sucesso. Por favor, verifique esta seção

  1. Implante o aplicativo httpbin
kubectl run httpbin --image kennethreitz/httpbin --port 80
kubectl expose pod httpbin --port 80
  1. Crie o Ingress para publicar e proteger o aplicativo 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. Acesse o nome de domínio do aplicativo

Certifique-se de que seu nome de domínio personalizado e o nome do load balancer foram associados. Por favor, verifique esta seção

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

Conclusão

Este artigo demonstra o uso do APISIX Ingress com os componentes AWS ACM e ACM Private CA por meio de exemplos práticos e apresenta duas configurações para terminar certificados TLS no Kubernetes: Terminar certificados TLS no NLB e no Ingress. A configuração ACM + NLB é mais adequada para certificados publicamente confiáveis. Se houver uma necessidade de criptografia entre aplicativos, o ACM Private CA pode fornecer um serviço de gerenciamento hospedado mais seguro.

Esperamos que esses artigos práticos possam ajudar os leitores a configurar e gerenciar o tráfego TLS em seus clusters AWS EKS de forma mais eficaz. Para mais informações sobre gateway de API, visite blogs ou Contate-nos.

Tags:
APISIX Ingress Controller
AWS
Kubernetes