Enabling secure SMB in NetApp Trident

Balasubramaniam · ‎2025-07-23

In today’s data-driven world, secure access to shared resources is paramount. With the increasing adoption of containerized environments, NetApp^® Trident™ provides a robust solution for integrating storage into Kubernetes ecosystems. One of its key features is support for the SMB protocol, enabling seamless file sharing for Windows nodes. In this blog, we explore how to enable secure SMB in NetApp Trident so that your data remains protected.

Why secure SMB?

SMB is a widely used protocol for file sharing, giving users access to files, printers, and other resources on a network. However, without proper security measures, SMB can expose sensitive data to unauthorized access. Enabling secure SMB ensures:

Authentication. Validates user credentials.
Access control. Restricts access based on permissions.

NetApp Trident simplifies the integration of secure SMB into Kubernetes environments, making it easier for organizations to adopt secure practices.

Beginning with the 25.06 release, NetApp Trident supports secure provisioning of SMB volumes created using the ontap-nas and ontap-nas-economy back ends. When secure SMB is enabled, Trident configures access control lists (ACLs) to provide controlled access to SMB shares for selected Active Directory (AD) users and user groups.

Prerequisites

Before enabling secure SMB, follow these steps:

Configure NetApp ONTAP^®. Your ONTAP system should be running a supported version and have SMB enabled. Refer to NetApp ONTAP Documentation for details.
Set up Kubernetes cluster. A working Kubernetes cluster with at least one Windows node (required only for mounting the SMB volume; it is not mandatory for creating the SMB volume) and NetApp Trident installed. Follow the NetApp Trident Installation Guide to set up Trident.
Set up SMB. Prepare to provision SMB volumes:

Trident back end. Make sure that your Trident back end is configured to provision SMB volumes.
useREST in Trident back end. Secure SMB is compatible with both REST API and ZAPI. Therefore, it is not mandatory to set the useREST flag to true.
SMB credentials. Valid credentials for accessing SMB shares.

Enable secure SMB

Follow these steps to configure secure SMB in NetApp Trident.

Notes:

To enable secure SMB in NetApp Trident, Step 2, Adding the trident.netapp.io/smbShareAdUser annotation to the storage class, is mandatory.
Step 1 and Step 3 are optional and can be included based on the user’s requirements.
Trident backend configuration and storage class creation are one-time processes, provided that the same storage class is used to create the Persistent Volume Claim (PVC).

Step 1: Specify adAdminUser in TridentBackendConfig as shown in the following example:

The adAdminUser field is used to specify a user with an administrative role for the SMB volume's SMB share.
adAdminUser will have full_control to the SMB shares.

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: 10.x.x.x
  svm: svm0
  useREST: true
  defaults:
    adAdminUser: tridentADtest
  credentials:
    name: backend-tbc-ontap-invest-secret

Step 2: Add the annotation in the storage class:

Add the trident.netapp.io/smbShareAdUser annotation to the storage class to enable secure SMB without fail.
The user value specified for the annotation trident.netapp.io/smbShareAdUser should be the same as the username specified in the smbcreds secret.
You can choose one of the following for smbShareAdUserPermission: full_control, change, or read. The default permission is full_control.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-smb-sc
  annotations:
    trident.netapp.io/smbShareAdUserPermission: change
    trident.netapp.io/smbShareAdUser: tridentADuser
parameters:
  backendType: ontap-nas
  csi.storage.k8s.io/node-stage-secret-name: smbcreds
  csi.storage.k8s.io/node-stage-secret-namespace: trident
  trident.netapp.io/nasType: smb
provisioner: csi.trident.netapp.io
reclaimPolicy: Delete
volumeBindingMode: Immediate

Note:

When the configuration is complete (Step 2), the user can use trident.netapp.io/smbShareAccessControl PVC annotation and create PVCs to specify the users with different permissions. This step can be repeated as many times as needed; the permission priority will be PVC, storage class, and then Trident backend.

Step 3: Create a PVC.

The following example creates a PVC:

The PVC requests storage from the NetApp ONTAP back end via Trident, using the ontap-smb-sc storage class.
The trident.netapp.io/smbShareAccessControl annotation ensures that only specific AD users/groups have access to the SMB share, with defined permissions (full_control, change, or read). This is crucial for environments where secure access to shared storage is required.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: trident
  annotations:
    trident.netapp.io/snapshotDirectory: "true"
    trident.netapp.io/smbShareAccessControl: |
      full_control:
        - TridentADtest
      change:
        - tridentADuser
      read:
        - tridentADdev
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: ontap-smb-sc

Sample output of SMB share

Once the PVC is created, Trident creates an SMB volume in ONTAP with a new SMB share, where the user with the specified permissions is added to the access control lists, as shown in the following image.
The default share ACL Everyone/Full Control is removed when secure SMB is enabled, because it poses a security risk.

Points to remember

Secure SMB is supported for ontap-nas managed volume imports and is not applicable to unmanaged volume imports.
Importing ontap-nas-economy volumes is not supported.
Only read-only clones are supported for ontap-nas-economy volumes. Even if a user has full_control in the ACL, they cannot write to the read-only clone.
If Secure SMB is enabled, Trident ignores the SMB share mentioned in the back end and creates a new SMB share with the provided ACL.
Updating the PVC annotation, storage class annotation, and back-end field does not update the SMB share ACL.
The SMB share ACL specified in the annotation of the clone PVC takes precedence over those in the source PVC.
Be sure to provide valid AD users when enabling secure SMB. Invalid users will not be added to the ACL.
If you provide the same AD user in the back end, storage class, and PVC with different permissions, the permission priority will be PVC, storage class, and then back end.Trident supports SMB volumes mounted to pods running exclusively on Windows nodes.

Best practices for secure SMB

Regular updates. Keep your ONTAP and Trident versions up to date to take advantage of the latest security enhancements.
Strong credentials. Use complex passwords and rotate them regularly.
Access control. Restrict SMB access to authorized users and applications.
Monitoring. Enable logging and monitoring to detect and respond to unauthorized access attempts.

Conclusion

Enabling secure SMB in NetApp Trident is a straightforward process that significantly enhances the security of your containerized workloads. By following the steps outlined in this document, you authenticate your SMB shares and protect them from unauthorized access. NetApp Trident continues to evolve, making it easier for organizations to adopt secure storage practices in Kubernetes environments.

For more information, refer to the NetApp Trident Documentation or join the community discussions on NetApp Community.