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 . . .
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 . . .
In the last post we looked at how to automate the creation of GKE Kubernetes clusters in GCP, however the deployment of workloads to these clusters was still something of a manual process. Enter Helm; a package manager for Kubernetes which allows us to use declarative configuration to push our cluster and container definitions from external repositories. If you’ve never heard of it, I recommend the IBM Cloud video here . . .
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 . . .
Terraform is great, it’s as simple as that, codifying complex infrastructure provisioning in to simple, readable configuration files, however there are some scenarios where you have bespoke requirements that you would like to do in a script that HCL just doesn’t offer (a problem that can plague many configuration languages and is slowly trying to be addressed as configuration languages mature more, as a side note check out Brendan Burn’s . . .
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 . . .