Getting your head around any new technology stack requires a lot of research and with that, you’re introduced to all the acronyms, terminology and how all its pieces fit together. The exact same happened to me when I started learning Kubernetes. One of the first questions I had, was “what’s the difference between a DaemonSet and a ReplicaSet?". A ReplicaSet is probably one of the first concepts that you’ll learn, cause it’s such an important part of what you can achieve with Kubernetes, but shouldn’t be confused with a DaemonSet; also a critical feature.

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.