For review: Vault integration #2039
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
candlerb
force-pushed
the
vault
branch
2 times, most recently
from
f723012
to
69e0648
Compare
This was referenced Mar 15, 2021
candlerb
force-pushed
the
vault
branch
6 times, most recently
from
02cfb73
to
641e3d6
Compare
connectors:
- type: vault
id: userpass
name: Vault (Userpass)
config:
vaultURL: https://vault.example.com:8200
mountType: userpass
claimMappings:
email: email_address
- type: vault
id: google
name: Vault (Google)
config:
vaultURL: https://vault.example.com:8200
mountType: oidc
mountPath: google
claimMappings:
email: email_address
preferred_username: ssh_username
# mapping metadata to group membership
"?ssh": ssh_username
Signed-off-by: Brian Candler <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This is a connector for Hashicorp Vault, just for initial review and comments.
What this PR does / why we need it
This allows Vault roles to be used for Dex authentication. It supports both username/password and OIDC auth roles.
Vault has an interesting story around identity management - see the diagrams in this blog post.
Users are "entities" which can be linked to multiple authentication identities; groups can be assembled from entities, either using internal membership, or external mapping of OIDC claims to groups.
As an example: suppose you have two OIDC sources, let's say Google and Azure AD. Instead of pointing Dex directly at those two sources, you could configure Vault to use those sources (two separate Vault auth mounts), and enable the Dex Vault connector twice for those two auth mounts.
The end result is similar - the user gets to choose between two OIDC sources to login to Dex. However:
subclaims are the Vault entity IDssubto Dex [^1]Special notes for your reviewer
A problem I had is that Vault's OIDC challenge sets its own "state" which is different from Dex's "state".
Since Dex validates the state before calling
HandleCallback(), I had to replace the Vault state with the Dex state, and stash the Vault state away somewhere to restore later.For now, I have done this in a
sync.Map. Ideally this state would be stored in the storage backend, because I couldn't find a way to stash data in the authrequest betweenLoginURL()andHandleCallback(). Maybe the connector API surface needs extending to handle this. (EDIT: raised separately as #2040 / #2041)Another note: Vault has a rich way of setting metadata on entities. This is crying out for being returned as custom claims, but they're not available in Dex yet (#1182).
Currently, this connector has no Vault token of its own: all Vault API calls are done using the token generated from the user's login process, i.e. under the privileges of the authenticated user. However it might be necessary for the connector to have its own token, in particular if it wants to map group IDs to group names.
Does this PR introduce a user-facing change?
It's a new connector. I realise there's a moratorium on those pending external connectors (#1907) - but hopefully it would be easy enough to extract.
[^1] EDIT: this is not quite true, because the Dex "sub" claim is a combination of the sub and the connector id. So if you make two connector instances, say "vault-azure" and "vault-google", even if both return the same entity ID, the Dex subs will be
1234-abcd vault-azureand1234-abcd vault-google(plus protobuf and base64 encoding)