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 🙂
