👋 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?
- Previous setup using Consul
- Problems with the old setup
- Using secrets manager to solve the problems
If you're not familiar with a configuration server, it's basically a service which is used to keep configuration data needed in applications. We keep different configuration servers for different environments. A staging server where staging configuration data would be stored and similarly a production server. 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.
Now there are multiple ways to store data depending on the service we'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.
- Our micro services which are orchestrated using Docker would pull the configuration json data and keep it in the docker image that is built and use it on the runtime.
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.
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.
- 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 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 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 config data should be stored for different environments. 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.