cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Defacto Standard required for storing credentials and configuration information

Kind of a big deal

Defacto Standard required for storing credentials and configuration information

One area I feel we are lacking in is a commonly accepted way for storing credentials and other configuration information across the different SDKs and platforms.  I think this is because when the API is young more emphasis is placed on just gettings things going and "out there".

 

As a result we frequently see sensitive information directly coded into scripts (I'll put my hand up here - I plead guilty).  The danger is other new users to the API copy and paste the bad practice and the issue perpetuates.  Eventually someone creates something they think is pretty cool and makes it publically available and accidentally leaves in their sensitive info.

 

I think as a community we should adopt a common method to store this information and use it everywhere.  The API example scripts should be updated to use it.  Then new users will copy and paste good examples that wont get them into trouble.

 

You should be able to grab your code at any stage, give it to someone else, and not expose yourself to any security issues.

 

Ideally I think there should be a standard place for this info so you can globally configure things like your organisation name and API key.  Then you can just download a script and "go".  You should also be able to have a local override (or to add additional info) in the local directory.

 

A couple of approaches is to use a library like dotenv available in Python and node.js and store the info as simple name=value pairs.  dotenv also allows you to specify local values in environment variables (so you could put an API key and org name in your user environment variables for anything you run to use).

 

If we adopted a common file (and common contents) for this, say meraki.env and everyone uses it then it would make it so much easier trying out new projects and for those creating projects to publish them safely.

 

 

Another option is to use json and have something like a meraki.json file that everyone uses.  Same deal.

 

 

I don't really mind too much which approach is used, but I think we should adopt some approach.  Ideally whatever is adopted should be placed into the actual SDKs so that it becomes automatic for every new project that gets created and we get this nice uniformity.

 

 

I wish I had a voting button.  What say you?

 

I know, I made this too long and you didn't get down to this line did you.

8 REPLIES 8
Kind of a big deal

Re: Defacto Standard required for storing credentials and configuration information

I guess you could also use a ~/.meraki or %userprofile%\.meraki file as well.

Kind of a big deal

Re: Defacto Standard required for storing credentials and configuration information

Actually I quite like the AWS approach where they have seperate credentials and config files.

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html 

 

"The AWS CLI uses two files to store the sensitive credential information (in ~/.aws/credentials) separated from the less sensitive configuration options (in ~/.aws/config)."

Here to help

Re: Defacto Standard required for storing credentials and configuration information

I've always used dotenv with node projects.

 

I don't think there is a 'standard' that could apply across the board given each language/framework would have their own way to do something similar. I haven't used python, but you said it also has a dotenv library which is cool.

 

IMO this is probably the best way forward because if you used something like meraki.json to store those credentials and you want to add email support or twilio integration then you will end up needing to store those credentials somewhere. You would probably end up back to using dotenv...

Kind of a big deal

Re: Defacto Standard required for storing credentials and configuration information

If you used json format then you could make the first level the vendor/product.  So lets say we called it cisco.json.

 

Then the first level could be:

meraki

webex

twilio

mysql

amazon

azure

 

And then under Meraki could could have things like:

key

org

 

And I would imagine it being referenced programtically something like:

 

config.meraki.key

config.meraki.org

 

 

However this is still pretty easy using dotenv.  We could adopt the convention vendor.key, so something like this in the "env" file:

meraki.key=xxx

meraki.org=xxx

mysql.username=xxx

amazon.xxx=xxx

 

I've been using dotenv myself and having the same thing available in Python and node.js already is very convenient.

 

 

 

Highlighted
Kind of a big deal

Re: Defacto Standard required for storing credentials and configuration information

I've been reading over how AWS handles this, and I really like their thinking.

https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sd... 

 

In particular, I like how they store the credentials in the users home directory - completely outside of any project yet usable by every project.

 

I think there is some merit to storing credentials and configuration information seperately as well.

Building a reputation

Re: Defacto Standard required for storing credentials and configuration information

I created an environment variable on my machine called MerakiAPI that stores my key. I have also had other users that utilize some of my scripts create that variable on their machines and save their keys. That being said, there is a hardcoded key for a generic account in the scripts if the environment variable can't be found. Not good for security, but I have a couple of users that are running a single script that is specific for what they do (inventory is one example). These users don't need any other API access and their dashboard access is read-only, so they don't have their own keys.

 

A standard way of storing/referring to this information safely would be nice to have.

Meraki Employee

Re: Defacto Standard required for storing credentials and configuration information

We've been thinking about ways to improve environment management as well. 

 

For instance, you may have noticed that over the past few updates, the path parameter names have been made unique. This supports a global environment variable name space. As a result, all of the potential param names are included in the Postman Collection.

DexterLaBora_0-1575377046481.png

 

If you export the collection to a JSON file, you will see that there is a root key called "variable" that will list out all of the potential param names, type and default value. 

DexterLaBora_1-1575377257325.png


point being, we are aiming for consistency with environments, regardless of "how" it is implemented. 

Regarding authentication in general, stay tuned for future developments. And join the Early Access program if you want the details sooner 🙂

Kind of a big deal

Re: Defacto Standard required for storing credentials and configuration information

I must admit I haven't been able to get "into" Postman.  It looks pretty when I have tried but for some reason it doesn't "gel" with me as being something usefull I can use.  It doesn't seem to address any problem I have.

It just seems to let you interact with an API without cutting any code.

 

With regard to Python and node.js I've been thinking mostly about solutions around dotenv (since it is available for both platforms, widely deployed and well respected).

The idea I'm starting to settle on the most is using two calls to dotenv.  One to retrieve a "global" environment file from the users home directory (such as .meraki.env) and one from the project directory.  The idea being the home directory file can store settings for the global use across all of projects, such as credentials.  I like the idea of storing credentials completely outside of the project directory as it would stop accidents happening, and it means common things like credentals can be used across all projects.

The idea of a second call to dotenv to load a project file means you can retrieve config related to just that project.

Effectively this would allow a global configuration with a per project override.

I like th idea of being able to having environment based parameters because you can esaily feed them into serverless environments like Amazon AWS Lamba with no code changes.

 

One idea I am still chewing over; I think it would be nice to be able to load a set of parameters based on an environment variable itself.  This would allow for handling the "switching" of envionments, such as between test and production.  So perhaps the project based settings file to be used could be specified by an environment file itself.

 

So a flow something like:

if exists env.MERAKI_CONFIG dotenv.config(env.MERAKI_CONFIG)

else dotenv.config(().

dotenv.config(HOME_DIRECTORY+".meraki.env")

 

So now you can set the environment variable MERAKI_CONFIG to something like "test.env", "production.env", etc to make your app switch between different settings, as well as pull a global environment setting, and all with minimal lines of code being added to the app - and zero code changes are required when you switch environments.

 

 

How does Postman store these variables?  Can it store/load them in a compatible fashion with dotenv (which would be super usefull)?  Postman seems to use json a lot.  I have moved away from the idea of using json for config where possible after doing a lot of reading on Google and people's horror stories with trying to modify their config files and how easy it was to accidentaly break things.

The other idea I like is using old school ini files, because of the abilities to have sections.  I like the idea of being able ot have a "test" or "production" section, or a "meraki" and "mysql" section.  It's also nice to be able to have comments in the ini file.  But its hard to go past the simplicity of the dotenv name=value system.

 

 

I joined the "Early access program" when it was first announced.  I have not heard anything.  Is the program actually active or when do you think it will become active?

 

 

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.