I've manually put in place a ferm rule and disabled puppet now on tools-proxy-01, since we've disabled security groups (kinda) due to https://phabricator.wikimedia.org/T142165 just now.

When I filed this task, I was confused about the way OpenStack handles incoming connections. By default, no connections at all are let through. It is only by virtue of the "default" security group (in Toolforge and other Labs projects) that intra-project communication is allowed, as this security group allows all traffic from other instances in the (same) "default" security group. This "default" security group covers all ports, including port 8282 for proxylistener. Instances in other projects cannot reach port 8282 (proved by tests).

What I am unsure about ATM is how Kubernetes interacts with this. I tried:

tools.templatecheck@interactive:~$ php
<?php
echo(file_get_contents("http://tools-proxy-01.tools.eqiad.wmflabs/list"));
PHP Warning:  file_get_contents(http://tools-proxy-01.tools.eqiad.wmflabs/list): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
 in - on line 2
tools.templatecheck@interactive:~$ php
<?php
echo(file_get_contents("http://tools.wmflabs.org"));
PHP Warning:  file_get_contents(http://tools.wmflabs.org): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
 in - on line 2
tools.templatecheck@interactive:~$

to see if I can see an access request on tools-proxy-01, but probably PHP's use-URLs-as-filenames is disabled? So I need try to this again to see if these requests go through OpenStack's firewall.

If Kubernetes offers no attack vector, then this task could be un-securitied and then closed as invalid. Additionally, we might think about amending the security groups so that instances in the webproxy security group only allow access to port 8282 from instances in the, hmmm, execnode security group?

I don't know why I did not try a simple curl :-). When I webservice php5.6 shell and then curl http://tools-proxy-01/does-not-exist, this hits the proxy as:

10.68.23.240 - - [31/Jan/2017:21:56:27 +0000] "GET /does-not-exist HTTP/1.1" 404 1409 "-" "curl/7.38.0"

10.68.23.240 is the IP of tools-worker-1003.tools.eqiad.wmflabs, i. e. proxylistener would contact the trustworthy ident server on tools-worker-1003 and not one on the user-controlled containers. Therefore I think Kubernetes does not offer any attack vector.

So this task can be un-securitied and then closed as invalid. Thanks and sorry for the confusion!