bosh director library should allow insecure HTTP about bosh-cli HOT 8 CLOSED

There was some previous discussion about this in cloudfoundry-attic/bosh-init#102 before the repo was forked. Might be helpful to read up on that for some additional context. We're trying very hard to avoid insecure setups with this new library.

Not familiar with your specific product, but is it truly a requirement to support insecure environments?

from bosh-cli.

I appreciate the desire to avoid insecure setups, and agree that disabling TLS verification should be avoided even in development environments (and of course always in production). Unfortunately a flag to ignore cert verification is already a supported feature of our product, designed for development environments (e.g. bosh-lite provisioned through vagrant).

We would also prefer the URL that we give to the library not to be rewritten, so that if we give an http scheme, it is not changed to https by the library.

from bosh-cli.

To be clear, bosh has always communicated over https with the director (never http). It's just that self-signed certificates were used if the operator didn't provide any, and there was lax trust policies in that case. Also, recent versions of bosh-lite are running with more trustable certificates that bosh-cli supports.

@cppforlife may have some thoughts as well with regards to your product requirements.

from bosh-cli.

@craigfurman im opposed to adding -k like functionality to either library or cli. let's chat more about how to have you all switch to using verifiable certificates.

from bosh-cli.

@cppforlife it isn't about as switching to globally verifiable certs as a development team, ignoring TLS verification (however inadvisable) is already a supported feature of an existing product of ours that interacts with bosh.

Unless we remove this feature we can't use this, unfortunately.

@dpb587-pivotal oops, I forgot about that! It might still be useful for URLs to not be rewritten, as it allows the CLI/library to interact with bosh web mocks that have no reason to serve TLS.

cc @jamesjoshuahill @avade

from bosh-cli.

The original reason for adding support for ignoring SSL errors was for the BOSH lite use case for local development.

Now that BOSH lite uses trustable certs for Vagrant, then we may be able to remove support for this feature in our product.

from bosh-cli.

I'm going to consider this closed then based on Alex's response about bosh-lite.

from bosh-cli.

@cppforlife I'm still against rewriting URLs, if for no other reason than simplifying the use of web-mocking the bosh API (no need to serve TLS from the mock).

from bosh-cli.