Since my first tentative steps in to Kubernetes it’s been an interesting journey. For the most part I suspect the most common way to interact with Kubernetes is to use a managed platform through one of the main public cloud players (that’s certainly been my experience), but it doesn’t do a lot to understand the nuts and bolts of the platform. I’d been meaning to try and get stuck in . . .
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 . . .
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 . . .
I’ve encountered this issue a couple of times in the last couple of weeks and it’s one that it seems unless you know the inside lore of how Linux works the actual solution isn’t exactly obvious and you can easily lead you to a disaster that seems like it should work and can actually leave you without a bootable system. While the fix is technically documented the actual method is . . .
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 . . .
Back in the forgotten age of December 2019, when people still walked the earth, I talked about the horrors of configuring the Dynamics 365 API, but at the time I was still pretty new to actually working with the API and little did I know it would get uglier the deeper you go and this problem compounds even deeper when we reach the point of trying to create custom integrations . . .
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 . . .
Even in 2020 (current year argument), it’s woeful how prevalent Brute Force Attacks are, what’s more worrying is how successful they are, whilst it might seem that the logical thing to do is just to harden password policies that’s not really the way the tide is turning and I’d remind anyone to remember Kerckhoffs’s principle of The Enemy Knows The System. What Is fail2ban? I’ve briefly discussed the use of . . .
After setting up a series of complex platforms, I needed a means of getting alerts to me should any of these fail. While a centralised platform such as Slack is normally better for operations teams, it doesn’t really work out that way for a home network and email will do the trick, but since I want things to be centralised I’ll need a mail server first. Since there’s no need . . .