J'ai configuré un cluster Kubernetes sur GKE. Installation du graphique Helm stable / wordpress. Ajout d'une entrée avec un certificat SSL. Mais maintenant, l'équilibreur de charge Google signale que mon service n'est pas sain. Cela est dû au pod Wordpress qui renvoie un 301 lors de la vérification de l'état car il souhaite appliquer HTTPS, ce qui est bien. Mais l'équilibreur de charge Google refuse d'envoyer un en-tête x-forwarded-proto: https. Le pod pense donc que la vérification de l'état a été effectuée via http. Comment puis-je contourner ce problème?
J'ai essayé d'ajouter un .htaccess qui renvoie toujours 200 pour l'agent utilisateur GoogleHC mais ce n'est pas possible avec le graphique de barre qui remplace le .htaccess après le démarrage.
Voir également: https://github.com/kubernetes/ingress-gce/ issues / 937 et https://github.com/helm/charts/issues/ 18779
3 Réponses :
FAÇON: 1
Si vous utilisez le cluster Kubernetes sur GKE, vous pouvez utiliser l'entrée indirectement, cela créera le Loadbalancer indirectement.
Vous pouvez ajouter un magasin de certificats SSL il à l'intérieur du secret et s'applique à l'entrée. Pour SSL, vous pouvez également choisir une autre approche pour installer cert-manager sur GKE.
Si vous souhaitez configurer nginx-ingress avec cert-manager, vous pouvez également suivre ce guide:
CHEMIN: 2
Modifiez le graphique de barre localement, ajoutez la sonde viveness et readinesss au déploiement et il vérifiera la vérification de l'état de WordPress via http uniquement.
Mise à jour :
Pour ajouter x-forwarded-proto en entrée, vous pouvez utiliser cette annotation
nginx.ingress.kubernetes.io/server-snippet: |
location /service {
proxy_set_header X-Forwarded-Proto https;
}
Vous n'avez pas compris mon problème. J'ai créé une entrée qui instancie indirectement l'équilibreur de charge. Il a un certificat SSL qui est obtenu avec cert-manager (aucun problème là-bas). Mais comme SSL est terminé par l'équilibreur de charge, je souhaite que le LB inclue l'en-tête x-forwarded-proto afin que le backend sache que la demande d'origine était via https et qu'il ne redirigera pas vers https. Mais le LB ne le fait pas pour les bilans de santé, il obtiendra donc un 301 au lieu de 200
en entrée, vous pouvez utiliser l'annotation d'extrait de serveur pour ajouter la mise à jour de la réponse `x-forwarded-proto`.
ok, je pense que c'est plus une solution de contournement qu'une solution. Mais cela fonctionnerait probablement. Juste un peu stupide que je ne puisse pas résoudre ce problème dans une configuration professionnelle avec GKE.
Lorsque l'équilibreur de charge HTTPS met fin à la session SSL / TLS client au niveau de la LB, vous devez configurer HTTPS entre l'équilibreur de charge et votre application (wordpress). Les vérifications d'état utilisent HTTP par défaut, pour utiliser les vérifications d'état HTTPS avec vos services backend, les services backend seraient également nécessitent leur propre certificat SSL / TLS (voir # 4 de l'équilibrage de charge HTTP dont l'équilibrage de charge HTTPS hérite). Pour simplifier la configuration des certificats backend, vous pouvez utiliser certificats auto-signés , qui n'interfèrent pas avec le chiffrement de l'équilibreur de charge <-> client, car la session client se termine au LB.
Vous pouvez bien sûr utiliser des vérifications de l'état HTTP (moins de configuration!) pour votre (vos) backend (s), cela ne causera aucun problème de chiffrement du trafic client, car cela n'affecte que la vérification de l'état et non les données envoyées à votre application.
Ce n'est pas non plus une solution. Je ne veux pas configurer HTTPS dans le backend, cela va à l'encontre de l'objectif de le terminer au LB.
Le problème ici est que Wordpress force la redirection HTTPS (la 301), auquel cas, vos options sont soit de configurer GCP derrière le LB pour «jouer avec» (activer HTTPS à partir de LB -> serveur Wordpress avec un serveur interne auto-signé certificat), ou pour configurer Wordpress pour répondre aux requêtes HTTP sans redirection HTTPS. Pour empêcher Wordpress d’effectuer la redirection HTTPS, cela peut être utile (réponse de Kyle Vassella). stackoverflow.com/questions/32855861/… < / a>
Pourquoi avez-vous besoin de https entre Load Balancer et Wordpress en premier lieu? Ne serait-il pas suffisant d'avoir https sur le frontend de Load Balancer (entre LB et le monde extérieur)?
La résiliation SSL a-t-elle été effectuée deux fois?
Voici ce que j'ai fait lors de la migration de mon site Wordpress vers GKE:
https / ssl / tls . Heureusement pour moi, cela n'a même pas nécessité de changements dans la base de données. apiVersion: networking.gke.io/v1beta2
kind: ManagedCertificate
metadata:
name: my-certificate
namespace: prod
spec:
domains:
#Wildcard domains are not supported(https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs).
- example.com
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: prod-ingress
namespace: prod
annotations:
kubernetes.io/ingress.allow-http: "false"
kubernetes.io/ingress.global-static-ip-name: load-balancer-ip
networking.gke.io/managed-certificates: my-certificate
Je me rends compte que vous avez un casque dessus, mais il y a toujours un moyen de le modifier / ou configs / params.
Désolé mais vous n'avez pas non plus compris la question. Wordpress fait en sorte que la connexion s'effectue via HTTPS. Mais si l'équilibreur de charge ne dit pas au backend que la connexion entrante était via https (en envoyant l'en-tête x-forwarded-proto comme le ferait tout autre système), il n'y a absolument aucun moyen pour le backend de savoir que la connexion était terminée. https et il redirigera l'utilisateur vers l'url https (qu'il a utilisé de toute façon). Mais je pense qu'il existe actuellement un moyen de le faire avec GKE LB.
Wordpress ne force pas HTTPS. Ce sont les plugins que vous utilisez à l'intérieur qui font cela. Et si cela dépend de vous, vous pouvez les supprimer.
Non, je ne peux pas car c'est le graphique Helm par défaut qui applique cela.
J'ai compris alors. Eh bien, vous pouvez toujours créer votre propre graphique basé sur celui-ci. Les gens le font plus souvent que vous ne le pensez. Plus les graphiques encapsulent, moins ils deviennent flexibles. Dans tous les cas, ce n'est pas une bonne raison d'avoir un élément de réseau redondant ou une terminaison TLS supplémentaire à cause d'un graphique qui ne peut pas s'en passer.