Ansible Vault isn’t, if I’m honest, a solution that I’ve ever found much use for in my day to day work. I prefer to use a centralised Secrets Management solution wherever it’s practical (particularly favouring Hashicorp Vault). These systems however are time consuming to properly deploy have a steep learning curve, depending on the scale of your deployments and integration requirements Ansible Vault might serve you just fine and I . . .
Recently I’ve been presented with the same question from a couple of readers so I’m going to run through it quickly. A while back I looked at integrating Azure KeyVault with Ansible Tower (a horribly documented scenario in my experience), but I didn’t really cover how to call multiple KeyVault Secrets and assign them to a single Ansible Tower Credential for use in a Playbook. Please take a look at . . .
In previous posts we’ve looked at how to look up Secrets from Hashicorp Vault using Ansible and Ansible Tower. We’ve also taken a look at how to integrate Azure Key Vault with Ansible Tower, however I’ve never gotten round to taking a look at how to integrate Ansible itself with Azure Key Vault (without the use of Tower). Whilst I’ve largley moved away from using Azure Key Vault in favour . . .
Recently I’ve spent a good amount of time looking at options for managing Kubernetes Secrets with Vault. Hashicorp being a great supporter of the Cloud Native philosophy, it’s little surprise to find that they provide a multitude of options to integrate with Kubernetes and provide extensive documentation here. for my needs I found that the suggested configurations were either unsuitable or required a degree of over-engineering so I’m going to . . .
UPDATED 11/2020: Have a look at a different method for this configuration better suited to CI/CD. In a previous post we looked at how to use Terraform provision and authenticate with Clusters using AWS’ Elastic Kubernetes Service (EKS) using the somewhat unique authentication method of it’s webhook token method leveraging aws-iam-authenticator. Once we get past that point however we still have another permission hurdle to overcome, specifically how we handle . . .
Recently I was presented with a very common problem, offer up a service which uses an unprivileged port, present that service through a reverse proxy and keep the entire service secure by completing TLS termination on the proxy. This is a pretty old problem and in my case the service is Hashicorp Vault, but what’s odd is that for such a popular platform I couldn’t find any guides or configuration . . .
Vault offers an array of flexible storage backends with a view to providing a highly available storage location to store secrets, this is a great baked-in design choice as if you make Vault an integral part of your infrastructure you can ill afford a sudden outage, a perfect platform for storing structured data is, of course, a RDBMS (Relational Database Management System), as many of the mainstays are scalable and . . .
In a previous post we’ve looked at how to build Azure infrastructure with Terraform, handle sensitive secrets by storing them within Vault and centrally manage states within Azure Object Storage (confusingly called Containers). In this post we’ll take a look at the same solution but leverage the same technology within AWS, making use of AWS S3 object storage platform and using Terraform to provision further AWS resources. Sample code for . . .
When working at scale with secret creation we can employ Vault’s Dynamic Secrets functions, however another less used and sometimes more flexible option is to leverage Terraform to create secrets at run time, allowing the injection of your secrets from pseudorandom secret generation in to Vault and then using these newly minted secrets further on in the creation process when creating resources in your cloud platform. Example code for this . . .
In a previous post we’ve looked at how to build Azure infrastructure with Terraform and handle sensitive secrets by storing them within Vault and looking them up at run time. This however still poses a problem if we’re using the default local backend for Terraform; particularly that these secrets will be stored in plain text in the resulting state files and in a local backend they will be absorbed in . . .