A while ago, I was searching for a tool that could offer a vault for credentials like 1Password or Bitwarden, and the possibility to get the secrets via an API. And most important, it must be open source and the main features that I need should not have limits by the open-source version.
After a couple of days of search, Infisical was my tool of choice. I was desperate to find a vault that I could use at work. We have tons of secrets that we require for day-to-day development, and we didn’t have a place to keep them safe.
Infisical checks most of those boxes, and the open-source version does not limit you on the use of the tool. This is a considerable point for me, since most of the open-source tools that are available to use, it’s almost useless on the open-source version. And I think that it should not be. The open-source version of a software should work smoothly, and only have some points of “ooo would be nice to have this” on the premium version where you see more value on paying the license.
Think about the MoSCoW prioritization method. The M stands for Must Have. So the open-source version should have all the tools that fit’s the M class. The S(Should have) and C(Could have) could fit on the Enterprise version of the software. Otherwise, you have an open-source version of a useless software.
If I like your software, and if I have the budget, I would totally buy the license. But if your open-source version limits me so much, I won’t buy your enterprise license just because. I rather build a tool myself.
This is the POV of a Software Engineer, and you know how we like to reinvent the wheel just because we can.
Terraform and Infisical
Now, back to Infisical.
They offer a couple of ways to set up your instance, with a Kubernetes Helm Chart, and via Docker-Compose. Checking its latest docs, the tutorial that I’ve seen in the past on how to start your Infisical instance on AWS is not there anymore. However, if I recall it correctly, it was based on an EC2 instance where the Docker-Compose would start.
But, since we don’t run software in bare-metal anymore, unless really needed, I used the stack of Terraform + ECS and RDS to set up the Infisical on Fargate.
The Terraform module can be found at my GitHub, and I’ll make it available to the Terraform Registry. Right now, you can use it by importing directly from the source code:
There’s not much that you need to set up to have your Infisical up and running. Firstly, on the networking block you need to pass the VPC ID, the subnets that you want to deploy, and the ARN and security group of an already existent load balancer. Secondly, on the DNS block, you have to pass the route53 zone id created to serve the application. Finally, you pass on the ECS block the ECS cluster ARN where the service will be deployed and the Infisical image that it’s going to be used.
Previously the Infisical persistence was based in a MongoDB instance, now it’s a Postgres one. So make sure that the image that you are passing in this block is one that is Postgres based.
Also, on the first run, it’s needed to set the variable `run_infisical_migrations` to True, so the database can be properly configured, after you check on the CloudWatch logs of the task that the migrations were run, you can set it to false, and the Infisical instance may start properly.
More settings of this module you can find reading the variables.tf file.
After your `terraform plan` and `apply` commands, you should have an up and running instance of Infisical.
Notes
There is a group of choices made at the development of this module that you should realize before using it:
The use of Aurora Serverless: Since, at this point, I’m not using Infisical for a production environment, and cost matters, I’m using a Serverless instance of Postgres. It could be added to the module the possibility to use a normal RDS instance, to allow for more intense workloads.
The Redis runs in the same task definition of Infisical: I don’t know the impact of this on a production workload, however, the module could also be extended to use an AWS Elastic Cache instance if needed.
The Postgres user for the application is the master one: I believe that using the master user is the best way to go, but it is what we have right now. It would be wonderful to use IAM authentication for Aurora services. But even with that way, or creating a new user, it would require some manual steps that I didn’t take at this point. You can check my blog posts about RDS management here:
So, for a proof of concept, this Terraform module should deliver you what you require.
You are welcome to contribute with the Terraform module. Please let me know in the comments how was your experience using this module and Infisical.
That’s all folks!