{"id":6619,"date":"2020-03-11T17:16:29","date_gmt":"2020-03-11T15:16:29","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=6619"},"modified":"2020-03-11T17:17:13","modified_gmt":"2020-03-11T15:17:13","slug":"doppelter-hostname-in-header-bei-kubernetes-ingress-backend-connections-component-pack-bad-request","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/doppelter-hostname-in-header-bei-kubernetes-ingress-backend-connections-component-pack-bad-request\/","title":{"rendered":"Doppelter Hostname in Header bei Kubernetes Ingress Backend &#8211; Connections Component Pack: Bad Request"},"content":{"rendered":"<p>F\u00fcr eine Connections 6.5 Testinstallation wurde der IBM HTTP Server hinter einem Standard Kubernetes Ingress betrieben. Bis zur Installation des Component Pack funktionierte dies: Auf der OrientMe-Seite waren keine Inhalte zu sehen, sondern die o.g. Fehlermeldung. Mehrere Ajax-Anfragen endeten mit einem 500er internen Serverfehler. In der Fehlerlog vom IHS sind folgende Eintr\u00e4ge zu sehen:<\/p>\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"\" data-line=\"\">[Fri Mar 06 09:30:27 2020] [debug] vhost.c(791): [client 1.2.3.4:54252] [strict] Invalid host name &#039;cnx65.k8s.internal cnx65.k8s.internal&#039;, problem near: , cnx6\n[Fri Mar 06 09:30:27 2020] [debug] vhost.c(886): [client 1.2.3.4:54252] Client sent malformed Host header: cnx65.k8s.internal cnx65.k8s.internal\n[Fri Mar 06 09:30:27 2020] [debug] protocol.c(1412): [client 1.2.3.4:54252] client sent HTTP\/1.1 request without hostname (see RFC2616 section 14.23): \/search\/atom\/mysearch<\/code><\/pre>\n<p>Das Problem wurde durch eine Verkettung verschiedener Umst\u00e4nde verursacht: Anfragen des Component-Pack erhalten einen <strong>X-Forwarded-Host<\/strong> Header. Er ist daf\u00fcr gedacht, um den anfragenden Host hinter einem Reverse Proxy zu \u00fcbermitteln. In der aktuellen Version 6.5.0.0 des Component Pack ist dieser fehlerhaft und enth\u00e4lt den Connections Hostname doppelt mit Komma getrennt &#8211; beispielsweise<\/p>\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"\" data-line=\"\">x-forwarded-host: cnx65.k8s.internal, cnx65.k8s.internal<\/code><\/pre>\n<p>Dies ist zwar fehlerhaft, aber nicht zwingend ein Problem. Das wird es erst durch das <a href=\"https:\/\/github.com\/kubernetes\/ingress-nginx\/issues\/2463\" target=\"_blank\" rel=\"nofollow\">Standardverhalten vom Kubernetes Ingress<\/a>: Dieser setzt den <strong>X-Forwarded-Host<\/strong> Header automatisch als Host-Header. Der <strong>Host<\/strong> Header ist jedoch nicht optional sondern essenziell, da er z.B. zur Zuordnung von virtuellen Hosts genutzt wird. Durch dieses Verhalten erh\u00e4lt der IHS hinter dem Ingress folgende Anfrage:<\/p>\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"\" data-line=\"\">GET \/xyz\nHost: cnx65.k8s.internal, cnx65.k8s.internal\n...<\/code><\/pre>\n<p>Somit entsteht die obige Fehlermeldung \u00fcber den ung\u00fcltigen Host-Header. Der IHS bricht die Abfrage darauf hin mit einem 500 Fehlercode ab.<\/p>\n<h2 class=\"wp-block-heading\">L\u00f6sung: Host auf den Eintrag im Host-Header setzen<\/h2>\n<p>Die L\u00f6sung ist im Grunde recht simpel: Der Ingress-Reverseproxy vor dem IHS muss angepasst werden, sodass er den Hostname in den Host-Header schreibt &#8211; anstelle des <strong>X-Forwarded-Host<\/strong> Headers. Hierzu ediert man den entsprechenden Ingress &#8211; hier <strong>external-service<\/strong>:<\/p>\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"language-bash\" data-line=\"\">kubectl edit ing external-service<\/code><\/pre>\n<p>Unterhalb von <strong>metadata.annotations<\/strong> muss folgendes Snippet eingef\u00fcgt werden:<\/p>\n<pre class=\"wp-block-prismatic-blocks\"><code class=\"language-yaml\" data-line=\"\">metadata:\n  annotations:\n    nginx.ingress.kubernetes.io\/configuration-snippet: |\n      more_clear_input_headers &quot;Host&quot; &quot;X-Forwarded-Host&quot;;\n      proxy_set_header Host $http_host;\n      proxy_set_header X-Forwarded-Host $http_x_forwarded_host;<\/code><\/pre>\n<p>Damit wird sichergestellt, dass der <strong>Host<\/strong>-Header auf den tats\u00e4chlichen Host gesetzt ist. Ferner \u00fcbermitteln wir den <strong>X-Forwarded-Host<\/strong> Header in seiner urspr\u00fcnglichen Form. Letzteres ist nicht zwingend notwendig, aber schadet auch nicht. M\u00f6glicherweise wird der Header zuk\u00fcnftig verwendet.<\/p>\n<p>Nach dem Speichern (in <strong>vim<\/strong> mit <strong>[ESC]<\/strong> den Ediermodus verlassen, dann <strong>:wq<\/strong>) die Seite neu laden &#8211; und OrientMe zeigt Inhalte statt Fehler:<\/p>\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"594\" src=\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2020\/03\/Bildschirmfoto_2020-03-11_16-12-09-1024x594.png\" alt=\"\" class=\"wp-image-6624\" srcset=\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2020\/03\/Bildschirmfoto_2020-03-11_16-12-09-1024x594.png 1024w, https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2020\/03\/Bildschirmfoto_2020-03-11_16-12-09-300x174.png 300w, https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2020\/03\/Bildschirmfoto_2020-03-11_16-12-09-768x445.png 768w, https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2020\/03\/Bildschirmfoto_2020-03-11_16-12-09-70x41.png 70w, https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2020\/03\/Bildschirmfoto_2020-03-11_16-12-09.png 1283w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>F\u00fcr eine Connections 6.5 Testinstallation wurde der IBM HTTP Server hinter einem Standard Kubernetes Ingress betrieben. Bis zur Installation des Component Pack funktionierte dies: Auf der OrientMe-Seite waren keine Inhalte zu sehen, sondern die o.g. Fehlermeldung. Mehrere Ajax-Anfragen endeten mit einem 500er internen Serverfehler. In der Fehlerlog vom IHS sind folgende Eintr\u00e4ge zu sehen: Das &#8230;<\/p>\n","protected":false},"author":5,"featured_media":6620,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[765,5],"tags":[792,760,793,794,719],"class_list":["post-6619","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hcl-connections","category-news","tag-hcl-component-pack","tag-hcl-connections","tag-ingress","tag-k8s","tag-kubernetes"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6619","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=6619"}],"version-history":[{"count":6,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6619\/revisions"}],"predecessor-version":[{"id":6627,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/6619\/revisions\/6627"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/6620"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=6619"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=6619"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=6619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}