[GH-ISSUE #166] Documentation on HTTP Proxy #39

New issue

Closed

opened 2026-05-07 00:17:57 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:17:57 +02:00

Owner

Originally created by @sdktr on GitHub (Mar 25, 2021).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/166

Hi team,
Is there any hints you can provide regarding the current and intended functionality of the 'http proxy'?
Is it serving the same purpose of the SSH bastion, but for HTTPS <--> HTTPS connections? What authentication methods does it support on the ingress/egress side?

Originally created by @sdktr on GitHub (Mar 25, 2021). Original GitHub issue: https://github.com/ovh/the-bastion/issues/166 Hi team, Is there any hints you can provide regarding the current and intended functionality of the '[http proxy](https://github.com/ovh/the-bastion/blob/d67141b10af49a451a58951b7ddb5535ea9cc2f7/bin/proxy/osh-http-proxy-worker)'? Is it serving the same purpose of the SSH bastion, but for HTTPS <--> HTTPS connections? What authentication methods does it support on the ingress/egress side?

BreizhHardware closed this issue

2026-05-07 00:17:57 +02:00

BreizhHardware commented

2026-05-07 00:17:58 +02:00

Author

Owner

@speed47 commented on GitHub (Mar 29, 2021):

Hello @sdktr ,

You're right, the HTTP Proxy is lacking documentation, that's why it's more or less an hidden feature for now, and it's not advertised too much, it'll be when we have written the documentation. But I can give you a few insights, so you can determine whether this fits the use case you have or not. If it does, it might be a good time for us to allocate some time writing the doc :)

We've developed this feature mainly to manage network devices, that now start having HTTPS APIs instead of just plain old SSH. The idea is to keep the principle of "identity Ix with credentials Cx on the ingress connection, might give access to a set of identities Iy with credentials Cy to a list of network devices". In that case, the credentials are different on the ingress and egress side, and the actual credentials that give access to the device are only present on the bastion. It's useful to have traceability even if for some reason you have service accounts on the egress side that might be used by several different entities. Under the hood, it works in a similar way than for SSH: the request is executed under the user's system account, which can only read the credentials they're allowed to. This also means that there is a non-negligible overhead (to sudo to the proper user) of around 150ms (depending on your hardware obviously). For the use case we designed it for (sending commands to network devices), it doesn't matter, but it might be a problem if response time is a very important metric in your use case.

As we wanted to be compatible with libraries and such, on the ingress side, that would expect to be talking to the remote device directly, we support only HTTPS with Basic-auth on the ingress side (that's what network devices support and expect), and same thing on the egress side.

If that sounds interesting to you, I'll try to draft some documentation soon.

@speed47 commented on GitHub (Mar 29, 2021): Hello @sdktr , You're right, the HTTP Proxy is lacking documentation, that's why it's more or less an hidden feature for now, and it's not advertised too much, it'll be when we have written the documentation. But I can give you a few insights, so you can determine whether this fits the use case you have or not. If it does, it might be a good time for us to allocate some time writing the doc :) We've developed this feature mainly to manage network devices, that now start having HTTPS APIs instead of just plain old SSH. The idea is to keep the principle of "identity Ix with credentials Cx on the ingress connection, might give access to a set of identities Iy with credentials Cy to a list of network devices". In that case, the credentials are different on the ingress and egress side, and the actual credentials that give access to the device are only present on the bastion. It's useful to have traceability even if for some reason you have service accounts on the egress side that might be used by several different entities. Under the hood, it works in a similar way than for SSH: the request is executed under the user's system account, which can only read the credentials they're allowed to. This also means that there is a non-negligible overhead (to `sudo` to the proper user) of around 150ms (depending on your hardware obviously). For the use case we designed it for (sending commands to network devices), it doesn't matter, but it might be a problem if response time is a very important metric in your use case. As we wanted to be compatible with libraries and such, on the ingress side, that would expect to be talking to the remote device directly, we support only HTTPS with Basic-auth on the ingress side (that's what network devices support and expect), and same thing on the egress side. If that sounds interesting to you, I'll try to draft some documentation soon.

BreizhHardware commented

2026-05-07 00:17:58 +02:00

Author

Owner

@sdktr commented on GitHub (Apr 8, 2021):

Thank you very much for this detailed explanation!
A different auth method between in- and egress legs would make this an absolute killer feature. For automated network tooling the current Basic method is propably enough for most of the tools, cert based (mtls) login would be even better. But endusers would greatly benifit from OIDC validated logins on the ingress while protecting the egress leg credentials on the bastion.

Like a combination of mysocketio or other fancy http 'frontend proxies' with the authorization framework and jumphost functionality of The Bastion

@sdktr commented on GitHub (Apr 8, 2021): Thank you very much for this detailed explanation! A different auth method between in- and egress legs would make this an absolute killer feature. For automated network tooling the current Basic method is propably enough for most of the tools, cert based (mtls) login would be even better. But endusers would greatly benifit from OIDC validated logins on the ingress while protecting the egress leg credentials on the bastion. Like a combination of [mysocketio](https://mysocket.readthedocs.io/en/latest/mysocketctl/mysocket.html#quick-connect-options) or other fancy http 'frontend proxies' with the authorization framework and jumphost functionality of The Bastion

BreizhHardware commented

2026-05-07 00:17:59 +02:00

Author

Owner

@tolgaulas commented on GitHub (May 9, 2021):

@speed47 yes, a small documentation will be very helpful, pretty please.

@tolgaulas commented on GitHub (May 9, 2021): @speed47 yes, a small documentation will be very helpful, pretty please.

BreizhHardware commented

2026-05-07 00:17:59 +02:00

Author

Owner

@speed47 commented on GitHub (Jun 30, 2021):

There is now some documentation about the HTTPS Proxy and its configuration file. It can still be improved but at least now there's something to look at :)

@speed47 commented on GitHub (Jun 30, 2021): There is now some documentation about the [HTTPS Proxy](https://ovh.github.io/the-bastion/using/http_proxy.html) and its [configuration file](https://ovh.github.io/the-bastion/administration/configuration/osh-http-proxy_conf.html). It can still be improved but at least now there's something to look at :)

BreizhHardware referenced this issue

2026-05-07 00:19:43 +02:00

[PR #39] [MERGED] release v3.00.01 #187