To many, Kubernetes is a black box that’s difficult to understand, manage and secure. If you’re using stateful persistent volumes – cloud resources that live and manage data outside the scope of your pods – it can be even darker. 

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.

What are stateful persistent volumes?

Unlike volumes attached to containers that are 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.

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.

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. This 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.

Tenable Cloud Security can help you address many of these Kubernetes security challenges, because it’s a multi-cloud solution that enables you to scan code used to provision cloud resources, the cloud environment and everything in between. In our new white paper “The security implications of ‘stateful’ persistent volumes attached to Kubernetes pods and applications”, we outline 10 implications of using stateful persistent volumes and how to keep them secure.

These 10 points are particularly important when you consider the cloud’s shared responsibility model, which splits security responsibility between the cloud provider and you. Many of the basics are covered by cloud providers and Kubernetes, but your team is ultimately responsible for securing access, encrypting volumes, patching CVEs and much more. In Kubernetes and other cloud platforms, the default security settings aren’t very secure at all, leaving you with lots to manage.

For example, consider 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) to control access to resources 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. 

Tenable Cloud Security provides detailed insights into users, groups and permissions to help you lock down privilege. Establishing and implementing security policies that limit users – both humans and machines – is another preliminary step to tackle.

This is just one of the 10 takeaways from this whitepaper. Download it for free and read it today to see how Tenable Cloud Security can help you gain the visibility and insights you need to secure Kubernetes.