Постоянное перенаправление HTTPS 308 на вход k8s в nginx

Question

Постоянное перенаправление HTTPS 308 на вход k8s в nginx

Я создал кластер EKS, следуя примерам из AWS EKS, я развернул входной контроллер nginx поверх kubernetes/nginx, создал входной ресурс, который указывает на серверные службы k8s. Однако, когда я пытаюсь выполнить запрос черезcurl -kv https://dev01.cricket.com/demo/helloон возвращает постоянное перенаправление 308

Вот мой сервис-nlb.yaml

          --- (service-nlb.yaml)
kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: default
  annotations:
    **service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http**
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600"
    service.beta.kubernetes.io/aws-load-balancer-internal: "0.0.0.0/0"
    **service.beta.kubernetes.io/aws-load-balancer-ssl-cert:  "arn:aws:acm:us-west-2:xxxxx:certificate/x-037xxxd-4a1e-x-x"**
    service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: ELBSecurityPolicy-TLS-1-2-Ext-2018-06
    **service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https**
spec:
  ports:
    - name: https
      port: 443
      targetPort: 80

вход.yaml

      ```apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  labels:
    app: jg
    env: dev
  name: jg-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
    **ingress.kubernetes.io/ssl-redirect: "false"**
spec:
  rules:
    - host: dev01.cricket.com
      http:
        paths:
          - backend:
              serviceName: jg-service
              servicePort: 8080
            path: /demo
    - host: dev02.cricket.com
      http:
        paths:
          - backend:
              serviceName: sad-service
              servicePort: 8080
            path: /sad
  tls:
   - hosts:
        - dev01.cricket.com
     secretName: my-tls-secret```

когда я делаюcurl -kv dev01.cricket.comон возвращает 308 постоянный редирект

      curl -kv https://dev01.cricket.com/demo/hello
*   Trying 10.41.168.92...
* TCP_NODELAY set
* Connected to dev01.cricket.com (10.41.168.92) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* 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, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=dev01.cricket.com; OU=management:idms.group.140787; O=Cricket Inc.; ST=California; C=US
*  start date: Apr 19 08:37:06 2021 GMT
*  expire date: May 19 08:37:05 2023 GMT
*  issuer: CN=Cricket Corporate Server CA 1; OU=Certification Authority; O=Cricket Inc.; C=US
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ff9eb80d200)
> GET /demo/hello HTTP/2
> Host: dev01.cricket.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 308
< server: Cricket
< date: Tue, 04 May 2021 16:38:38 GMT
< content-type: text/html
< content-length: 171
< location: https://dev01.cricket.com/demo/hello
< strict-transport-security: max-age=31536000; includeSubdomains
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
<
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>
* Connection #0 to host dev01.cricket.com left intact
* Closing connection 0

Я не уверен, почему не происходит завершение TLS и происходит постоянная ошибка перенаправления, если я делаю тот же завиток по http, он возвращает 301

      curl -kv http://dev01.cricket.com/demo/hello
