In my recent posts I’ve covered the hardened setup of Vault and covered the basics of using the REST API. As we’ve seen so far, Vault is primarily designed for programmatic interactions from external systems via the API, so lets take a look a favourite of mine; Ansible Tower, which is a prime candidate as a third party system which often has a requirement to call secrets from external systems. . . .
In my last post I covered the setup and hardening of Hashicorp’s Vault platform, in this post I’ll be looking at getting to grips with REST API and the Token authentication method. Tokens are core to the Vault authentication system, the platform is at it’s heart designed to be interacted with programmatically by external systems over the API and the UI exists only to make the platform less bewildering for . . .
Recently I’ve been working with Hashicorp’s Vault, a product that I’d played with a little in the past but never really gotten stuck in to. Vault provides a centralised Secret Management platform, including some really cool features like IDAM, cross platform support, dynamic secret management and a fully fledged enterprise offering. It also boasts some pretty fantastic out of the box back-end integrations, Hashicorp’s own Consul is a big favourite, . . .
Since the release of Ansible 1.7, way back in the forgotten era of 2014, Ansible can connect to Windows (2008 and higher) using remote PowerShell over that most finicky of mechanisms, WinRM. Red Hat are quick to sell the unilateral management capabilities of Ansible (which do exist), but under the hood we see a uniquely Windows problem. Ansible was built for SSH initially and because Microsoft as ever adopt a . . .
Secure Shell might be the greatest component of Linux and the best gem to come from the Open Source community, enabling countless systems to connect to one-another and allowing the secure communication of systems both manually and programmatically with very little complexity, yet despite this people still appear to struggle with it, especially admins from a Windows background. Keys Vs Passwords There’s a significant downside to using a username and . . .
This project came from the back of my desire to learn more about public key certificates ahead of deploying a two tier PKI for an enterprise network, ahead of this I thought it would be prudent to try something a little smaller scale and see how the nuts and bolts worked and try and deploy a simple single tier PKI at home and see how it could be leveraged. Cryptography . . .
After seeing this configuration deployed in enterprise I struggled to understand how it worked, so I picked up a UniFi AC-AP access point second hand and set around seeing how to do it using open source platforms. Knowing that this required a certificate authority to work and RADIUS I figured I could eventually get it to work, but having never used RADIUS to any great degree it wasn’t without it’s . . .
Once upon a time I used to rely on nothing but a Secure Shell for access to my internal network, however this became more and more impractical the more things I stood up on the network and the more things I needed access to from my phone the less time I spent carrying a laptop with me. Given my long time favouritism for OpenVPN and how much the platform had . . .
My personal infrastructure has gone through a number of iterations. Starting as a 450mhz Pentium 3 Ubuntu 7.04 server running SMB on a single 5400 RPM IDE disk cobbled together through a BT home hub and some cheap megabit switches, it later became an Ubuntu 14.06 host on a laptop with a broken screen and gigabit switches, then a Pentium 4 desktop and then a lightweight Gigabyte Brix mini-PC before . . .
Netbox is an incredible tool and I’ll happily say I don’t know how I worked before I was introduced to it, scrabbling around in leviathan (non version controlled) spreadsheets and SharePoint pages that try to perform IP address management, or even worse the notes on a scrap of paper or book on someone’s desk. There are other tools on the market, but they cost an arm and a leg for . . .