Portshift Simplifies Kubernetes Security Management
Portshift this week added a tool that makes it simpler to manage pod security policies (PSPs) that are embedded within distributions of Kubernetes.
Zohar Kaufman, vice president of research and development for Portshift, says that while PSPs make certain that only pods that comply with policies are allowed to run, managing PSPs is a significant challenge for the average IT administrator to set up and manage.
The Portshift implementation allows IT teams to centralize PSP management without having to deploy a software agent in the form for a daemonset on all Kubernetes nodes, says Kaufman. Administrators can configure desired security settings from predefined PSP profiles or use their home-grown profiles.
The Portshift approach to PSP also makes it possible for administrators to configure and apply more granular policies on a per-pod basis based on risk levels, adds Kaufman. Those policies can be implemented independently of the role-based access control (RBAC) mechanism in Kubernetes and any service account granularity limitation, including issues such as overlapping policy conflicts and the inability to apply granular security controls across multiple Kubernetes clusters at scale.
The arrival of the PSP tools comes on the heels of the release of five best cybersecurity practices for Kubernetes environments as defined by Portshift. Those best practices include:
1. Authorization: Kubernetes offers several authorization methods which are not mutually exclusive. It is recommended to use RBAC for authorization policies controlling how the Kubernetes API is accessed using permissions. ABAC is an additional authorization mechanism that provides powerful and fine-grained policies, but it’s more complex and has few operational constraints.
2. Pod Security: Because each pod contains a set of one or more containers, it is essential to control their deployment configurations. Kubernetes Pod Security Policies are cluster-level resources that allow users to deploy their pods securely by controlling their privileges, volumes access and classical Linux security options such as seccomp and SELinux profiles.
3. Secure the Production Environment: As companies move more deployments into production, that migration increases the volume of vulnerable workloads at runtime. Organizations should embrace DevSecOps processes to minimize those risks.
4. Securing Continuous Integration/Continuous Delivery (CI/CD) Pipelines on Kubernetes: Security needs to be baked at the CI/CD process to allow developers to quickly discover and mitigate potential vulnerabilities and misconfigurations by allows for the inspection of images and deployment configurations at the CI/CD stage can achieve this purpose.
5. Add Service Mesh to the Network Security Layer: A service mesh addresses common tasks associated with managing and securing microservices in a unified and agnostic manner using policies. A service mesh automatically balances inter-service traffic using a zero-trust security model.
Most organizations are working through the implementation of best DevSecOps processes that in many ways is being forced by the adoption of Kubernetes. The challenge they face is first securing Kubernetes and then all the endpoints of a containerized application that consist of hundreds of microservices all with their own application programming interfaces (APIs). Given all that complexity, developers are naturally playing a larger role in implementing cybersecurity policies. However, it’s still the responsibility of the cybersecurity team to define those policies and, just as importantly, verified they have been implemented.