*   Trying 10.41.162.164...
* TCP_NODELAY set
* Connected to dev01.cricket.com (10.41.162.164) port 80 (#0)
> GET /demo/hello HTTP/1.1
> Host: dev01.cricket.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: Cricket
< Date: Tue, 04 May 2021 19:17:26 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: https://dev01.cricket.com/demo/hello
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>Cricket</center>
</body>
</html>
* Connection #0 to host dev01.cricket.com left intact
* Closing connection 0

бэкэнд-service.yaml

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: jgdeployment
  labels:
    app: jg
spec:
  replicas: 3
  selector:
    matchLabels:
      app: jg
  template:
    metadata:
      labels:
        app: jg
    spec:
      containers:
      - name: jg
        image: docker.cricket.com/jga:1.0.0
        ports:
        - containerPort: 8080
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /demo/hello
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /demo/hello
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: jg-service
  namespace: "default"
spec:
  type: ClusterIP
  ports:
    - port: 8080
      targetPort: 8080
  selector:
    app: jg

Не уверен, что мне не хватает, чтобы получить ошибку 308 на https.

2

kubernetes nlb nginx-ingress

Источник

Cricket 04 май '21 в 19:23

4 ответа

Другие вопросы по тегам kubernetes nlb nginx-ingress

Piotr Malec 04 апр '22 в 17:29 2022-04-04 17:29 · Answer 1 · 2022-04-04 17:29

Это ответ пользователя Ariseaz из проблемы GitHub , упомянутой в ответе Азиза Адениджи.

Использование диаграммы helm ingress-nginx в EKS.
Редактирование карты конфигурации ingress-nginx-controller.
kubectl edit configmap ingress-nginx-controller -n ingress-nginx
Добавлять
data: server-snippet: | listen 8000; if ( $server_port = 80 ) { return 308 https://$host$request_uri; } ssl-redirect: "false"

Отредактируйте сервис/ingress-nginx-controller, добавив
meta.helm.sh/release-namespace: ingress-nginx service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: <acm arn> service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https service.beta.kubernetes.io/aws-load-balancer-type: nlb

Настройте свой порт во входном контроллере так, чтобы он выглядел так, как показано ниже:
NB: специальный порт — это то, что вы собираетесь добавить к входным
портам контейнерного порта:

имя: http
порт: 80
протокол: TCP
targetPort: 80
имя: https
порт: 443
протокол: TCP
targetPort: специальный

Теперь отредактируйте контейнер развертывания входящего контроллера.
kubectl edit deployment.apps/ingress-nginx-controller -n ingress-nginx
Добавлять:

ContainerPort: 8000
имя: специальный
протокол: TCP

Matthew L Daniel 05 май '21 в 04:09 2021-05-05 04:09 · Answer 2 · 2021-05-05 04:09

Я не уверен, почему не происходит завершение TLS и происходит постоянная ошибка перенаправления.

Учитывая вашу спецификацию обслуживания:

      spec:
  ports:
    - name: https
      port: 443
      targetPort: 80

вызывает следующее:

      User -- [Internet] -HTTPS-> :443 [NLB] -HTTPS-> :443 [iptables] -HTTP-> :80 [nginx]

Таким образом, поскольку nginx не осознает, что перед ним есть TLS, а внутри кластера трафик HTTP, nginx считает, что это полезно, перенаправляя запрос на свой сервер.443порт и таким образом защищает запрос

Я не выполнял завершение TLS с помощью NLB , но теоретически идея та же: вы хотите использовать TLS от NLB к (предположительно самозаверяющему) сертификату на порту 443 nginx, потому что - при прочих равных условиях -- AWS LB не будет проверять действительность сертификата nginx. Таким образом, хотя у вас действительно есть MITM, не будет никакой связи по протоколу открытого текста между браузером пользователя и nginx, что делает его счастливым, а не 308.

Я вижу аннотацию, которую вы выделили на своем Ingress, но я сильно подозреваю, что механизм, с которым вы сталкиваетесь, происходит до того, как он доберется до конкретного ресурса Ingress, возможно, из-за настройки ConfigMap или чего-то еще. Возможно, можно настроить nginx так, как вы думали, но я считаю, что «сквозной псевдо-TLS» настолько просто исправить, что вам не придется искать обходные пути.

Azeez Adeniji 05 мар '22 в 22:41 2022-03-05 22:41 · Answer 3 · 2022-03-05 22:41

Прочтите мой комментарий к этой теме:https://github.com/kubernetes/ingress-nginx/issues/2724 .

Комментарий от Ariseaz

0

Источник

Azeez Adeniji 05 мар '22 в 22:41

Jananath Banuka 24 июн '23 в 21:15 2023-06-24 21:15 · Answer 4 · 2023-06-24 21:15

Вы можете добавить следующее вannotationsресурса Ingress;

      annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"

0

Источник

Jananath Banuka 24 июн '23 в 21:15