nginx-ingress не работает с AWS ELB при использовании aws-load-balancer-backend-protocol: "https" - PullRequest
Новая
       19

nginx-ingress не работает с AWS ELB при использовании aws-load-balancer-backend-protocol: "https"

0 голосов
/ 26 сентября 2018

Я использую AWS EKS в качестве плоскости управления k8s и развернул группу автоматического масштабирования из 3 узлов в качестве моих рабочих узлов (узлы K8s). Эта группа автоматического масштабирования находится в моем VPC.И я убедился, что группы безопасности открыты, по крайней мере, достаточно разрешительно для взаимодействия между узлом и ELB.

Я пытаюсь использовать nginx-ingress для маршрутизации трафика вне кластера k8s.Я использую helm для развертывания моего nginx-входа с использованием values.yaml.

Мой values.yaml выглядит следующим образом: 

serviceAccount:
  create: true
  name: nginx-ingress-sa
rbac:
  create: true

controller:
   kind: "Deployment"
   service:
      type: "LoadBalancer"
  # targetPorts:
  #   http: 80
  #   https: http
   loadBalancerSourceRanges: 
      - 1.2.3.4/32
  annotations:
      service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "https"
      service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
      service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789:certificate/my-cert
      service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: sg-12345678
      service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: '3600'
      nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
      nginx.ingress.kubernetes.io/enable-access-log: "true"
  config:
    log-format-escape-json: "true"
    log-format-upstream: '{"real_ip" : "$the_real_ip", "remote_user": "$remote_user", "time_iso8601": "$time_iso8601", "request": "$request", "request_method" : "$request_method", "status": "$status", "upstream_addr": $upstream_addr", "upstream_status": "$upstream_status"}'
  extraArgs:
    v: 3 # NGINX log level

Мой вход yaml: 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress-1
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/enable-access-log: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  rules:
  - host: "s1.testk8.dev.mydomain.net"
    http:
      paths:
      - path: /
        backend:
          serviceName: s1-service
          servicePort: 443
  - host: "s2.testk8.dev.mydomain.net"
    http:
      paths:
      - path: /
        backend:
          serviceName: s2-service
          servicePort: 443
  tls:
  - hosts:
    - "s1.testk8.dev.mydomain.net"
    - "s2.testk8.dev.mydomain.net"
    secretName: "testk8.dev.mydomain.net"

Обратите внимание, что этот секрет является самозаверяющим сертификатом TLS в домене * .mydomain.net.

В настоящее время этот параметр работает так, что если ввести

https://s1.testk8.dev.mydomain.netв хроме он просто зависает.В нижнем левом углу написано ожидание s1.testk8.dev.mydomain.net.

Если я использую: 

curl -vk https://s1.testk8.dev.mydomain.net

Возвращает: 

*   Trying x.x.x.x...
* TCP_NODELAY set
* Connected to s1.testk8.dev.mydomain.net (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.mydomain.net
*  start date: Apr 25 00:00:00 2018 GMT
*  expire date: May 25 12:00:00 2019 GMT
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: s1.testk8.dev.steelcentral.net
> User-Agent: curl/7.54.0
> Accept: */*
>

И это также, кажется, ждет ответа сервера.

Я также пытался настроить values.yaml, и когда я изменяю 

service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http" # instead of https as above

, тогда я нажимаю на URL https://s1.testk8.dev.mydomain.netЯ могу хотя бы увидеть сообщение HTTP 400 (простой HTTP-запрос, отправленный на порт HTTPS) с модуля входного контроллера.

Если раскомментировать эти строки в values.yaml: 

# targetPorts:
  #   http: 80
  #   https: http

Я могу связаться с моим модулем бэкэнда (контролируемым набором состояний, которого здесь нет в списке.), Я вижу журнал доступа моего модуля бэкенда с новыми записями.

Не уверен, что мой вариант использования здесь странный, посколькуЯ вижу, что многие люди используют nginx-ingress на AWS, они заканчивают TLS на ELB.Но мне нужно разрешить своему внутреннему модулю завершить TLS.

Я также попробовал флаг ssl-passthrough, не помогло.Когда backend-protocal имеет значение https, мой запрос даже не достигает входного контроллера, поэтому говорить о ssl-passthrough все еще бессмысленно.

Заранее спасибо, если вы только что прочитали весь этот раздел!!

Ответы [ 2 ]

0 голосов
/ 14 ноября 2018

Насколько я могу судить, даже с текущим мастером nginx-ingress невозможно использовать самозаверяющие сертификаты.В шаблоне https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl отсутствуют какие-либо из необходимых директив, таких как: 

location / {
     proxy_pass                    https://backend.server.ip/;
     proxy_ssl_trusted_certificate /etc/nginx/sslcerts/backend.server.pem;
     proxy_ssl_verify              off;

     ... other proxy settings
}

Поэтому попробуйте использовать, например, сертификат зашифрованного кода.

0 голосов
/ 27 сентября 2018

Я предполагаю, что ваши серверные службы используют HTTPS, а промежуточный трафик отправляется через HTTP.Эта строка в вашем values.yaml выглядит странно: 

targetPorts:
  http: 80
  https: http

Можете ли вы попробовать что-то подобное? 

targetPorts:
  http: 80
  https: 443
...