Product documentation
Citrix SecurSpaces™
View PDF

Configure SecurSpaces for AWS Mount Points

August 18, 2026
Contributed by: 
T

Complete the AWS preparation first. The steps here depend on a file system, its mount targets, and the IAM roles already existing.

Create the StorageClass

You author the StorageClass by hand, one per backing file system. SecurSpaces ships none and creates none. A missing StorageClass is the most common cause of an empty create dialog.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sn-efs-mountpoint
provisioner: efs.csi.aws.com
mountOptions:
  - tls
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0abc123
  basePath: "/dyn"
  directoryPerms: "700"
  gidRangeStart: "50000"
  gidRangeEnd: "51000"
reclaimPolicy: Delete
volumeBindingMode: Immediate
<!--NeedCopy-->

Required values:

  • provisioner: efs.csi.aws.com for both backends.
  • parameters.provisioningMode — efs-ap for Amazon EFS, s3files-ap for Amazon S3 Files. This parameter, not any option in the interface, selects the backend. Users choose the backend by choosing the StorageClass, so give each class a clear name.
  • parameters.fileSystemId — the id of the file system you created.
  • mountOptions: [tls] — a top-level list, a sibling of parameters, not a key inside it.
  • volumeBindingMode: Immediate — EFS and S3 Files are zoneless. A class set to WaitForFirstConsumer can never bind and the create is rejected.

Optional values include basePath, subPathPattern, directoryPerms, and the pair gidRangeStart and gidRangeEnd, which bound the POSIX group id the access point enforces. Set both or neither. Keep a custom range wide enough for every Mount Point planned on that file system, because each access point consumes one group id.

One file system and one StorageClass serve many Mount Points. Add more only when you exceed the access point ceiling, need throughput isolation, or need hard tenant isolation.

Encryption in transit

EFS and S3 Files are mounted over NFS on port 2049, and the CSI driver only encrypts that traffic when the mount carries the tls option. Set it on the StorageClass and on every PersistentVolume you author. Without it, every byte read or written travels unencrypted.

SecurSpaces keys strictly on the literal tls mount option. It does not accept parameters.encryptInTransit, a TLS-enabled access point, or an EFS file system policy that enforces SecureTransport as substitutes.

How strictly this is enforced differs by mode:

  • Attach Existing fails closed. At bind time SecurSpaces reads the volume you named and refuses the attach unless it is an efs.csi.aws.com volume whose mount options contain tls.
  • Create New is best-effort. A StorageClass without tls is normally hidden from the Create New list, and naming it anyway is rejected. All of these checks depend on reading the StorageClass from the Kubernetes API.

Warning

The StorageClass read is made by the workspace service. If it cannot read StorageClasses, every Create New encryption check is skipped, a StorageClass without tls becomes usable, and the mount runs unencrypted with no error. This is the one failure in this article that fails in the permissive direction.

The grant is a ClusterRole, because StorageClasses are cluster-scoped. Two Helm settings remove it: platform.serviceKubernetesConfig.rbac.createWorkspaceClusterRoles: false prevents the ClusterRole from being created, and setting platform.serviceKubernetesConfig.serviceAccounts.wsAPIServiceAccount to your own service account means the chart installs none of the workspace service RBAC objects. In that case you must create the equivalent permissions yourself.

Verify both verbs. Kubernetes list does not imply get:

kubectl auth can-i get storageclasses --as=system:serviceaccount:<namespace>:<release>-workspace-api
kubectl auth can-i list storageclasses --as=system:serviceaccount:<namespace>:<release>-workspace-api
<!--NeedCopy-->

Missing get skips the encryption checks and allows an unencrypted mount. Missing list breaks discovery entirely: the create list is empty and the feature disappears.

Enable the feature

Mount Point Storage is enabled at System Configuration > Integrations > Mount Point Storage. System Configuration is an administrator-only area. A security officer who is not also an administrator cannot enable it.

  • The cloud provider is detected, not chosen. SecurSpaces derives whether Mount Points are backed by AWS or Azure from the CSI provisioners of the StorageClasses on the cluster. To expose the AWS options, create AWS Mount Point StorageClasses first.
  • Turn on the file storage switch. While it is off, the create flow is hidden from users.
  • Use one cloud per cluster. If both an AWS and an Azure Mount Point StorageClass are present, the provider cannot be resolved, the switches are forced off, and the feature is withdrawn. The page explains this and lists the providers it detected. Remove one cloud’s classes and revisit the page. No restart is needed, but allow about 30 seconds for the configuration cache.
  • allowPersistentVolumeAccess governs one attach mode. The mode in which a user types raw coordinates and SecurSpaces builds the volume requires platform.serviceKubernetesConfig.rbac.allowPersistentVolumeAccess, which defaults to false. While it is off, that mode is hidden, but attaching a volume you authored and creating new Mount Points both still work. The change takes effect when helm upgrade completes, with no pod restart.

Note

Only this page explains why Mount Points are unavailable. In the project and workspace views the option is simply hidden. Triage any report of missing Mount Points by opening this page first.

Next

Configure SecurSpaces for AWS Mount Points
August 18, 2026
Contributed by: 
T
August 18, 2026
Contributed by: 
T

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.