A while ago I wrote an article breaking down how to deploy Hashicorp Vault using NGINX as a reverse proxy. It has been a popular article but after it had been up for a couple of years I got some comments that my proposed method wasn’t recommended and that using an HTTP Reverse Proxy generally is insecure for a few reasons. I don’t like the idea of putting bad information . . .
If you’ve ever worked with AWS in the real world you are probably very used to seeing IAM Users and Roles which are terrifyingly over-permissioned. In my experience it’s pretty common to find them in the wild with access to every attribute of a specific service or just as often the native AdministratorAccess Managed Policy assigned. The principle of least privilege is a concept that you often hear about a . . .
Without a doubt the topic that seems to confuse people the most when using Ansible Tower is working with Credentials. Especially how to pass multiple credentials from either an external Secret Management source (which we’ve looked at a few times here) or just defining some arbitrary set of credentials and using them in a template. I get emails about this topic from readers on a fairly regular basis and professionally . . .
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 . . .
S3 seems to really rule the roost for cloud-based Object Storage and it’s not really a surprise given how flexible it is; often seeing use as hosting for static websites, storing bulk analytics or logs or providing the storage backend for applications amongst many other uses. As S3 content often needs to be presented to the public for anonymous access; the contents of a Bucket are not encrypted by default . . .
This article was going to be a look at how to configure IAM roles to work with EKS Service Accounts, however that topic is already well documented in the AWS docs right here. Whilst there’s nothing wrong with it in a technical sense, I can’t help find it a little clunky, using the AWS CLI and eksctl to get the job done. I’ve been pretty unattracted to eksctl (though it . . .
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 . . .
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 . . .