Использование APISIX Ingress Controller с AWS ACM

Xin Rong

December 30, 2022

Ecosystem

Зачем нужен AWS ACM?

Проблемы ручного управления

Сертификат содержит информацию о владельце, издателе и сроке действия, при этом истекший сертификат нельзя использовать, и его необходимо обновить до истечения срока действия. Поэтому информацию о сертификате необходимо записывать, например, вручную в таблицу, чтобы гарантировать, что сертификаты могут быть отозваны и обновлены вовремя.

Однако с увеличением количества сертификатов ручной метод управления становится неэффективным и ненадежным. Таблица не может отправлять автоматические уведомления, а также не может автоматически обновлять сертификаты по истечении срока их действия, что создает ненужные риски.

Чтобы избежать риска прерывания работы сертификатов и обеспечить автоматическое обновление в соответствии с новыми данными и правилами, появилось автоматизированное управление сертификатами, которое снижает риски истечения срока действия сертификатов и освобождает разработчиков от лишней работы.

ACM автоматически управляет сертификатами

AWS Certificate Manager (ACM) позволяет легко создавать, управлять, развертывать и обновлять SSL/TLS-сертификаты. Вы можете напрямую выпускать сертификаты через ACM для защиты своих веб-сайтов и приложений на AWS или импортировать сторонние сертификаты в систему управления ACM.

С ACM вам больше не нужно проходить сложные ручные процессы, связанные с использованием и управлением SSL/TLS-сертификатами, как раньше. Вы также можете экспортировать сертификаты ACM, подписанные AWS Private CA, для использования в любом месте вашей внутренней PKI. Кроме того, он интегрирован с AWS Elastic Load Balancing (ELB).

acm

Какие проблемы решает ACM Private CA?

Самоподписанные сертификаты используются для развертывания внутренних приложений без какого-либо частного CA внутри организации. Когда эти приложения пытаются получить доступ друг к другу, они могут отказать в доступе, поскольку их сертификаты не доверены. Слепое доверие неизвестным источникам приложений может привести к рискам безопасности. В этом случае нам нужен управляемый сервис Private CA для создания и управления иерархией CA, чтобы гарантировать, что все приложения внутри организации доверены.

ACM Private CA — это высокодоступный управляемый сервис, который создает и поддерживает внутреннюю PKI для вашей организации, устраняя затраты на постоянное обслуживание. Закрытые ключи хранятся в аппаратных модулях безопасности (HSM), размещенных в AWS и сертифицированных по стандарту FIPS 140-2, что обеспечивает более безопасное решение для организаций, выпускающих сертификаты, по сравнению с CA по умолчанию в Kubernetes.

pca

Как использовать ACM с Kubernetes?

Существует две различные конфигурации для завершения TLS-сертификатов в Kubernetes:

Configurations

  • Завершение TLS-сертификатов в Ingress: Когда требуется шифрование между приложениями, нам нужно завершить TLS в контроллере Ingress. Каждое приложение может управлять своим сертификатом через Ingress, не мешая друг другу. Этот метод проще в настройке и управлении и гарантирует, что связь между приложениями доверена.
  • Завершение TLS-сертификатов в NLB: Завершение TLS-сертификатов на уровне NLB — это наиболее распространенный случай использования публично доверенных сертификатов. Этот метод прост в настройке и позволяет привязать публично доверенный сертификат ACM к NLB. Доступ к приложениям внутри кластера по-прежнему использует HTTP без дополнительных операций шифрования и дешифрования.

В следующих примерах вы сможете настроить APISIX Ingress напрямую на Amazon EKS. Используя эти два метода, мы покажем, как APISIX Ingress работает с ACM (и ACM Private CA).

Предварительные требования

Прежде чем мы начнем, необходимо выполнить следующие требования:

  • AWS Учетная запись AWS и интерфейс командной строки AWS (AWS CLI)
  • У вас должны быть права на использование роли IAM Amazon EKS и связанных с сервисом ролей AWS CloudFormation, Amazon Virtual Private Cloud (Amazon VPC) и связанных ресурсов. Пожалуйста, ознакомьтесь с этой статьей в руководстве пользователя IAM "Операции, ресурсы и ключи условий для Amazon Elastic Container Service for Kubernetes" и используйте связанные с сервисом роли. Кроме того, этому субъекту безопасности IAM необходимо прикрепить управляемую политику IAM AWSCertificateManagerPrivateCAFullAccess.
  • Установите и настройте инструменты kubectl и eksctl.

Кластер Amazon EKS

Amazon EKS — это управляемый сервис, который позволяет запускать Kubernetes на AWS и легко развертывать и управлять кластерами Kubernetes. В этой статье будет использоваться инструмент командной строки eksctl для управления кластерами.

  • Используйте конфигурацию по умолчанию eksctl для создания кластеров (пропустите эту часть, если у вас уже есть кластер EKS)
