I need clarity on few of the below concepts. Pls add your inputs
My observation on AWS - When we add a target, the target needs to have a .pem file associated with it. Boundary connect ssh would not work and gives permission denied errors if I try without it. Even the controllers and workers look for a key on the local .ssh/id_rsa for access from console. Imagine I have a developer who needs access to the target via ssh - Do I give him the key? Is this not what we are trying to avoid?
Right now, I have 3 ubuntu instances and 1 centos instances - I created these targets and I can connect to them as I have keys.
How do I give access to other team members?
I have my concepts clear that boundary does not directly connect to target using these keys- the worker brokers the connection and tunnels to target.
But still why do we need these keys ? Is this because we are working with cloud instance?
How does the worker connect with target? My understanding is that it tunnels the ssh connect through portforwarding to localhost on a specific port.
Boundary proxies access, but you still need whatever credentials are needed to log into the target, if it requires a login for the type of access you’re trying to establish. For a typical cloud host that means an SSH key (or possibly a username and password) – in the simplest scenario one of two things is usually the case:
your team adds their public SSH keys to your account in the cloud platform and you attach those keys by name to the host config in the cloud provider when you create the host
your team has some repository of all their keys somewhere and when you create the instance, it has an embedded first-boot or cloud-config script that retrieves the keys and adds them to the SSH config on the instance (GitHub’s SSH key URLs are a popular way of doing this)
If you have either of these happening then everybody can just use boundary connect ssh... and it should use their default keys automatically since it just invokes the user’s own SSH client.
In a more advanced scenario, you can have things set up so that a trusted authority first signs the user’s SSH public key with a time-limited signature, and that signature is passed as part of the key authentication to the host in SSH. The host doesn’t have everyone’s keys but accepts their keys if they are accompanied by a valid signature from an authority it trusts. You can do this with Vault today – Boundary doesn’t support that workflow directly because you have to send the user’s public key as part of the signing request and Boundary doesn’t currently have that kind of parameterization for dynamic credentials (although it’s being worked on), but you can do the signing request before connecting and pass the signature as an additional argument to boundary connect ssh.
In all of these scenarios, the only thing ever exchanged over the network is non-sensitive public key info – the user never downloads a private key from anywhere and they never send the private key they generate anywhere either.
(One of the reasons SSH access is such a difficult case in any kind of proxy scenario is that SSH by design makes it difficult to log in any other way than via a direct connection to a known host with an explicitly host-trusted key.)
As to how connections work with Boundary, the worker connects to the target directly, then the user’s client (boundary CLI or Boundary Desktop) sets up a local proxy to the target using the worker as a remote proxy. So when you connect to a target, the worker needs to be able to connect to the target port on the target host. When the Boundary client establishes a session to that target, it will authenticate to the worker and set up a random local port on the client machine to forward traffic to it. The user’s native client (web browser, DB client, SSH client, etc.) then connects to that local port, and the traffic is forwarded to the worker which forwards it to the target host.
I’m commenting, first to track this as I’m trying to understand this concept also. Second, @omkensey so the dynamic Vault Signed SSH authentication is being worked on but is not supported at this time as I understand your remarks. Would this workflow eventually allow for grabbing an SSH key from Vault and signing it to allow for granting access without the user needing the key? I already have the trusted CA key from Vault included in our AMI build process and then have Vault policies for different roles to allow signing which I could see granted in Boundary to user groups. Or is it a workflow that simply allows passing the public key and having Boundary submit it to Vault to be signed and sent along with the SSH proxied connection?
Would this workflow eventually allow for grabbing an SSH key from Vault and signing it to allow for granting access without the user needing the key?
More the other way around – the user has the key, the key becomes trusted by the host because Vault signed it and the host trusts Vault. (Don’t we all, though? )
Obviously that’s going to be a powerful signature to have, so you want it to be tightly controlled both in who’s allowed to access it and how long that signature is valid for.
I already have the trusted CA key from Vault included in our AMI build process and then have Vault policies for different roles to allow signing which I could see granted in Boundary to user groups.
This would involve a different CA certificate, but same principle, yes. Anything that holds an SSH public key and has a token that allows it to request SSH key signing from Vault can have that key signed. In terms of how credential libraries work in Boundary now, control over who can access which credentials comes down to which targets have which credentials attached and who can access those targets.
Or is it a workflow that simply allows passing the public key and having Boundary submit it to Vault to be signed and sent along with the SSH proxied connection?
I’m not sure what that workflow will eventually look like, myself. At a minimum something has to contact Vault with a token and an SSH public key data blob and request Vault sign that blob, but any plans that might exist around that workflow are blank space in what I know currently.
)