A question that I’ve been approached about several times recently is how to lookup multiple Hashicorp Vault Secrets and assign them to a single Ansible Tower Credential for use in a Playbook. A while ago I looked at the process of integrating Hashicorp Vault with Ansible Tower (a less that perfect process in the first place) but this has repeatedly led to the same question about multiple Secrets, so in . . .
Previously I’ve looked at how to lookup secrets from Hashicorp Vault using Ansible Tower however whilst that functionality is incredibly valuable it doesn’t really tackle the issue of how to write Playbooks which can interact with Vault. In this post we’ll look at how we can use some excellent lookup functionality provided as part of the ansible which provides this functionality. Some Assumptions For this article, I’m going to be . . .
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 . . .
EDITED: 07/2024. Please take a look at THIS ARTICLE for a follow up discussing the risks and nuances relating to using HTTPS Reverse Proxies. An HTTP reverse proxy may not be the right tool for your circumstances and using one carries certain risks. 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 of some . . .
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 . . .
Previously I’ve looked at Azure DevOps as a fantastic platform for deploying CI/CD pipelines, and it is, however it’s obvious inclination for Azure makes it something of an issue when trying to work on other public cloud providers, and Azure obviously isn’t the only game in town. There’s also the issue of complexity. Whilst Azure DevOps is incredibly flexible and powerful, this leads to complexity and we don’t always need . . .
In a complex Linux environment where multiple administrators have a requirement to manage countless machines (or even a small amount of machines), there is inevitably a requirement to manage SSH Private Keys, as well as the large administrative overhead that comes with cycling them when they expire, or new admins join or move teams. Vault offers us a method to remove the churn of key cycling. A fantastic feature of . . .
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 . . .