如何构建具有中央证书和身份验证管理的入口控制器

Question

我想以集中管理的安全方式将EKS中的一些网络应用程序公开到互联网。

在AWS中，使用ALB很好，例如它允许您终止TLS并使用Cognito添加身份验证。（见此处）

要预配ALB并将其连接到应用程序，有aws-load-balancer-控制器。它工作正常，但它需要每个应用程序/入口配置一个新的ALB：

  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/tags: Environment=test,Project=cognito
    external-dns.alpha.kubernetes.io/hostname: sample.${COK_MY_DOMAIN} 
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
    alb.ingress.kubernetes.io/auth-type: cognito
    alb.ingress.kubernetes.io/auth-scope: openid
    alb.ingress.kubernetes.io/auth-session-timeout: '3600'
    alb.ingress.kubernetes.io/auth-session-cookie: AWSELBAuthSessionCookie
    alb.ingress.kubernetes.io/auth-on-unauthenticated-request: authenticate
    alb.ingress.kubernetes.io/auth-idp-cognito: '{"UserPoolArn": "$(aws cognito-idp describe-user-pool --user-pool-id $COK_COGNITO_USER_POOL_ID --region $COK_AWS_REGION --query 'UserPool.Arn' --output text)","UserPoolClientId":"${COK_COGNITO_USER_POOL_CLIENT_ID}","UserPoolDomain":"${COK_COGNITO_DOMAIN}.auth.${COK_AWS_REGION}.amazoncognito.com"}'
    alb.ingress.kubernetes.io/certificate-arn: $COK_ACM_CERT_ARN 
    alb.ingress.kubernetes.io/target-type: 'ip'

我希望有一个中央定义良好的ALB，所有的应用程序都不需要再关心这个了。

我的想法是拥有一个常规的nginx入口控制器，并通过中央ALB将其公开。

现在的问题是：如何将ALB连接到nginx控制器？

一种方法是手动配置ALB并手动构建目标组，这感觉不像是一个稳定的解决方案。

另一种方法是使用aws负载平衡器控制器连接nginx。然而，在这种情况下，nginx似乎无法发布正确的负载平衡器地址，外部dns将输入错误的dns记录。（不幸的是，在nginx或traefik等常用入口控制器中似乎没有--发布入口选项。）

问题：

• 有没有办法让nginx入口控制器提供正确的地址

Answer 1

您可以使用两个入口控制器来实现这一点。ALB入口控制器将把公开的endpoint和路由流量交给作为后端的nginx入口控制器。然后配置nginx入口控制器以管理应用程序流量的入口。

Answer 2

我想我找到了一个很好的解决办法。

我使用terraform设置环境。设置alb入口控制器后，我可以创建一个合适的入口对象，等待alb启动，使用terraform提取alb的地址，并使用发布状态地址告诉nginx将该地址准确发布到其所有入口：

resource "kubernetes_ingress_v1" "alb" {
  wait_for_load_balancer = true
  metadata {
    name = "alb"
    namespace = "kube-system"
    annotations = {
      "alb.ingress.kubernetes.io/scheme" = "internet-facing"
      "alb.ingress.kubernetes.io/listen-ports" = "[{\"HTTP\": 80}, {\"HTTPS\":443}]"
      "alb.ingress.kubernetes.io/ssl-redirect" = "443"
      "alb.ingress.kubernetes.io/certificate-arn" = local.cert
      "alb.ingress.kubernetes.io/target-type" = "ip"
    }
  }
  spec {
    ingress_class_name = "alb"
    default_backend {
      service {
        name = "ing-nginx-ingress-nginx-controller"
        port {
          name = "http"
        }
      }
    }
  }
}

resource "helm_release" "ing-nginx" {
  name       = "ing-nginx"

  repository = "https://kubernetes.github.io/ingress-nginx"
  chart      = "ingress-nginx"
  namespace  = "kube-system"

  set {
    name  = "controller.service.type"
    value = "ClusterIP"
  }
  set {
    name  = "controller.publishService.enabled"
    value = "false"
  }
  set {
    name  = "controller.extraArgs.publish-status-address"
    value = kubernetes_ingress_v1.alb.status.0.load_balancer.0.ingress.0.hostname
  }
  set {
    name  = "controller.config.use-forwarded-headers"
    value = "true"
  }
  set {
    name  = "controller.ingressClassResource.default"
    value = "true"
  }
}

这有点奇怪，因为它引入了类似循环依赖的东西，但入口只是等待nginx最终启动，一切正常。

此解决方案与--发布入口选项不完全相同，因为它将无法适应ALB地址的任何更改。-幸运的是，我不希望地址改变，所以我对这个解决方案没意见。