«ERR_TOO_MANY_REDIRECTS» Контроллер nginx-ingress не перезаписывает X-Forwarded-Proto: http, X-Forwarded-Scheme: http

Мы используем IAP, GCP L7 Loadbalancer с контроллером nginx-ingress (версия 0.49.3). Мы развернули собственный GitLab и получили «ERR_TOO_MANY_REDIRECTS».

После нескольких напряженных дней устранения неполадок мы заметили, что

POST /api/v4/jobs/request HTTP/1.1
Host: gitlab.ci.g.nakhoda.ai
X-Request-ID: dfa874d97ed06e0e7a7cf17c0a4ae2c0
X-Real-IP: 35.191.12.183
X-Forwarded-For: 35.191.12.183
X-Forwarded-Host: gitlab.ci.g.nakhoda.ai
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Scheme: http
X-Scheme: http
X-Original-Forwarded-For: 62.189.73.245, 35.186.225.221
Content-Length: 714
User-Agent: gitlab-runner 15.6.1 (15-6-stable; go1.18.8; linux/amd64)
Accept: application/json
Content-Type: application/json
Accept-Encoding: gzip
X-Cloud-Trace-Context: 4efdd65224a5882999fd0fb26a888bfd/2273898499790060164
Via: 1.1 google

X-Forwarded-Proto: http и X-Forwarded-Scheme: http в наших первоначальных переадресациях установлено значение http. Немного повозившись с этим, мы выполнили в контейнере nginx-ingress-controller и отредактировали nginx.conf, чтобы у обоих был https, а также добавили аннотацию ssl-redirect: false.

После этого запрос выглядит так:

POST /api/v4/jobs/request HTTP/1.1
Host: gitlab.ci.g.nakhoda.ai
X-Request-ID: f103bba96d47527dae15087d1dd1d476
X-Real-IP: 35.191.12.180
X-Forwarded-For: 35.191.12.180
X-Forwarded-Host: gitlab.ci.g.nakhoda.ai
X-Forwarded-Port: 80
X-Forwarded-Proto: https
X-Forwarded-Scheme: https
X-Scheme: http
X-Original-Forwarded-For: 194.203.216.4, 35.186.225.221
Content-Length: 714
User-Agent: gitlab-runner 15.6.1 (15-6-stable; go1.18.8; linux/amd64)
Accept: application/json
Content-Type: application/json
Accept-Encoding: gzip
X-Cloud-Trace-Context: 3ceb1d9d95fa28be4da929dea1f3ac95/3016269448751760533
Via: 1.1 google

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

Проблема в том, что мы искали добавление пользовательских заголовков для перезаписи [nginx.conf](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-headers/ не перезаписывает обычный nginx .conf), но после добавления ConfigMap с конкретными вещами или просто добавления подобных аннотаций, подобных этой, в Ingress контроллера nginx-ingress или в ConfigMap:

Вход в Gitlab

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gitlab-chart-webservice-default
  namespace: gitlab
  labels:
    app: webservice
    app.kubernetes.io/managed-by: Helm
    chart: webservice-6.6.2
    gitlab.com/webservice-name: default
    heritage: Helm
    release: gitlab-chart
  annotations:
    kubernetes.io/ingress.provider: nginx
    meta.helm.sh/release-name: gitlab-chart
    meta.helm.sh/release-namespace: gitlab
    nginx.ingress.kubernetes.io/proxy-body-size: 512m
    nginx.ingress.kubernetes.io/proxy-connect-timeout: '15'
    nginx.ingress.kubernetes.io/proxy-read-timeout: '600'
    nginx.ingress.kubernetes.io/service-upstream: 'true'
    nginx.ingress.kubernetes.io/ssl-redirect: 'false'
status:
  loadBalancer:
    ingress:
      - ip: 1.1.1.1
      - ip: 1.1.1.1
spec:
  ingressClassName: stable-protected
  tls:
    - hosts:
        - gitlab.ci.example.com
      secretName: gitlab-cert
  rules:
    - host: gitlab.ci.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: gitlab-chart-webservice-default
                port:
                  number: 8181

ConfigMap для контроллера nginx

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx
  namespace: ingress-stable-protected
  annotations:
    refresh-me: |
      This 'refresh-me' annotation is purely used as a placeholder so we can
      modify its value in order to manually force the nginx ingress-controller
      to reload its configuration.
      Reload.
data:
  enable-vts-status: 'true'
  hide-headers: Strict-Transport-Security
  hsts: 'true'
  hsts-include-subdomains: 'false'
  hsts-preload: 'false'
  proxy-body-size: 2048m
  proxy-buffer-size: 16k
  proxy-connect-timeout: '5'
  proxy-next-upstream: 'off'
  proxy-read-timeout: '600'
  proxy-send-timeout: '600'
  server-name-hash-bucket-size: '256'
  server-tokens: 'false'
nginx.ingress.kubernetes.io/x-forwarded-proto=https
nginx.ingress.kubernetes.io/x-forwarded-scheme=https

Он по-прежнему требует nginx.conf http, поэтому мы застряли с этим временным исправлением.

Пытался добавить кучу пользовательских заголовков и x-forwarded-headers, но безрезультатно.

Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
0
0
114
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Проблема заключалась в том, что после версии 0.24.0 nginx-ingress произошло изменение аннотации, поэтому, добавив следующее в карту конфигурации nginx, ошибка больше не возникает.

Более подробное описание можно найти в этом билете

use-forwarded-headers: "true"
use-proxy-protcol: "false"

Полный пример:

apiVersion: v1
data:
  enable-vts-status: "true"
  hide-headers: Strict-Transport-Security
  hsts-preload: "false"
  proxy-body-size: 2048m
  proxy-buffer-size: 16k
  proxy-connect-timeout: "5"
  proxy-next-upstream: "off"
  proxy-read-timeout: "600"
  proxy-send-timeout: "600"
  server-name-hash-bucket-size: "256"
  server-tokens: "false"
  use-forwarded-headers: "true"
  use-proxy-protcol: "false"
kind: ConfigMap
metadata:
  annotations:
    refresh-me: |
      This 'refresh-me' annotation is purely used as a placeholder so we can
      modify its value in order to manually force the nginx ingress-controller
      to reload its configuration.
  labels:
    app.kubernetes.io/managed-by: pulumi
  name: nginx
  namespace: namespace

Другие вопросы по теме