search

vmware-archive / pcf-prometheus-pipeline

Apache License 2.0
20 stars 38 forks source link

Unable to reach OpsMan BOSH director #14

Open henryaj opened 6 years ago

henryaj commented 6 years ago

We attempted to add an external IP to our OpsMan BOSH Director (which by default has only a private IP) so that our Concourse workers could reach it. Unfortunately, the Director's CA cert will reject connections made to this IP:

Performing request GET 'https://35.xxx.xxx.xxx:25555/info': Performing GET request: Retry: Get https://35.xxx.xxx.xxx:25555/info: x509: certificate is valid for 10.0.0.5, 127.0.0.1, not 35.xxx.xxx.xxx

Ideally, the task would be able to set up an SSH tunnel (using e.g. sshuttle) to transparently proxy requests made to the OpsMan Director.

Thanks :)

mkuratczyk commented 6 years ago

sshuttle could be an option indeed (I'm a big fan of it). A property to set a value of BOSH_ALL_PROXY could be another option. I'll think about it. Thanks!

rmeharg commented 5 years ago

Am am also attempting this without deploying an external concourse worker to inside the customer plane PCF, BOSH_ALL_PROXY is definitely the preferred and best method rather than sshuttle

rmeharg commented 5 years ago

I started work on this, but external worker is still the best approach until UAAC supports SOCKS5

mike-carey commented 5 years ago

We ran into this issue recently and put in a PR to add jumpbox support for the bosh-creds-resource. It exports the BOSH_ALL_PROXY into the bosh2_commandline_credentials and adds the jumpbox values to both of the jsons. If left empty, they should be omitted by the bosh-deployment-resource

mkuratczyk commented 5 years ago

Thanks Mike! I have merged that PR and pushed mkuratczyk/bosh-creds-resource:1.5. However, unless I'm missing something, it doesn't solve this pipeline's problem completely because the first job still can't connect to the BOSH Director using uaac. What was your solution to this step?

mike-carey commented 5 years ago

Sorry about that. I guess I did not read all the way through. We had created the client ourselves.

mike-carey commented 5 years ago

One option that I recently picked up again is port forwarding through an ssh tunnel. You can still specify the http protocol like you would any other request. So theoretically, if you bind a port with the ssh tunnel of opsman against the director on port 8443 (with any port of your choosing), you can proxy through the bind. I put a gist out there that uses two docker images for proxying the http server through the ssh server as a small demonstration. Not sure if this could potentially get around uaac not allowing socks protocol, but I thought I would throw it out here.