Vault Part 4 - Transferring Authentication Burden to Vault
I remember in at least one of the apps I worked in we had both user-pass and LDAP creds, with more types on the way but each used their own tool to authenticate. You had to wrestle with LDAP, manage your manual users, dome something else for another connection on all different platforms. Vault apparently does most of this for us.
Note: Everything done via cli or UI can be done with the Vault API as well.
Token
Remember our first time opening Vault. So many authentication options but we just went ahead with the Token login.
But if you were using an app, you wouldn’t give a root token away for the devs to use because in the very best case, someone well wishing like me, but not knowing the whims of Vault API properly, would nuke something core (ACL policies for example) unintentionally and there comes the sleepless panic fixes for the whole team.
We can login with the root token because, as we can see below, only the token auth is enabled.
But why just root, right? I want to add more people from the UI. So click on the token auth and try to add another person. In Vault, you can’t do everything from the UI. Best bet is cli or if you want, the Vault API could be used.
When we first run Vault, a root token which we used many times on our previous adventures, is created and assigned the root role which can do whatever it pleases in the Vault environment. We need to create other token holders who could at least not nuke the system.
vault token create --policy=defaultNotice below, if we don’t assign a policy, it automagically assigns whatever token we are working with. Checking the expansive vault docs, we need to define policies (other then default) to govern client behavior. (We don’t have to but we really should.) Before that though, let’s not get lost in the policies immediately.
Using the created tokens, I can login both from the cli and the UI
User-Pass Auth
Who doesn’t like the good old-fashioned user-pass login? Probably almost everyone but we are going to enable it and login with that anyway.
Let’s create a user and login to vault with that.
The only bits worth mentioning here is the TTLs we can set and the CIDR access limit of our user. We can also set maximum use of a token here as well. Later on, we can assign our policies via the Generated Token’s policy bit.
Let’s try logging in,
vault login -method=userpass -path=userpasswow username=yigit1 password=123By default, we need to select the method of our login, in this case userpass, also since our path is not the default one we need to state that via -path field. Our magical super secret username and pass are plain text for all the world to see.
If we want to see if an auth capability is enabled, we can use below command with our root user (the tokeny one).
vault auth list
Anyway, moving back let’s try that login again but from the UI.
I created another user yigit2 without a login count limit and works fine.
LDAP
Now let’s try the ldap auth in Vault but I’m not going to go setup an AD so I’ll be piggybacking on existing free LDAPs available.
- Used the free “Ldap Admin” tool to wrestle with LDAP. Link
- Found 2 free hosts, links below, first is the one I used,
Forumsystems has hosted an ldap test server for 7 years apparently.
Redhat IPA if you want to try it out.
Lets configure Vault side by enabling the LDAP auth…
…and configuring it as below
Some parts are a bit cryptic in Vault but in the last image the first part is asking for the bind user and the user DN field is asking for the dc where users are. User Attribute field in the second image is cn by default so don’t forget to change to uid.
Now try logging in with any of the users.
Going back to LDAP auth method and clicking users (or groups for that matter)…
We get an empty list. Here, we can match ldap groups/users with Vault policies to manage Vault access. Right now, our ldap user is bound with the default policy.
GitHub
Note: We need a github organization for this to work. Can create a free one in 5 mins. Steps, here.
As usual, lets enable and start configuring github auth but this is like the token setup so no UI for anything more than basic config. Let’s do it with the cli.
vault auth enable github #add --path=githubwow if you want a non default path
vault write auth/github/config organization=esat-koc #your github org name
vault write auth/github/map/teams/esat-koc value=default #this line maps our org team to the default ACL Policy
vault login --method=github token=$PREFERABLY_IN_ENV
AWS
I have an initial run of the AWS login but, as you will later find, some parts are missing. Please read the official docs since it’s a mile long, it’s one of those things that will take ages to cover decently. In short Vault can log you into EC2 and IAM separately and it insists on creating roles for the Vault IAM user we reused in the configuration, named vaultuser from our Dynamic Cred part. Configuration is as below and there is nothing else to do in the UI.
In the cli we need to run the below command to create a iam-role for our supposed dev env called dev-role-iam. the iam principle arn is from the below image of our IAM user used in the aws auth config
vault write auth/aws/role/dev-role-iam auth_type=iam bound_iam_principal_arn=arn:aws:iam::1111111111:user/vaultuser policies=default max_ttl=500h
We can now login with the below command
vault login -method=aws role=dev-role-iam aws_secret_access_key="$FROM_ENV_SECRET" aws_access_key_id="$FROM_ENV_ACCESS_KEY"
For now as a light brush up on the topic, this should suffice but the concept needs its own wall of text which is for some other day.
Out of the other methods shows in Vault login, I’ve never heard of Okra, RADIUS and OIDC, don’t have the willpower to slug through JWT. Besides those, there are other auth types available each with it’s own unique hill to climb. Let’s move on to authorization a bit.
Thanks for reading and see you next time.
