[Feature-Request] TridentBackendConfig for ontap-sap to support mounting the secrets via volume and service account for AWS FSx NetApp ONTAP integrates with AWS Secrets Manager

[haofeif]

Describe the solution you'd like Hi, I am using Trident Operator on EKS to spin up AWS FSx NetApp ONTAP filesystem volume. In configuring the backend, i find out that using the TridentBackendConfig with ontap-san storageDriverName, I have to specify the secrets manually in the Kubernetes Secrets. However, the FSx NetApp ONTAP Filesystem credentials (Filesystem password and SVM password are stored in AWS Secrets Manager). The official AWS Secrets Store CSI supports mounting the secrets as volumes, and the service account. As specifying in the secrets itself does not seem to be a very secure way in the AWS ecosystem.

Here is the existing Yaml i configured to use my Trident backend

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-fsx-ontap-san
spec:
  version: 1
  backendName: fsx-ontap-san
  storageDriverName: ontap-san
  managementLIF: svm-XXXXXX.fsx.us-east-1.amazonaws.com
  dataLIF: 192.168.3.222
  svm: svm1
  credentials:
    name: backend-fsx-ontap-san-secret
---
apiVersion: v1
kind: Secret
metadata:
  name: backend-fsx-ontap-san-secret
type: Opaque
stringData:
  username: vsadmin
  password: password

Describe alternatives you've considered In order to leverage AWS Secrets Manager, AWS Secrets Store CSI and service account support is required for TridentBackendConfig. Wondering whether it can add the support for getting secrets via volumes and support service account ?

This is an example of Kubernetes deployment using the Secrets Store CSI:

kind: Service
apiVersion: v1
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      serviceAccountName: nginx-deployment-sa
      volumes:
      - name: secrets-store-inline
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: "nginx-deployment-aws-secrets"
      containers:
      - name: nginx-deployment
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets-store"
          readOnly: true

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

[andreas-theswede]

I agree with @haofeif trident need to support fetchin othe kinds of secrets such as secrets-store.csi.k8s.io, which will enable the usage of many different secrete providers such as AWS secret manager, azure key vault, hashicorp vault, google secret manger etc....

//Andreas

[andreas-theswede]

@haofeif We took the decision to use external-secrets.io until support for Secrets Store is available for Trident. Not but better than manual tasks.

//Andreas

[clintonk]

Trident 24.02 adds FSxN personality to the ONTAP drivers, including support for workload identity for AWS credentials and Secrets Manager support for the FSxN SVM credentials. It also fixes the incompatibility between Trident and FSxN volume backups.