DEV Community

Cover image for Hide your f🤬🤬king API keys and credentials from versioned code
Jonathan BROSSARD for Monisnap

Posted on

Hide your f🤬🤬king API keys and credentials from versioned code

As a developer, you deal every day with API keys, passwords, credentials, tokens etc... and you do NOT want to share them.

Here are the different ways to handle them :

1 - A versioned settings file with secrets in it.
If you do that, please continue to read this post, internets need that.

2 - A non versioned settings file.
Better ! But when you'll onboard developers, it will be funny to check how you'll send them these values.

3 - Environments variables (the classic .env) !
Yeah ! Even better. Once again, how your future team members will have their own, by copy pasting yours ?

4 - Store your secret into a secret management service !!!
Yeah ! OK, let's see how to do so

There are several secrets management tools, but, I'll talk about the one I know best, because this is the one we're using at Monisnap : AWS Secret Manager.

What is AWS Secret Manager ?

AWS Secrets Manager is a secrets management service which enables you to easily rotate, manage, and retrieve credentials, API keys, or other secrets.
Using Secrets Manager, you can secure, audit, and manage secrets used to access your resources.

You'll now be able to share your code (every file, every line), without any fear. Indeed, in your code, there will only be specific strings which describes your secrets, but not the secrets values themself.

Before Secrets Manager After Secrets Manager
db-name.cluster-cifkjshyfli1p.eu-west-2.rds.amazonaws.com. DB_HOST
username DB_USER
password DB_PASSWORD

Security

AWS Secrets Manager automatically rotates your secrets. Your teammates or anyone else who clone/fork your code can have access without any knowledge on what are the secrets values.

You only need to manage ACL via AWS IAM.

And so, for instance, your seniors developers can have access through their IAM roles and create/edit/update/delete new secrets, and interns can't.

Usage

For every AWS Cloud based infrastructure, all you need to do is to grant access to the secrets.

Our MicroServices infrastructure is built on Serverless lambdas functions, so we just have to add the rights IAM roles to our lambdas.

Also, you can easily split them by environments.

provider:
  name: aws
  runtime: nodejs10.x
  stage: ${opt:stage, 'dev'}
  region: eu-west-1

  iamRoleStatements:
    # Role for using AWS Secret Manager
    - Effect: "Allow"
      Action:
        - "secretsmanager:GetSecretValue"
      Resource: 
        - ${self:custom.jarvisAdminPassword.${self:provider.stage}}

  environment:
    JARVIS_ADMIN_PASSWORD: ${self:custom.jarvisAdminPassword.${self:provider.stage}}

custom:
  stage: "${opt:stage, self:provider.stage}"

  jarvisAdminPassword:
    local: "local_jarvis_admin_password_secrets_key"
    dev: "dev_jarvis_admin_password_secrets_key"
    staging: "staging_jarvis_admin_password_secrets_key"
    prod: "prod_jarvis_admin_password_secrets_key"
Enter fullscreen mode Exit fullscreen mode

An extra cool thing about secrets: if you need to update your database accesses, an API key or any secret value you can just update the secret value into your Secret Manager, and every services that are using it will be automatically updated :)

Hope it helps !

Top comments (8)

Collapse
 
sebbdk profile image
Sebastian Vargr

Dunno, so far I’ve always just had default configs, a developer would have their own keys from running the services they would need on their computer.

For third party services, they would get personal keys to a copy of the environment there, preferably through the third party services team system.

Sure it takes a bit of setup, but it also keeps the devs miles away from anything related to production.

Collapse
 
dvddpl profile image
Info Comment hidden by post author - thread only accessible via permalink
Davide de Paolis • Edited

nice post!
( it kinda reminds me my own post from last year ;-) but at some point, every engineer has gone through these steps, and everyone loves such gifs - so i believe it can happen to have some content overlapping.

Collapse
 
patzistar profile image
Patrick Schadler

For Microsoft Azure guys have a look at their Key Vault Service. It basically does the same and you can grant your app services access to the key vault in the portal as well.

Collapse
 
monisnapjonathan profile image
Jonathan BROSSARD

Hi @patzistar . Great, good to know, thanks for sharing !

Collapse
 
patzistar profile image
Patrick Schadler

No problem, I have seen many people storing sensitive information in public repositories. So, we can mention those services enough I guess.

Thread Thread
 
monisnapjonathan profile image
Jonathan BROSSARD

Fully agreed

Collapse
 
visualmov profile image
Ryan

I just wrote up a routine to read my API keys from a file that I don't stage.

Collapse
 
miniscruff profile image
miniscruff

Wait, you forgot my favorite method. Using the same bad password across everything and in plain text.

Some comments have been hidden by the post's author - find out more