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

Jonathan BROSSARD — Fri, 24 Jan 2020 11:09:02 +0000

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"

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 !

Bye bye Postman ! Let's share your REST API calls in team, easily !

Jonathan BROSSARD — Fri, 10 Jan 2020 10:56:48 +0000

As developer, we are using tools to make REST API calls (Postman, Insomnia, PostWoman...), and these tools are very usefull.

The limits

Make calls to test an API is fine, but if you want to edit, version, or simply share it with your team ... it's not very handy.

Indeed, you can use Postman paid plans for instance, but it means that you need to pay, and it means that all your team needs to use Postman, again one more tool...

Do you know REST Client ?

REST Client* is a VS Code extension.

It will let you to send HTTP requests and view responses into VS Code. And only based on a text file, which can easily be versioned among your repository. 🙏

Pros

The main advantage is to be able to version and share your API calls.

If you're working on an internal API, you may want to share how to test a new endpoint with your colleagues.

REST Client is a good easy way to do it !

Another good point is simplicity. All you need to do/have, is ONE file. Also, if you jump between projects and do not remember how works an API/Service on which you did not work since a while, just look at this file !

Cons

You have to use VS Code... but for a lot of known reasons among internets, you are using Emacs, VI, or VS Code 😄

What's next ?

Here is how to begin.

The file

Only create a file with .http extension, for instance doc.http

And then, VS Code will show you the file as :

And by clicking on "Send Request", a new tab with all request response details will be opened.

Go further

You may also use environment variables to easily switch between you env and avoid any api-key or token manually update in the file, or url update etc...

Here is how to use environment variables, just like that :

Here, I created 4 environments : local, dev, staging, production.

These 4 environments have their own host and token variables, with their specific values.
But they also share a variable, named partnerUniqueToken (don't ask me why ... too many partners don't have several env...).