10. Security Recommendations

10.1. Run Trident in its own namespace

It is important to prevent applications, application admins, users, and management applications from accessing Trident object definitions or the pods to ensure reliable storage and block potential malicious activity. To separate out the other applications and users from Trident, always install Trident in its own Kubernetes namespace. In our Installing Trident docs we call this namespace trident. Putting Trident in its own namespace assures that only the Kubernetes administrative personnel have access to the Trident pod and the artifacts (such as backend and CHAP secrets if applicable) stored in the namespaced CRD objects. Allow only administrators access to the Trident namespace and thus access to tridentctl application.

10.2. CHAP authentication

Trident supports CHAP-based authentication for HCI/SolidFire backends and ONTAP SAN workloads (using the ontap-san and ontap-san-economy drivers). NetApp recommends using bidirectional CHAP with Trident for authentication between a host and the storage backend.

10.2.1. CHAP with ONTAP SAN backends

For ONTAP backends that use the SAN storage drivers, Trident can set up bidirectional CHAP and manage CHAP usernames and secrets through tridentctl. Refer to Using CHAP with ONTAP SAN drivers to understand how Trident configures CHAP on ONTAP backends.

Note

CHAP support for ONTAP backends is available with Trident 20.04 and above.

10.2.2. CHAP with HCI/SolidFire backends

Note

For HCI/SolidFire backends, CSI Trident will use CHAP to authenticate connections. The volumes that are created by CSI Trident will not be associated with any Volume Access Group.

NetApp recommends deploying bi-directional CHAP to ensure authentication between a host and the HCI/SolidFire backend. Trident uses a secret object that includes two CHAP passwords per tenant. When Trident is installed as a CSI Provisioner, it manages the CHAP secrets and stores them in a tridentvolume CR object for the respective PV. When a PV is created, CSI Trident uses the CHAP secrets to initiate an iSCSI session and communicate with the HCI/SolidFire system over CHAP.

In the non-CSI frontend, the attachment of volumes as devices on the worker nodes is handled by Kubernetes. Upon volume creation time, Trident makes an API call to the HCI/SolidFire system to retrieve the secrets if the secret for that tenant doesn’t already exist. Trident then passes the secrets on to Kubernetes. The kubelet located on each node accesses the secrets via the Kubernetes API and uses them to run/enable CHAP between each node accessing the volume and the HCI/SolidFire system where the volumes are located.