Author: Omer Rokach, Senior Product Manager, Tenable
Bio: Omer Rokach is a Senior Product Manager at Tenable Cloud Security. Omer is responsible for the KSPM and Just-In-Time Access products. Omer joined Tenable as part of the Ermetic acquisition. Before Ermetic, Omer was a Product Manager at Salesforce, where he worked on products such as Slack, Marketing Cloud Intelligence, and Salesforce Data Cloud.

In Kubernetes, many organizations use stateful persistent volumes to provide stable storage for certain applications, such as databases. These databases tend to hold critical customer data and are high-value targets for hackers, so it’s important to understand how to secure them with cloud-native tooling.

Unlike in stateless applications, the user state must be preserved across Kubernetes pods and data requests, even when the pods that use the volumes are terminated or moved to a different node in the cluster.

Using stateful persistent volumes in Kubernetes to store data has security implications that need to be considered to ensure the safety and confidentiality of sensitive data. In addition to securing the data, organizations must ensure the cloud architecture around those volumes is up to snuff.

What are stateful persistent volumes?

Unlike volumes attached to containers used to store applications and their data, persistent volumes survive much longer. They persist after application containers are destroyed so information can continue to be used and collected. Think of product data and customer orders. That data is critical for long-running applications – even if the applications themselves come and go.

Here are some useful points to understand and consider:

• Persistent storage outlives the lifecycle of a Kubernetes pod. When a pod is deleted, the data stored in the volume remains intact and can be reused by a new pod.
• Stateful pods are deployed and scaled in a predictable order, which ensures each pod gets a unique hostname and network identity based on its ordinal index. This is essential for applications that rely on consistent naming conventions or need to manage distributed data consistently.
• Stateful volumes often require manual provisioning by a cluster administrator. While Kubernetes can automatically provision persistent volumes for stateless applications using PersistentVolumeClaims (PVCs), stateful volumes often require manual work because stateful applications have specific requirements for data preservation and consistency.

Securing these volumes provides some good lessons from the Shared Responsibility Model, which requires you, the customer, to do much of the work to secure applications and the data they collect and use.

Key Considerations for Persistent Volumes in Kubernetes

As you build out your Kubernetes applications and look to keep the data they use and collect secure, here are a few key considerations when using and securing persistent volumes

1. Access Control

Kubernetes is largely API-driven, so it’s important to implement strict access controls to clusters, pods and stateful persistent volumes to prevent unauthorized access. Kubernetes provides role-based access control (RBAC) so only authorized users or services have access to volumes. However, it’s your responsibility to ensure access is based on least privilege –  that is, no more and no less access than is strictly necessary. Establishing and implementing security policies that limit users – both humans and machines – is another preliminary step to tackle.

2. Pod Security + Identity

In addition to securing your Kubernetes clusters, you must also secure the pods that use the stateful persistent volumes. Kubernetes security contexts define privilege levels and access capabilities for pods. You must ensure that they’re not running with excessive privileges and that they have access only to the necessary resources. This is often done in the infrastructure-as-code (IaC) used to provision these systems, and can be spotted with Kubernetes Security Posture Management (KSPM) tools.

In addition, Identity is a critical aspect of Kubernetes, allowing microservices and related infrastructure to interact and deliver services. Default settings are not very restrictive, so you and your team must ensure that pods accessing your stateful persistent volumes have a proper identity. Kubernetes Service Accounts can be used to provide an identity to your pods. However, you must be deliberate when creating and assigning appropriate service accounts so that they always provide the minimum required permissions.

3. Container and Image Security

Many Kubernetes security vulnerabilities can be traced back to the container images themselves. Using unpatched operating systems and packages, providing excessive container and network privilege, and not verifying container images are just a few of the causes. You must ensure your container images are from trusted sources and don’t contain any vulnerabilities before they’re put in production. When new CVEs are published, you must be able to identify and patch them.

Wrapping it up

By thinking about and addressing these security considerations, you can enhance the overall security posture of your stateful persistent volumes and mitigate potential risks associated with data breaches, unauthorized access, and data loss. Of course, persistent volumes are just one piece of the Kubernetes security puzzle. Security in Kubernetes is an ongoing process, and regular security assessments and updates are essential to maintain a robust security posture.

###

Join me at KubeCon + CloudNativeCon Europe this March 19 – 22 in Paris and visit booth G17 to chat about addressing Kubernetes security in multi-cloud environments.