Using Kubernetes Persistent Volume for Data Protection

9/25/2018

To resolve a few issues we are running into with docker and running multiple instances of some services, we need to be able to share values between running instances of the same docker image. The original solution I found was to create a storage account in Azure (where we are running our kubernetes instance that houses the containers) and a Key Vault in Azure, accessing both via the well defined APIs that microsoft has provided for Data Protection (detailed here).

Our architect instead wants to use Kubernetes Persitsent Volumes, but he has not provided information on how to accomplish this (he just wants to save money on the azure subscription by not having an additional storage account or key storage). I'm very new to kubernetes and have no real idea how to accomplish this, and my searches so far have not come up with much usefulness.

Is there an extension method that should be used for Persistent Volumes? Would this just act like a shared file location and be accessible with the PersistKeysToFileSystem API for Data Protection? Any resources that you could point me to would be greatly appreciated.

-- Marshall Tigerus
asp.net-core
data-protection
kubernetes

1 Answer

9/25/2018

A PersistentVolume with Kubernetes in Azure will not give you the same exact functionality as Key Vault in Azure.

PesistentVolume:

  • Store locally on a mounted volume on a server
  • Volume can be encrypted
  • Volume moves with the pod.
    • If the pod starts on a different server, the volume moves.
  • Accessing volume from other pods is not that easy.
  • You can control performance by assigning guaranteed IOPs to the volume (from the cloud provider)

Key Vault:

  • Store keys in a centralized location managed by Azure
  • Data is encrypted at rest and in transit.
  • You rely on a remote API rather than a local file system.
  • There might be a performance hit by going to an external service
    • I assume this not to be a major problem in Azure.
  • Kubernetes pods can access the service from anywhere as long as they have network connectivity to the service.
  • Less maintenance time, since it's already maintained by Azure.
-- Rico
Source: StackOverflow