adb014 commented on PR #1116:
URL:
https://github.com/apache/guacamole-client/pull/1116#issuecomment-4271513115
I’ve been looking at the today and I like your scheme
```
HASHIVAULT:<mount path>/<path>/<key>/<value>
```
that you have used. But I’d like to see it completed with other secret
engines than just the key-value secret engine. It seems to me only the KV, LDAP
and SSH secret engines make sense for guacamole connections, but if we want to
store guacamole’s database secret in a vault we’ll also need the database
engine as well. I propose including the engine to use in the prefix and
removing HASHI from the prefix to make it shorter after adding the engine and
agnostic wrt to openbao.
So 4 prefixes
VAULT_KV: for the key-value engine
VAULT_SSH: for the ssh engine
VAULT_LDAP: for the ldap engine (also used with Active Directory)
VAULT_DB: for the database engine
So for a static-role in the ldap engine the token to use would be
`${VAULT_LDAP:<mount path>/static-role/<role>/<value>}` where `<value>` would
be “password” or “username”. This works for dynamic roles as well, replacing
“static-role” with “role” as long as we don’t deal with the TTL within
guacamole. The same for service accounts
For the ssh secret engine using certificates we’ll need to create the ssh
keys in guacamole and use the secret engine to sign them. The account needs to
exist on the ssh host so the username should be taken from the connection
username or a key-value otherwise. However, no path or value is needed for
these tokens. So I’d propose a generic token like `${VAULT_SSH:<mount
path>/public}` and `${VAULT_SSH:<mount path>/private}` for the two ssh
certificates. However, there is a quack. The signed ssh certificate can
contain restrictions on the ssh parameters like port forwarding that could be
used to stop these short lifed certificates from being abused
For SSH one-time passwords they are created for a particular username and
hostname, that can be recovered from the connection information itself. Only
the password token makes sense in that case which might be returned with the
token `${VAULT_SSH:<mount path>/otp}`
The database tokens are a bit like the KV tokens with seperate username and
password values. So the token in that case would be `${VAULT_DB:<mount
path>/database/creds/<value>}`. Though the “database/creds” part of the path
always there so they could be dropped in the token and added by guacamole in
the query to the vault.
There are many edge cases in implementing all of these tokens types. I’ll
take a try at it based on your code and the other PR for openbao, but testing
it extensively will be difficult
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
