Dynamic API Token Generation For Temporary Users with Vault

Computeracer
Conversationalist

Dynamic API Token Generation For Temporary Users with Vault

We like to use Hashicorp's Vault to generate temporary credentials for admins and CICD pipelines. This can be done with other cloud vendors like AWS like show here. The current Meraki API allows the creation of admins, but the only way to get an API token is to setup the account with email and proceed to create an API token through the GUI.  We have submitted a wish, but I was wondering if anyone was looking into such a solution?

 

I found a similar post regarding this need for API access: https://community.meraki.com/t5/Developers-APIs/Manage-organization-admins-with-API/m-p/64292/highli...

 

4 Replies 4
PhilipDAth
Kind of a big deal
Kind of a big deal

I would like to be able to create API tokens not associated with a user account as well.

 

The tricky bit is how to handle multi-orgs.  At the moment, you can create a user, give them access to three orgs, create an API key, and that API key can access all three orgs.

 

It's difficult to see how a system would work that can allow the creation of just an API key (with no user attachment) to have similar functionality.  Perhaps the API key would need to be a special kind of user account that can not log in interactively.

sungod
Head in the Cloud

If it were possible for an admin to define multiple org-specific keys that were either full admin or read-only, it'd address many of my wishes.

 

As it stands I (or another admin) need to create multiple logins, each needing a different email alias, each needing TFA set-up. If the admin changes, it all needs ripping up and redoing. It's not a good solution with multiple orgs.

 

The API authentication process starts with the key, clearly the logic to look-up a key is there.

 

That's the point at which the access privileges for that key are established it doesn't seem a huge complication to make those privileges those of the key rather than of the owning admin.

 

If it really must be based on a user ID, then let admins create multiple aliases that each have only one editable thing in their user profile: the API key (everything else just inherits from the parent ID.)

 

The login email address could use a syntax like n!real.email@real.com  where the n is a Dashboard generated 'alias ID' followed by a '!', so we don't need to create and manage real email aliases, there's still only the single admin email - this alias isn't ever used as an email address, the ! is never going to get routed as a bang path 😀

 

Then we just add the alias ID as the admin and it can have it's own org access settings.

 

It's a bit of a 'bag on the side', but again it's something that feels it should be possible as a simple extension.

 

AutomationDude
Building a reputation

What are you looking to do with the temporary API users? Curious to learn more.

 

Don't think Meraki will implement this soon as it would require a complete overhaul of the current API structure. Is having the users log on to the dashboard one time really such a big problem?

Computeracer
Conversationalist

The benefit of api tokens that can quickly be created and destroyed are that they are short lived, and less likely to be compromised. The vault product could create the temporary token and it would exist only for the amount of time needed for a job to finish it's work and then no longer exist. A job could perform any meraki configuration through the api. Even if we just had an API call to create and delete the API tokens for an existing user would be a small step to work towards this. It is inconvenient to have to come up with email aliases for a 'service account' that a human would never use, but not a show stopper to work towards short lived tokens.

Get notified when there are additional replies to this discussion.