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.


Remember our first time opening Vault. So many authentication options but we just went ahead with the Token login.

vault ui login screen

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.

only auth method available

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=default

Notice 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.

apple (token) does not fall far from the tree (parent)

Using the created tokens, I can login both from the cli and the UI

basic cli login
after a ui login with a new token

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.

enable auth authentication
basic config

Let’s create a user and login to vault with that.

user creation

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=123

By 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
enabled auth methods

Anyway, moving back let’s try that login again but from the UI.

we need that mount path
not many permissions on that user yet, also not the brightest idea assigning a single use token to a user

I created another user yigit2 without a login count limit and works fine.



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.

ldap connection details

Redhat IPA if you want to try it out.

connection details of this ldap

Lets configure Vault side by enabling the LDAP auth…

enable ldap auth method

…and configuring it as below

basic config
ldap specific configurations
this bit is a little tricky. compare with the ldap settings several pictures above

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.

don’t forget to select method as ldap

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.


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


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.

setting up aws auth

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
*shocked pikachu face*

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"
logged in

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.

so many auth methods available

Thanks for reading and see you next time.




Let’s talk devops, automation and architectures, everyday, all day long.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

top ten tips how to get free domain and hosting for wordpress?

Cloud-Native Prometheus Solution: High Performance, High Availability, and Zero O&M

Capturing Lightning: Moving to a Microservices and Serverless World

Everything you need to know to resolve the Git Push RPC error

Getting Started in CakePHP | CakePHP blog

5 Bonus Tips To Help Out Effectively on Open Source Projects

Three women sit around a table working intently on laptops

Eager Loading Polymorphic Associations in Ruby on Rails

SAP ABAP for Beginners

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Yiğit İrez

Yiğit İrez

Let’s talk devops, automation and architectures, everyday, all day long.

More from Medium

Shell completion for plugins with Helm 3.8

Releasing Helm Charts maintaining your mental health

Vault Authorization — ACL(Access Control List) Policies

Canary Deployment in Kubernetes (Part 2) — Automated Canary Deployment using Argo Rollouts