Chaos engineering is the discipline of experimenting on a software system in production to build confidence in the system’s capability to withstand turbulent and unexpected conditions. Essentially, we’re going to break things on purpose… The difference though; chaos engineering is traditionally done to better understand a distributed system, application or service, but I’m going to break my Kubernetes cluster, to better understand its inner workings and features. In my attempt to improve my skills of troubleshooting a Kubernetes cluster, I’ve written a little script (super basic for now) that randomly create a little bit (sometimes a lot) of chaos in my Kubernetes cluster, it’s then up to me to then go and fix.

It would seem that customers of public cloud providers are just loving life right now. And I would classify myself in the same group. We’re like kids in a candy store with the flexibility that goes along with “anything-as-a-service". We’re spinning up resources, building clusters, decoupling application functionality by adding load-balancers in-between - and all of this without the lengthy and expensive procurement process. With public clouds’ billing on a pay-as-you-go basis, reserved instances aside, this of course means that there are no upfront expenses to worry about, and companies (especially enterprises) are jumping for joy to convert their operational IT costs that the public cloud brings.

Project Description Kubernetes Security Series A series of posts focussed on security in the Kubernetes ecosystem

Kubernetes Default Service Account - What you need to know Kubernetes Security and Governance with Kyverno Policies Kubernetes: Restrictive Pod Security Policies Linux Host Security - SSH

Ever needed to give a user or a group of users permission to only control the EC2 instances that you want them to control? Of course, you have! Access control is a critical aspect of managing any environment. But, if managing IAM policies in your company’s AWS environment falls within your realm of responsibilities, this is something that should not be taken lightly. OK, so let’s say that your company has recently hired a bunch of interns to perform some application testing for you.

Post Updated: 2019-10-08 Description: Notification via SNS Topic We recently completed an audit of a customer’s AWS environment. I tend to either dive into the customer’s IAM policies as the first item on the list or I leave it for last. I find that the reason behind this, for me, is it depends on the complexity of the environment. At a high-level, it’s a fairly simple component (/service) to audit, so getting this out of the way first clears the ‘to-do’ list for the more complex stuff… And as for this recent audit, I worked through the customer’s IAM policies as the first item on the ever-growing to-do list.

I’m a massive believer in anything automated. I look back on my career, and I’m starting to think it is ingrained in me. I’ve been tinkering with Excel macros, when I was writing reports in my early career, then getting into SysAdmin I wrote simple monitoring scripts to check the output of commands on remote systems and send me an email with the results. Script patching updates, and automate the roll-out of applications.