Portshift this week plans to launch a framework that promises to make it easier to identify potential security threats to Kubernetes clusters.
Adapted from the ATT&CK cybersecurity framework created by MITRE, a non-profit that manages research centers on behalf of the U.S. government, K8SHIELD Framework defined by Portshift promises to improve the security posture in containerized application environments by making a knowledge base for threat modeling globally accessible. As part of that framework, IT teams are also provided with mitigation suggestions for each attack pattern identified.
In addition, Portshift is adding a risk analysis tool to its portfolio that can predict the threat potential of Kubernetes objects based on parameters such as security misconfigurations and overly permissive permissions. IT teams can also detect exposed dashboards that might provide inadvertent visibility into Kubernetes clusters.
Zohar Kaufman, vice president of research and development for Portshift, says the goal is to further adoption of best DevSecOps processes within Kubernetes environments. Those efforts should, for example, help minimize cryptomining manipulations of Kubernetes clusters by enabling IT teams to remain in control over individual Kubernetes pods.
The launch of the K8SHIELD Framework complements Portshift’s set of agentless tools that enables IT teams to secure both containers and the Kubernetes clusters they run via a centralized console.
Previously, Portshift has defined five best cybersecurity practices for Kubernetes environments:
1. Authorization: Kubernetes offers several authorization methods that 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, the volume of vulnerable workloads at runtime increases. 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 into the CI/CD process to allow developers to quickly discover and mitigate potential vulnerabilities and misconfigurations.
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 interservice traffic using a zero-trust security model.
In much the same way containers and Kubernetes have forced organizations to come to terms with DevOps processes to manage a highly dynamic IT environment, it’s now only a matter of time before IT teams managing Kubernetes environments come to terms with DevSecOps. The issue now is determining who in the organization will be defining and implementing those best DevSecOps processes.