How to protect API keys? (Newbie)

Maggs
Here to help

How to protect API keys? (Newbie)

Hi all.  I'm a sysadmin just starting out with scripting.  I'm loving learning so far and have a pretty basic question.  If we want to have a script run in a scheduled way, what can we do to protect the API key? 

 

For day to day work, I understand we should pass the key as a variable and not include it in shared source code.  I also see PhilipDAth's excellent proposal to help protect keys.  https://community.meraki.com/t5/Developers-APIs/A-newer-safer-way-to-access-the-dashboard-API/m-p/69...   

 

For a scheduled script, It seems we need to pick a relatively secure place to put the key, lock it down as much as we can, and that's about it.  I'd appreciate advice from those with more experience.

 

By the way we're using Python.

 

Thanks!

 

 

8 REPLIES 8
sungod
Head in the Cloud

I use a Centos VM to run all the API access - actually a replicated pair, with limited login access using ssh with keys not passwords and all sitting on a segregated network accessible inbound by VPN only.

 

The people with direct access to the VMs (and physical UCS servers etc.) are a small subset of ones who have Dashboard admin access (mandatory 2-factor authentication).

 

Bear in mind, the weakest link is may be people with Dashboard admin read-write access, rather than API key storage/access per se.

 

For API use that's for stats/reporting only, the API key comes from a dedicated Dashboard account with admin read-only.

 

The API keys/other credentials are held in a central store as the application uses multiple vendor APIs, and is modular so it's easy to add extra target networks and other APIs.

 

Everything is run by cron. At runtime credentials are pulled from the store by a 'wrapper' that runs the python scripts and chooses the correct set for each orchestrator/target, then they are put into the environment so the script can get them with os.environ.get()

 

To protect API keys on a 'shared' system would depend on the environment. You could encrypt them and decrypt on the fly based upon the identity of the requesting process, but at some point they'll exist as plaintext in memory and in principle be vulnerable to a sufficiently skilled user. Really depends on your level of paranoia 🙂

 

Summary:

  • limit Dashboard admin users, especially read-write
  • make 2-factor Dashboard access mandatory
  • strictly limit access to the system holding the API key(s)
  • keep keys in one place, rather than scattering them around the system

 

Tbh I wish Meraki had the option for API key to not be linked to individual admin account(s), require 2+ designated admins to modify and maybe be pki/cert-based rather than simple plaintext, as it would improve the security of generating/managing keys. But this is an issue across other SDN APIs too, not picking on Meraki 🙂

 

Thanks sungod!  All good ideas.  This gives me food for thought.  We have the dashboard admins pretty locked down and we're starting with read-only API access.  I'll do some searching but if you have any further advice on encrypting and decrypting keys on the fly, I'm all ears.

 

Much appreciated.

PhilipDAth
Kind of a big deal
Kind of a big deal

What platform are you running the scripts on?

Windows

PhilipDAth
Kind of a big deal
Kind of a big deal

I've never used it, but you could check out using "Windows Protected Credentials" or something like that.

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/comprehensive-protection-for-your-credent... 

 

You could also store the API key in the registry with an ACL only allowing the specific accounts that need it.

Thanks PhilipDAth!

Maggs
Here to help

A couple other suggestions I've heard since posting are to use a PaaS service with its own protection features, or Azure Automation Accounts.

DarrenOC
Kind of a big deal
Kind of a big deal

Hi @Maggs - some food for thought in this post:

 

https://dzone.com/articles/security-best-practices-for-managing-api-access-to

 

 

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.