eksctl create cluster

Установка APISIX Ingress

  1. Установите APISIX Ingress в кластере EKS и установите тип 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

Примечание:

Убедитесь, что ваш кластер может добавлять постоянные тома; подробнее см. Amazon EKS Storage. Если вы просто хотите попробовать этот учебник, настройте --set etcd.persistence.enabled=false во время установки, чтобы указать, что постоянные тома не будут использоваться.

  1. Выполните следующие команды для проверки статуса и убедитесь, что все поды находятся в состоянии 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. Проверьте статус NLB; обратите внимание на PORT(S) и 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

Завершение TLS-сертификатов в NLB

Подготовка сертификата ACM

  1. Откройте консоль ACM и запросите публичный сертификат ACM для вашего пользовательского домена или импортируйте пользовательский сертификат.

acm

Настройка сертификата для LoadBalancer

  1. Откройте консоль EC2 и выберите ваши балансировщики нагрузки -> слушатели -> редактировать

nlb-1

  1. Установите протокол NLB на HTTPS, порт на 443, протокол экземпляра на HTTP и порт на 30851

nlb-2

  1. Прикрепите TLS-сертификат из ACM к NLB.

nlb-3

Связывание пользовательского домена с именем балансировщика нагрузки

Вы можете использовать консоль вашего DNS-провайдера, чтобы направить DNS-запись вашего приложения на URL NLB через CNAME. Например, Route53 и настройте записи CNAME, которые указывают на ваш NLB.

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

Доступ к домену приложения

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

Завершение TLS-сертификатов в Ingress

Прежде чем начать этот пример, убедитесь, что конфигурация AWS NLB восстановлена, как показано на следующем изображении.

nls-0

Установка cert-manager

Cert-manager — это дополнение Kubernetes, которое может автоматически управлять и выпускать TLS-сертификаты из различных источников. Вы можете использовать стандартный способ для установки cert-manager.

Создание ACM Private CA

  1. Откройте консоль ACM PCA, выберите "Создать частный CA" и установите.

pca-1

  1. После успешного создания CA и его активного статуса ARN PCA будет часто использоваться в последующих разделах.

pca-2

Настройка разрешений для узлов EKS для ACM Private CA

По умолчанию нет разрешений на выпуск. Чтобы выпустить сертификат из ACM Private CA, необходимо добавить политику IAM к роли EKS NodeInstanceRole, включая роль сервиса iamserviceaccount.

  1. Создайте файл pca-iam-policy.json, и вам нужно заменить ${PCA_ARN} на ваш собственный 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. Создайте IAM и iamserviceaccount на основе pca-iam-policy.json, и замените ${account_id} на ваш AWS ID.
aws iam create-policy \
    --policy-name AWSPCAIssuerIAMPolicy \
    --policy-document file://pca-iam-policy.json
# создание пространства имен
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

Установка aws-privateca-issuer

AWS PrivateCA Issuer служит дополнением к cert-manager (Внешние издатели для подписания запросов на сертификаты.

  1. Используйте Helm для установки
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. Проверьте статус
$ 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

Создание издателя и запрос сертификата

  1. Замените ${PCA_ARN} в файле issuer-cert.yaml на вашу конфигурацию и выполните следующую команду:
  • 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 # замените на ваш пользовательский домен
  dnsNames:
    - httpbin.example-test.org # замените на ваш пользовательский домен
  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. Выполните следующую команду, чтобы убедиться, что сертификат был выпущен и секрет был создан.
$ 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

Публикация и защита приложения httpbin

Убедитесь, что APISIX Ingress успешно установлен. Пожалуйста, проверьте этот раздел

  1. Разверните приложение httpbin
kubectl run httpbin --image kennethreitz/httpbin --port 80
kubectl expose pod httpbin --port 80
  1. Создайте Ingress для публикации и защиты приложения 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. Доступ к домену приложения

Убедитесь, что ваш пользовательский домен и имя балансировщика нагрузки связаны. Пожалуйста, проверьте этот раздел

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

Заключение

Эта статья демонстрирует использование APISIX Ingress с компонентами AWS ACM и ACM Private CA на практических примерах и представляет две конфигурации для завершения TLS-сертификатов в Kubernetes: завершение TLS-сертификатов в NLB и Ingress. Конфигурация ACM + NLB больше подходит для публично доверенных сертификатов. Если требуется шифрование между приложениями, ACM Private CA может предоставить более безопасный управляемый сервис.

Мы надеемся, что эти практические статьи помогут читателям более эффективно настраивать и управлять TLS-трафиком в своих кластерах AWS EKS. Для получения дополнительной информации о API-шлюзах, пожалуйста, посетите блоги или свяжитесь с нами.

Tags:
APISIX Ingress Controller
AWS
Kubernetes