PVCs and Stork with Authorization in AKS

Summary and Key concepts

Summary:

The article provides instructions on how to create secure volumes in a Portworx-enabled Kubernetes cluster using authorization tokens stored in Kubernetes Secrets. It explains how to use these tokens to create private Persistent Volume Claims (PVCs) by specifying the necessary annotations to reference the secrets. Additionally, the guide covers creating secure CSI volumes and using the same authorization model for volume snapshots managed by Stork. This ensures that private volumes are protected and accessible only with the appropriate authorization.

Kubernetes Concepts:

• PersistentVolumeClaim (PVC)
• Kubernetes Secret
• StorageClass
• VolumeSnapshot

Portworx Concepts:

• Portworx Authorization
• PX-Security
• Stork

Creating volumes

Portwox authorization provides a method of protection for creating volumes through Kubernetes. Users must provide a token when requesting volumes in order to create a private volume. These tokens must be saved in a Secret, normally in the same namespace as the PVC.

The key in the Secret which holds the token must be named auth-token.

Then the annotations of the PVC can be used to point to the secret holding the token. The following table shows the annotation keys used to point to the secret:

Name	Description
openstorage.io/auth-secret-name	Name of the secret which has the token
openstorage.io/auth-secret-namespace	Optional key which contains the namespace of the secret reference by auth-secret-name. If omitted, the namespace of the PVC will be used as default

Create a Secure PVC

1. Find or create your token secret:

   For operator installs, a user token is automatically created and refreshed under px-user-token in your StorageCluster namespace.

   USER_TOKEN=$(kubectl get secrets px-user-token -n <px-namespace> -o json | jq -r '.data["auth-token"]' | base64 -d)

   kubectl create secret generic px-user-token \
     -n <px-namespace> --from-literal=auth-token=$USER_TOKEN

2. Before creating pvc, make sure you've created a storageclass which can authenticate using the secrets. For example.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: portworx-sc
   provisioner: pxd.portworx.com
   parameters:
     repl: "1"
     csi.storage.k8s.io/provisioner-secret-name: px-user-token
     csi.storage.k8s.io/provisioner-secret-namespace: <px-namespace>
     csi.storage.k8s.io/node-publish-secret-name: px-user-token
     csi.storage.k8s.io/node-publish-secret-namespace: <px-namespace>
     csi.storage.k8s.io/controller-expand-secret-name: px-user-token
     csi.storage.k8s.io/controller-expand-secret-namespace: <px-namespace>
   allowVolumeExpansion: true

3. Create a PVC request, specifying your volume size, accessModes, and authorizations:

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: pvc-auth
     annotations:
       volume.beta.kubernetes.io/storage-class: portworx-sc
       openstorage.io/auth-secret-name: px-user-token
       openstorage.io/auth-secret-namespace: <px-namespace>
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 2Gi

For creation of secure CSI volumes, see Securing your CSI volumes.

Stork

When using CRDs consumed by Stork, you must use the same authorization model described above for the PVCs. Here is an example:

apiVersion: volumesnapshot.external-storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mysql-snap1
  annotations:
    openstorage.io/auth-secret-name: px-user-token
    openstorage.io/auth-secret-namespace: default
spec:
  persistentVolumeClaimName: mysql-data

Reference

For more information on Kubernetes Secret which holds the environment variables See Kubernetes Secrets