Add elb for bosh director

[madamkiwi]

This allows us to create an elb for the bosh director. Please review and let me know if you have any suggestions or questions. Would be happy to work together to modify the code.

[aegershman]

A solid usecase for giving the bosh director an eip / a hostname could be for setting up SAML for SSO auth to the director.

But still, from what I understand setting ingress/egress to 0.0.0.0/0 would expose the director to the public internet?

[ciphercules]

@madamkiwi - lots of PRs (so amazing ❤️)

Can we ask, why do you need a direct line to the director?

Normally you can get access to the director by doing an om bosh-env with the ops-manager private key. This is seemed good enough for automation needs on infrastructure. Is there some other need you have to directly target the director via an ELB?

🌶

[evanfarrar]

Is this for HA perhaps? Could it be an internal LB? externally exposing the director API has been not supported by bosh in the past, it would be nice to know if that is an opinion we are changing

[haydonryan]

It may be if they wanted to use valid certs for an internal LB. Amazon will give you a free cert for ELBs, but you don't have access to the private key, so you can't apply it to VM configuration. That and using an FQDN is more flexible than IP address.

[voor]

At the very least, this should be toggleable, since this would expose the Bosh Director to the internet, which is not preferred in most scenarios. You would achieve that by adding a count = ${var.public_bosh ? 1 : 0} or similar, see use_route53 as an example, we can then have a default of false and hide this from customers.

You might also want to consider a NLB, and I only greedily propose that since I'd like to see a unique security group on the bosh director. 🍰 🍴

[aegershman]

I still think giving the director a DNS entry / LB is a good idea & should be encouraged by default. It makes it easier to setup SSO for the director + colocated UAA/credhub if so desired.

I've also heard of teams using DNS for the director so in the event of an absolute disaster where an AZ fails where the director is in, it makes it more feasible to stand up the director in a new AZ, restore the director's DB & update the DNS to point to the new director.

regardless, remembering/looking up/leveraging IPs kind of sucks. It feels like a DNS value + internal LB for the director should be encouraged & the default and have raw IPs be the exception? maybe i'm totally missing something though. hope pivotal architecture engineers look into it