Warum reagiert Jenkins auf dem Docker-Host auf HTTP-Anforderungen von internen Containern?

Question

Ich habe ein ziemlich eigenartiges Verhalten auf einer Maschine, auf der Jenkins und Docker installiert sind. Aus Gründen der Übersichtlichkeit wird Jenkins nicht als Docker-Container ausgeführt, sondern unter dem Benutzer jenkins ausgeführt.

Wenn curl in einem Container ausgeführt wird, erhalte ich eine 403:

root@ada71c8116bf:/# curl -I www.google.co.uk 
HTTP/1.1 403 Forbidden 
Date: Tue, 30 May 2017 13:41:07 GMT 
X-Content-Type-Options: nosniff 
Set-Cookie: JSESSIONID.f1223778=36hjq9sozhveoe1bfsss1dnq;Path=/;HttpOnly 
Expires: Thu, 01 Jan 1970 00:00:00 GMT 
Content-Type: text/html;charset=UTF-8 
X-Hudson: 1.395 
X-Jenkins: 2.46.3 
X-Jenkins-Session: 2836b130 
X-You-Are-Authenticated-As: anonymous 
X-You-Are-In-Group-Disabled: JENKINS-39402: use -Dhudson.security.AccessDeniedException2.REPORT_GROUP_HEADERS=true or use /whoAmI to diagnose 
X-Required-Permission: hudson.model.Hudson.Read 
X-Permission-Implied-By: hudson.security.Permission.GenericRead 
X-Permission-Implied-By: hudson.model.Hudson.Administer 
Content-Length: 793 
Server: Jetty(9.2.z-SNAPSHOT) 

außerhalb des Behälters auf dem Host, erhalte ich die erwartete Antwort:

$ curl -I www.google.co.uk 
HTTP/1.1 200 OK 
Date: Tue, 30 May 2017 13:40:17 GMT 
Expires: -1 
Cache-Control: private, max-age=0 
Content-Type: text/html; charset=ISO-8859-1 
P3P: CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info." 
Server: gws 
X-XSS-Protection: 1; mode=block 
X-Frame-Options: SAMEORIGIN 
Set-Cookie: NID=104=mMKjBy002X3N_SkhkD_8xuAwpFuw03CFi0iOJjNX81FUHfMT6qTq95LcgRwdhrV_GZoUF9LQ1B9qAQPriN9Er3Bu2JWoqPgvt16TduuVj5QsNs9GiJTQBtaSXWic7G9E; expires=Wed, 29-Nov-2017 13:40:17 GMT; path=/; domain=.google.co.uk; HttpOnly 
Transfer-Encoding: chunked 
Accept-Ranges: none 
Vary: Accept-Encoding 

Jenkins ist offensichtlich, aber ich schuld Ich habe keine Ahnung, warum es HTTP-Verkehr abfangen würde, Container zu verlassen. Pinging Google funktioniert einwandfrei, ebenso wie das Senden von HTTPS-Anfragen. Keine andere Maschine besitzt dieses Problem (vermutlich, weil Jenkins nicht installiert ist). Also, was ist hier los? Wie bekomme ich Jenkins, um das Abfangen von HTTP von Docker-Containern zu stoppen?

aktualisieren

Ausschalten Jenkins' "Prevent Cross Site Request Forgery-Exploits" Option bewirkt, dass Jenkins nicht mehr zu 403s zurück. Stattdessen reagiert Jenkins auf jede HTTP-Anfrage innerhalb eines Containers mit der Dashboard-Seite, d. H. Der Standardseite.

Auch erwähnenswert ist, dass DNS gut funktioniert; Hostnamen werden in die richtigen IP-Adressen aufgelöst.

Ich werde Wireshark raus.

Answer 1

Durch die Verwendung von Wireshark fand ich, dass etwas HTTP-Verkehr zu Port 8090 auf dem Host umleitete. Ein glücklicher google führte mich dazu, die IP-Tabellen des Hosts zu überprüfen (iptables -t nat -L -n) und sicher genug gab es Regeln, die alle Port 80 Verkehr von überall an Port 8090 des Hosts umgeleitet. Jemand hatte diese Umleitung eindeutig zugunsten von Jenkins-Benutzern eingerichtet.

Die Lösung bestand darin, die IP-Tabellen so zu ändern, dass der Datenverkehr vom Andock-Subnetz nicht umgeleitet wurde.

Die Tabellen vor:

$ sudo iptables -t nat -L -n 
Chain PREROUTING (policy ACCEPT) 
target  prot opt source    destination    
REDIRECT tcp -- 0.0.0.0/0   0.0.0.0/0   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   0.0.0.0/0   ADDRTYPE match dst-type LOCAL 

Chain INPUT (policy ACCEPT) 
target  prot opt source    destination   

Chain OUTPUT (policy ACCEPT) 
target  prot opt source    destination   
REDIRECT tcp -- 0.0.0.0/0   127.0.0.1   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   !127.0.0.0/8   ADDRTYPE match dst-type LOCAL 

Chain POSTROUTING (policy ACCEPT) 
target  prot opt source    destination   
MASQUERADE all -- 172.17.0.0/16  0.0.0.0/0   

Chain DOCKER (2 references) 
target  prot opt source    destination   
RETURN  all -- 0.0.0.0/0   0.0.0.0/0 

Befehle zu ändern:

$ sudo iptables -t nat -R PREROUTING 1 ! -s 172.17.0.0/16 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8090 
$ sudo iptables -t nat -R OUTPUT 1 ! -s 172.17.0.0/16 -d 127.0.0.1/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8090 

Resultierende IP Tabellen:

$ sudo iptables -t nat -L -n 
Chain PREROUTING (policy ACCEPT) 
target  prot opt source    destination   
REDIRECT tcp -- !172.17.0.0/16  0.0.0.0/0   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   0.0.0.0/0   ADDRTYPE match dst-type LOCAL 

Chain INPUT (policy ACCEPT) 
target  prot opt source    destination   

Chain OUTPUT (policy ACCEPT) 
target  prot opt source    destination   
REDIRECT tcp -- !172.17.0.0/16  127.0.0.1   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   !127.0.0.0/8   ADDRTYPE match dst-type LOCAL 

Chain POSTROUTING (policy ACCEPT) 
target  prot opt source    destination   
MASQUERADE all -- 172.17.0.0/16  0.0.0.0/0   

Chain DOCKER (2 references) 
target  prot opt source    destination   
RETURN  all -- 0.0.0.0/0   0.0.0.0/0