Kubernetes keeps transforming the way we think about modern application architecture, as it keeps its status as the flagship orchestrator for containerized workloads and services.
The month of October is well recognized as the National Cyber Security Awareness Month.
Here at Alcide, we leverage the hype around Cyber Security and share our take on how to protect your Cyberspace, specifically with Kubernetes.
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.
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.
Alcide Logs and Coralogix
Ingress APIs manage external access to the services in a cluster, typically HTTP. This would generally be implemented as an API Gateway style of traffic routers that relay traffic to proxied services through a common entry point. The user would be left to control when and how to publish a service by using a declarative definition of the desired behavior (with YAML/JSON file).