Working with Kubernetes namespaces enables you to manage users spread across multiple teams and projects. Namespaces are essentially virtual clusters backed by the same physical single cluster. As Kubernetes clusters help in managing workloads and deployed objects, these numbers increase and can become unmanageable over time.
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.
Vulnerability Description and Impact
Automate Kubernetes Analytics and Forensics with Alcide kAudit
Last month, the Microsoft Azure Security Center published a fully detailed Threat Matrix for Kubernetes. This article identifies attack vectors unique to a Kubernetes environment. This important contribution is derived from the more generalized MITRE ATT&CK® framework that offers a complex matrix of common attack vectors.
What is Pod Security Policy?
The Pod Security Policy, sometimes called PSP in short, is a Kubernetes resource that allows the enforcement of policy rules during the creation phase of a Pod.
When a PodSecurityPolicy resource is created, it does nothing. In order to use it, the requesting user or target pod’s service account must be authorized to use the policy, by allowing the use verb on the policy.
While a lot of people are calling network policies the Kubernetes equivalent of a firewall, they probably wouldn’t be called network policies if that were really the case. Although network policies are comparable to security features like firewalls, they mostly pertain to rules, and therefore a more accurate comparison would be with “firewall rules” or security groups in the Cloud that are used to manage permissions.