Kubernetes use is rising rapidly: 58% more respondents than last year - 78% of this years’ respondents - reported in the 2019 CNCF (Cloud Native Computing Foundation) survey that they use Kubernetes today. With numbers like those, it looks like everyone is headed towards the cloud.
Whether you are on the cloud or still need to run your applications and workloads on-premise, Amazon Web Services (AWS) continues to innovate when it comes to supporting its devoted customers in any environment.
Traditional network security includes protection against layer2 and layer3 spoofing attacks. Many security teams don’t realize it, but these threats are still relevant when running applications on a Kubernetes cluster in the cloud. You might be using a complex container network, but that doesn’t mean that simple spoofing attacks between pods aren’t possible. This matters because it dramatically increases the blast radius of compromised pods.
Kubernetes namespaces - they’re an essential feature for building modern cloud architectures. Namespaces let you split up a single cluster into multiple “virtual clusters”. Resources like pods, replicasets, and deployments all live in namespaces. You can think of a namespace as being a resource’s last name - it specifies which family the resource is part of - and normal resources can have one and only one namespace (There are exceptions like the Node resource which is cluster-wide and doesn’t belong to any namespace). If you don’t think you’re using namespaces on your cluster then you’re wrong. You’re actually just putting everything into the default namespace.
A security issue was discovered in the kube-apiserver that could enable a privilege escalation from a compromised node.
Vulnerability Description and Impact
Automate Kubernetes Analytics and Forensics with Alcide kAudit