Permalinks / Static Ports

[micchickenburger]

Is your feature request related to a problem? Please describe.
We have a web app in the cloud, only accessible through Boundary, that sends notifications to a team messaging platform. The notifications should include links to the app. However, ports are ephemeral in Boundary so these links aren't possible.

Describe the solution you'd like
I see two possible solutions:

1. Have a Boundary URI-scheme that initiates a session to a given target if not already established (and auth if not already authenticated), then opens a web browser and navigates to the resource with the given path. Ephemeral ports may remain in this case, but deciding whether to open a web browser could be a challenge since Boundary doesn't treat HTTP differently than other TCP connections. Another challenge would be to make the target ID known to the application sending the notifications. An example might look like: boundary://{target-id}/{path}
2. Enable defining static proxy ports in target configurations. These static ports might need to be in the well-known range to avoid the operating system from using the port and (though a rare occurrence) resulting in a collision. An example might be http://localhost:{well-known port}/{path}. This would also be related to issue Modify /etc/hosts to provide a simple UX for non technical users accessing https sites #1398.

I'm partial to option 1 since it may result in a better user experience.

[malnick]

Sorry for the tardy response on this, I've assigned it to our product manager to take a look! Thank you for the request!

[rjshrjndrn]

Static Ports will be a huge boost, as it'll greatly simplify all workflows, if you're using the desktop app, and that's most of our case(lots of non tech-savvy people).

If there is one more field for a specific client port( it can be best effort) that'll make it much more easier.

For example now when ever I'm connecting to a kube cluster, I've to do

k config set-cluster my-kube-cluster --insecure-skip-tls-verify=true \
    --server=127.0.0.1:56615

else other toolings won't work on this kubeconfig

[ccammilleri]

I'd vote for static ports please! I'm afraid that a custom protocol handler would be more complex to implement and manage in multiple platforms. Additionally, a static port would work better for APIs and scripts or anything command line.

[rjshrjndrn]

@PPacent Hi, will there be any priority on this item? This will make the usability miles ahead.

[engineerang]

• 1 for static port assignment. We have client side apps that have hardcoded ports. Can tell it to use "localhost" but not the random ports as assigned by the workers.

[Dyagilets13]

Upvoting this issue. Static ports gonna be pretty useful.

[szeber]

+1 for this issue as well. Our use case is using vault behind boundary using oidc/jwt authentication, which requires a static redirect URL. We tried using vault tokens as a credential store as well to replace oidc with tokens, but that didn't play nicely with boundary desktop either. So currently we don't really have a way to authenticate into vault for our users who need access to it without using static credentials. We could work around this limitation if we could have vault always exposed by boundary on a specific port (via boundary desktop as we have less tech savvy users as well), allowing us to set a static redirect url for oidc.

[wokalski]

I've also been thinking about permalinks and I want to build an app for it until a better alternative is built in:

Here's what I have in mind

1. poll boundary sessions
2. for each boundary session set up revery proxy so that local.mydomain.com/${target.name} forwards to targets[name][endpoint]
3. add local.mydomain.com to /etc/hosts pointing to the reverse proxy running on my computer

[jrhrmsll]

A proposal to made the access to HTTP targets more simple, https://medium.com/@jrhrmsll/access-to-boundary-http-targets-made-simple-6069dcb3aabe

[micchickenburger]

Hello, I am following up on this issue to see where it is in the roadmap and to ask how I can help. This is an essential feature for us; our Boundary-secured app notifications need to include contextual links back to the application.

[wokalski]

I have found a technique (and I'm implementing a solution based on it) to use boundary for using http targets from the browser without a local client and with static links. Here's the design:

Overview

We leverage:

• cookies to maintain session identity
• the ability to use boundary CLI for multiple concurrent users by specifying the -token parameter

Authentication flow

Boundary HTTP proxy has to be deployed somewhere, ideally wherever the worker is

Let's assume we query something like grafana.eu1.boundary.mycompany.com (<target_name>.<scope_name>.). There has to exist a DNS entry pointing *.boundary.mycompany.com to the boundary http proxy.

If there is no session cookie or no valid session for that cookie we have to authenticate. The proxy queries <controller-url>/v1/auth-methods/<auth-method-id>:authenticate and responds with a redirect to auth_url and a session cookie. The user authenticates.

Requesting resources

The user requests grafana.eu1.boundary.mycompany.com now with a valid session cookie. The proxy looks up if there's an existing connection for that user (as identified by the session id) to that target (identified by <target_name>.<scope_name>.boundary.mycompany.com). If it doesn't exist it will spawn a boundary connect to that particular target with -token associated with a given session id cookie.

After a connection between the proxy and worker is established, the original request is proxied to that localhost address and back.

Feedback

Please reach out with feedback. Especially with security-related flaws.

This solution addresses the most common use case in my experience. It's also very non-technical-user-friendly.

It does add another piece to the infrastructure and slightly diminishes the benefit of distributed, target-aware workers.

The lack of local client: a pro or a con?

From user's perspective, it's great.

I have mixed feelings about it from security perspective but it seems to me like a security win. You have to own the session cookie to be able access the http proxy. With boundary CLI it is possible start malicious connections from unrelated processes if only you get access to shell and boundary was previously authenticated.

HA use

The HTTP proxy processes are stateful. But you can still deploy multiple instances of the proxy, you just might end up having multiple open sessions for a given user to a given target. Any risks here?

[ap-vishal]

Having static port would be really nice, we are using boundary to connect to RDS databases and every time a developer creates a session they get a new port which makes them change their client configurations many times, this becomes really painful when we have lots of databases :(

[ap-vishal]

@PPacent is there any priority for this issue? From the reactions, it seems many people need it.

[xingluw]

Hi everyone, work on web/https targets and static ports is important for us and something we are actively investigating

[malnick]

Hey everyone, I was reading through this thread today and realized there hasn't been a mention of a boundary connect flag we've had since 0.1.1:

  -listen-port=<int>
      If set, the CLI will attempt to bind its listening port to the given
      value. If it cannot, the command will error. This can also be specified
      via the BOUNDARY_CONNECT_LISTEN_PORT environment variable.

Passing this flag will give you a static port, and wanted to see if this solves this issue or if there are other use cases where setting a static port on the target resource directly would be of value. Thank you for your feedback!

[micchickenburger]

@malnick, I think this doesn’t resolve the issue. Firstly, an application developer would not know what static port is chosen by the user, and users could choose different static ports. Secondly, I have found that our users, at least, prefer using the UI.

[malnick]

Thanks @micchickenburger - the UI use case is a compelling reason to add this to the target resource. We're going to dive into this more soon, but perhaps the flag can be a temporary work around for those on the CLI? More on this soon, thank you for all the feedback!

[dmitryroshchin]

Any news, how things are going with this request?
Looks like lots of folks are waiting for this feature!
Are there any perspectives?

[xingluw]

@dmitryroshchin no updates yet, this is something we are keeping an eye on

[AdamBouhmad]

Hey all!

We're excited to announce that in 0.13, Boundary introduced 'default_client_port', as a new, optional attribute on a TCP or SSH target, enabling the ability to the set the default port users can connect to their boundary worker over when looking to establish a proxied connection to a remote target.

Changelog

We also released a ton of new functionality in 0.13, which you can read about in the 0.13 release blog: https://www.hashicorp.com/blog/boundary-0-13-introduces-ssh-session-recording-boundary-enterprise-and-more