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.