Re: Static IP setup for routers on AWS


Amit Kumar Gupta
 

Thanks Dan,

So it sounds like *if* your router has public IPs, then you need to tell
those IPs to the UAA so it knows to trust them and handle the x-forwarded-*
headers from them. Going back to Johannes original question, I think he's
right, in the typical AWS configuration there's no reason to give the
routers static IPs. I'll go ahead and submit a PR for this change.

Cheers,
Amit

On Thu, Apr 14, 2016 at 6:57 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Fri, Apr 8, 2016 at 7:04 AM, Engelke, Johannes <
info(a)johannes-engelke.de> wrote:

Hi Amit,
thanks for your answer. I deployed cloud foundry without using static
IP’s. It is working well.

As far as I understood the uaa config the entire 10.x.x.x network is
allowed to access the UAA Servers anyway, so there is no reason to place
the dedicated static IP's of the routers into the config.
Are you referring to the RemoteIpValve that is configured for UAA?


https://github.com/cloudfoundry/uaa-release/blob/develop/jobs/uaa/templates/tomcat.server.xml.erb#L70-L73

Because the RemoteIpValve doesn't restrict access to Tomcat / UAA. It's
controls how (and if) Tomcat handles the x-forwarded-* headers. In short,
it will only process those headers if it "trusts" them (by trust, it really
means if the regex matches).

My understanding is that the UAA job will take the gorouter IP's and
prepend them to the front of this regex so that it will always match at
least the IP's for the gorouter. If you're using private IP's, it's not
really necessary as the default regex used by Tomcat will match all private
IP's.

If you're using public IP's for some reason, you'd need to configure this
or UAA might not detect the incoming connects as HTTPS and it would very
likely detect the wrong remote IP address (necessary for audit records in
the logs).


Do you see any security improvements, if only routers are allowed to
access the UAA?
As long as we're talking about RemoteIpValve, sorry if I'm not following
the conversation completely I jumped in a little late, and you're using
private IP addresses for your VMs then I don't see any difference in
behavior.

If you have public IP's assigned to your gorouter VMs then you may see
some issues with how the x-forwarded-for and x-forwarded-proto headers are
processed, which in turn could affect the accuracy of the audit messages in
the logs.

Hope that helps!

Dan



On 08 Apr 2016, at 02:19, Amit Gupta <agupta(a)pivotal.io> wrote:

The UAA needs to know the router IPs to know which IPs to accept inbound
requests from. If you don't care about this, you can try configuring UAA
to allow requests from many IPs, and remove the static IPs from gorouter.
I would be interested to find out the result of this experiment should you
try it out.

Best,
Amit

On Thu, Apr 7, 2016 at 6:28 AM, Engelke, Johannes <
info(a)johannes-engelke.de> wrote:

Hi,
does anybody know, why the routers got static ips in the
cf-infrastructure-aws.yml file?
https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-infrastructure-aws.yml#L173

Bosh is assigning the instances to ELB’s during deploy time, so there
should be no need to have static addresses here.

If nobody know’s a good reason should we remove them ;-)

Cheers
Johannes

Join {cf-dev@lists.cloudfoundry.org to automatically receive all group messages.