This is the 3rd part of an in-depth look at how companies running Kubernetes can approach implementing the recommendation of PCI’s guidance for container orchestration. The previous installment looked at authorization, and there’s also an overview post and some notes on the complexity of assessing security in Kubernetes which might be worth reading before getting in to this part. An index of the posts in this series can be found here.

This is the 2nd part of an in-depth look at how companies running Kubernetes can approach implementing the recommendation of PCI’s guidance for container orchestration. The previous installment looked at authentication, and there’s also an overview post and some notes on the complexity of assessing security in Kubernetes which might be worth reading before getting in to this part. An index of the posts in this series can be found here.

Having taken a high-level look at how the PCI guidance for container orchestration could apply to Kubernetes environments, and some of the challenges in auditing/assessing Kubernetes environments, I thought it would make sense to start getting into the details of the recommendations and see how in-scope organizations could look at meeting their requirements when using Kubernetes. Whilst this post is structured round the PCI recommendations, it would hopefully be helpful in general for Kubernetes security. An index of the posts in this series can be found here.

After talking about the release of PCIs recommendations for containers and container orchestration environments, and how it could be applied to Kubernetes clusters in my last blog I thought that it might be a good idea to discuss some of the general challenges that assessors and auditors might have when looking at Kubernetes environments, as there’s quite a few variables that you need to account for. This is part of a longer series on the PCI guidance for containers, and an index of the posts in this series can be found here.

Yesterday, the PCI Council issued a new information supplement that should be of specific interest to anyone using container technologies like Docker and podman and Container orchestration technologies like Kubernetes and OpenShift to process cardholder transactions.

Windows containers don’t get quite the use of their Linux brethren, but they’re an interesting topic and one that’s seeing more adopting as enterprises move to Containerization. Whilst, from a Docker/Kubernetes perspective, they look relatively similar to Linux containers, the underlying isolation mechanisms are entirely different. A new development in this is the provision of “host process” containers, so I thought it would be fun to take a look at what’s possible with them, but first some background…

I was doing some reading on the topic of Kubernetes RBAC this week and I realised that a good article on the topic of auditing RBAC by Mark Manning had unfortunately succumbed to bitrot (Although the wayback machine still has a copy), so I thought it would be a good opportunity to revisit the topic as there are some interesting nuances to it.

Capabilities are an interesting area of Linux security and one which has some application to containers. Whilst the details of how they work have been well documented (I’d recommend reading Adrian Mouat’s two part series here and here) I thought it was worth looking at a couple of neat tricks we can use do with file capabilities when using containers.

There’s been a couple of studies recently released by security research companies about exposed Kubernetes clusters on the Internet, and whilst it’s nice to see the security industry focusing a bit more on Kubernetes, some of the analysis misses some of the details of why Kubernetes clusters are exposed to the Internet and what some of the results mean, so I thought it would be a good opportunity to revist this topic, also as there have been some developments in what information can be found via Internet search engines.

There are lots of tools which we can use in the container ecosystem to easily create and test applications, but sometimes the networking they create can get a little complex, making it hard to work with and troubleshoot. I came across a scenario recently (for a workshop in Kubecon) where I needed to access a GUI application deployed in a KinD cluster running in an EC2 instance on AWS, from my laptop. The solution I came up with was to use Tailscale and as it seemed like a nice way to solve the problem, I thought it was worth documenting.