Permanent Credentials working over dynamics connections .

[pratiyush05]

Describe the bug Permanent credentials still work over dynamically created connection .

To Reproduce Steps to reproduce the behavior:

1. Setup boundary with vault for dynamic credential generation via credential store .
2. On Boundary desktop app , connect to the target which generates dynamic credential using a permanent credential placed in vault .
3. Boundary provides localhost:port and dynamically generated credential to use for connection . We tried same localhost:port but with permanent creds which were stored in vault . It CONNECTED !!.

Expected behavior Only dynamic credentials must work on that localhost connection .

Additional context We have deployed boundary and vault on k8 using helm chart . Boundary chart used - https://github.com/ugns/boundary-chart Boundary Image - 0.14.2 Boundary Desktop Version - 1.7.1 Vault Image - 1.13.1

[jefferai]

Boundary does not enforce which credentials are accepted by an end host -- that is up to the configuration of the end host. If those permanent credentials are valid, they are valid whether you go through Boundary or not.

The only difference is for sessions in which credential injection are used, which are currently limited to SSH on the cloud/Enterprise versions of Boundary. In that case the user does not provide credentials to have the session connect, so the user cannot pass those permanent credentials through Boundary; however, if the user is able to connect to the machine not via a Boundary worker, then those permanent credentials will still be valid.

[pratiyush05]

Hi @jefferai , sorry to bother again, so once we click on connect and generate dynamic credentials , shouldn't these dynamic credentials be the only one to be able to connect to this host via this local port ?

My query is , long lived credential which was used to generate this dynamic credential works over this localhost connection . So its like parent credential is working over this child credential using child connection . Is it a valid test case for boundary ?

[jefferai]

Hi there,

Boundary does not control the credentials that are valid on the remote system. If you are getting credentials from Vault via Boundary, Vault is creating those and managing the lifecycle of those credentials, and is ensuring that during their validity period those credentials are valid on the remote host, but Vault is also not controlling any other credentials created outside Vault that are considered valid by the remote system.

[ankit-ls]

Hi @jefferai, in that case Boundary is acting like a passthrough proxy (and not as an identity aware proxy) through which users can connect to the Databases using any existing credentials. Don't you think Boundary should only allow the dynamic credentials (which Boundary has generated) to access the DB over the secure tunnel (which Boundary has opened)?

To give you more context on our current setup, we have 2 networks:

• one, where our databases are hosted: users are not allowed access to this network
• second, where Boundary is hosted: this network is peered to the DB network allowing Boundary access to DBs, users have access to this network

By using Boundary, we are allowing users to connect to the DB over the secured tunnel (via Boundary network), which we feel should only allow the secured sessions created by Boundary. If Boundary allows any existing long-lived credentials to connect to the DB via this tunnel, then it is opening a loophole which can be exploited by users using those credentials. Let me know your thoughts on this.

[jefferai]

Hi @ankit-ls

Whether Boundary is acting as a passthrough or identity aware proxy depends on the target type. The tcp target type is a pure passthrough where Boundary is only gating whether the network connection is allowed to be made (and potentially routing it to the right spot); the ssh type is identity-aware and can inject credentials.

Don't you think Boundary should only allow the dynamic credentials (which Boundary has generated) to access the DB over the secure tunnel (which Boundary has opened)?

Boundary doesn't generate credentials. It can plug into Vault to have credentials dynamically generated, but those are Vault-generated credentials, not Boundary-generated credentials.

Boundary also purposefully doesn't interact with the remote machine in any way other than as a network endpoint. This is because Boundary does not require (and we do not want to require) an agent installed on the remote machine. While this provides less functionality in some ways, and we may introduce an optional agent at some point for enhanced functionality, the tradeoff is that Boundary can be used to gate access to all kinds of services and endpoint types where installing an agent is totally infeasible (think things like switches/routers, SaaS-hosted services, etc.).

Some other products may require and use such an agent and actually send network connections to that agent, so for instance, the agent may act as an SSH server that is configured to accept only the credentials that are produced by the product that owns the agent. I think it's important to note, however, that even in this scenario, this still doesn't disallow "permanent" credentials. For instance, in such a system, if you have connections through the system sent to the agent running on port 2222, but you also have vanilla OpenSSH running on port 22 and can make a network connection to the vanilla OpenSSH, any credentials accepted by OpenSSH will still be valid for use.

There are also other products out there that manage the local accounts database on target machines, so they are in control of what accounts are available on the machine and what credentials those accounts accept. Boundary is not currently such a product -- again, that would require a very intrusive agent on every remote endpoint and would only work for some endpoints. It may gain some kind of functionality like that in the future via an opt-in agent, but it's not something that Boundary does right now...and arguably that's really a separate (but companion) product than something like Boundary anyways, where Boundary controls the network access and can talk to such a system to fetch current valid credentials for an account, but is not itself constantly managing those accounts. (This is purely speculation though, to be clear.)

[ankit-ls]

Makes sense. Thanks @jefferai for explaining it in detail.