Force_https non funziona con GCP Ingress

Supporto
1

Ho un’istanza Kubernetes su GCP. Tutto sembra funzionare correttamente, ma in qualche modo force_https non sta forzando il reindirizzamento e il sito è ancora accessibile tramite http://.

La mia soluzione temporanea è stata aggiungere questo blocco a app.yml:

    - replace:
        filename: /etc/nginx/conf.d/discourse.conf
        from: '    add_header ETag "";'
        to: |
                  add_header ETag "";
                  if ($thescheme = "http") {
                    return 301 https://$host$request_uri;
                  }

(Sarei anche felice di capire come far sì che pups indenti correttamente le righe che ho inserito, ma mi sto dilungando.)

Qualche tempo dopo questa modifica, il controller Ingress sembra aver smesso di servire il sito, anche se sembrava funzionare e reindirizzare correttamente per un certo periodo.

Ovviamente si tratta di una unsupported-install, ma se qualcuno ha un’idea su dove guardare ora, ne sarei grato.

2

Stai utilizzando un load balancer HTTP o un load balancer TCP? Se è HTTP, il protocollo rilevato in ingresso potrebbe essere inserito in un’intestazione non standard che Discourse non sta cercando.

3

Sembra che la configurazione completamente gestita sia questa:

$ gcloud compute addresses create discourse-ip-address --global
#                                 ^~~~~~~~~~~~~~~~~~~~ nome personalizzato
# ATTENZIONE: riservare un indirizzo IP senza utilizzarlo comporta una penale di 0,010 USD/ora
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: discourse-cert
spec:
  domains:
    - discourse.example.com  # personalizza
---
apiVersion: extensions/v1beta1
# se v1.14 o successive:
# apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: discourse-web-ingress
  annotations:
    networking.gke.io/managed-certificates: discourse-cert
    kubernetes.io/ingress.global-static-ip-name: discourse-ip-address
spec:
  backend:
    serviceName: discourse-web  # verifica che sia corretto
    servicePort: 80

fonti:

4

Grazie mille, @riking! Sì, sembra che il problema sia il bilanciatore di carico. Penso che ingress sia a posto (e ora ho un’idea della differenza). Ho passato alla configurazione che mostri tu e ottengo gli stessi risultati di una configurazione un po’ più complicata. Immagino che il prossimo passo sia capire tcpdump e vedere cosa c’è in quegli header…

EDIT: Sembra che dovrebbe funzionare. Ecco cosa vedo:

GET /thisisatest HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: community.example.com
X-Cloud-Trace-Context: 72c9f7219e6b541cad01153c52fb92c5/13509441707361831434
Via: 1.1 google
X-Forwarded-For: MY-IP-ADDRESS, INGRESS-IP
X-Forwarded-Proto: http
Connection: Keep-Alive

Ho un set_real_ip_from con l’IP di ingress (e gli indirizzi IP vengono registrati correttamente).

5

@pfaffman Potrei aiutarti con questo - sono su GCP e ho già risolto questo problema in passato. Sono impegnato per qualche ora, ma se puoi inviarmi la configurazione del tuo load balancer (insieme alle impostazioni di health check) qui o in privato, posso provare a individuare il problema.

PS: Sia TCP che HTTP funzionano.

6

Grazie mille, @p16!

Ecco il controllo di stato. Ho modificato il percorso in /srv/status, ma continuo a vedere “GoogleHC/1.0” che colpisce /.

image
image485×576 20.9 KB

7

Grazie, il backend risulta sano nel load balancer? Aggiungi anche www.yoursite.com all’host (sotto “altro”).

Inoltre, ecco cosa aggiungo al mio app.yml:

  after_web_config:
    - replace:
       filename: "/etc/nginx/conf.d/discourse.conf"
       from: /server.+{/
       to: |
         server {
           if ($http_x_forwarded_proto = 'http'){
            return 301 https://$host$request_uri;
           }

Non sarà necessario per molto tempo, poiché Google aggiungerà un reindirizzatore da http a https entro questo trimestre.

8

Sì. Sembra che funzioni ora! Immagino di essere confuso riguardo alla porta magica 30182, ma suppongo che sia una sorta di magia di k8s che capirò un altro giorno.
Proverò il tuo blocco after_web_config:. Sembra un po’ più pulito rispetto a quello che stavo facendo.

Grazie mille.