👋 Hi. I'm Sunil.

I work at a startup during the day and as an indie developer at night.

In this article I'm going to talk about why we started using AWS Secrets Manager to manage sensitive data like passwords, keys, tokens etc used in our applications.

This is what is covered in this article:

• What the hell are you talking about?
• What did our previous setup look like?
• Problems with the old setup
• How did we use secrets manager to solve the problems?
  
  

What the hell are you talking about?

If you're not familiar with a configuration server, it's basically a service which is used to keep configuration data needed in applications. If you are wondering what configuration data is, it can be any data which is needed to run applications and is different for different environments like staging and production. For example: If you're using stripe to charge your customers, you'll need too use different keys for staging and production environments.

We keep different configuration servers for different environments. A staging server where staging configuration data would be stored and similarly a production server for prod configuration data. On the runtime applications would pull this data from these servers and use them.

The next question is how can we input this data to a configuration server?

What did our previous setup look like?

There are multiple ways to store configuration data depending on the service you're using. In our case it is Consul and this is how we use it:

• We store configuration data for each service as a json file in staging and prod branches of a Github repository for respective environments.
• Every time we make changes to this repository, we run a Jenkins job to update the data on Consul server.
• Our micro services which are orchestrated using Docker would pull the configuration data and keep it in their docker images that are built and then use it on the runtime.
  

Problems with the old setup:

There are many problems with storing sensitive data as part of code in a Github repository.

• It is not the right way to keep sensitive data as part of your code on Github even if it's a private one.
• It is not secure. If hackers get access to your Github account, all your secrets would be compromised.
  

How did we use Secrets Manager to solve the problems?

There are many applications which provide encrypt / decrypt services to store sensitive data. The idea here is that we provide data in plain format. The service then encrypts the data using a key. When you request for this data, the service then decrypts this data and sends you back in the plain format. There are many details involved in this process like encrypt / decrypt algorithm used, access to read and write data from services, limiting the access to specific keys etc. But these are out of the scope of this blog.

AWS Secrets Manager is one of them and works well with the AWS ecosystem of services.

This is what we did to solve the problems discussed above:

• Removed sensitive configuration data from our private Github repositories.
• Used KMS and Secrets Manager to store sensitive data. Here we manually add the data one by one on the AWS console after we login.
• Provided access to our applications / micro services through policies and attaching them to ecs task roles to read data stored in Secrets Manager.
• Updated Dockerfile and consul template files of our services to pull the data stored in Secrets Manager when building docker image.
• Note that we still store all the other non sensitive data in a Consul server. When we build docker images we pull data from both Consul and AWS Secrets Manager and merge them and use.
• Our micro services now read sensitive data from AWS Secrets Manager instead of from a consul server. And there are no worries of someone hacking our data as AWS ensures keeping this data secret and encrypted.

I hope this article has given some insights into how sensitive data should be stored and accessed during the lifecycle of an application.

I've left out many details involved in each step on purpose. Let me know in comments if some parts are not explained clearly. I would be happy to answer your questions 🙂

---

If you're a beginner to cloud computing and want to learn AWS concepts, here's a great course by Daniel Vassallo who has worked in Amazon AWS team for 10+ years.

I highly recommend buying this course if you think documentations are overwhelming.

Here is the link if someone is interested.

Connect with me on twitter where I usually share my knowledge on AWS concepts, building SaaS products, JavaScript, HTML/CSS tips and programming in general.