nvmeof: CSI Driver TLS/PSK Feature Implementation

[gadididi]

Describe the feature you'd like to have

[WIP]

Add TLS/PSK (Pre-Shared Key) authentication support for NVMe-oF connections in the CSI driver, enabling encrypted communication between Kubernetes nodes and Ceph NVMe-oF gateways.
This is a requirement from PM.

What is the value to the end user? (why is it a priority?)

Security Benefits:

• Encryption in Transit: All storage traffic between nodes and gateways is encrypted using TLS 1.3, protecting against network sniffing
• Authentication: Ensures only authorized nodes can connect to storage subsystems, preventing unauthorized access

How will we know we have a good solution? (acceptance criteria)

• StorageClass parameter enableTLS: "true" activates TLS/PSK for volumes
• PSK keys are auto-generated using cryptographically secure random generation
• Keys are stored in Kubernetes Secrets, never in logs or volume metadata
• Each volume-node pair gets a unique PSK for granular access control

The Solution Architecture:

1. Key Generation: When a volume is attached to a node, the CSI controller generates a unique 256-bit random PSK key

2. Secure Distribution:

   • Controller stores PSK in a Kubernetes Secret (encrypted by K8s)
   • Configures the Ceph gateway to accept this PSK for the specific host
   • Passes only the secret reference (not the key) to the node

3. Protected Connection:

   • Node CSI plugin retrieves PSK from K8s Secret (over encrypted API)
   • Uses PSK with nvme connect --tls to establish encrypted connection
   • All subsequent I/O is encrypted with TLS 1.3

Add any other context or screenshots about the feature request here.

In fact, the changes will be in 2 places:

1. In the controller, where adding host. We will generate PSK key if

enableTLS: "true"              # Enable TLS/PSK authentication

in storageClass was provided. We need to attach the psk key in AddHost GRPC call as another parameter. Then save it in k8s secret encrypted.

2. In Nodeserver, where nvme connect command is executed, if PSK\TLS key is provided, add it as another parameter.

The Flow:

NOTE:

1. By using psk, the listener must be created with --secrure option.
2. the host that runs the nvme commands must be at least redhat version 9.6 with nvme tool at least version 2.11
3. the NVMe-oF GW must deploy with encryption_key option (in the spec file)

[nixpanic]

The workflow looks good to me. But there is one issue with the approach. CSI-drivers can not assume Kubernetes is used, so storing the PSK in a Kubernetes Secret is not really an option (and there would be one Secret per volume, and that can be many).

It would be cleaner if the PSK can be stored in the rbd-image metadata (or related omap maintained by ceph-csi). That suggests requiring encrypted Ceph connections (msgr v2).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation.