Citrix SecurSpaces™

Prepare AWS storage for Mount Points

AWS Mount Points give a project shared, persistent, POSIX file storage that is mounted into its workspace pods at /mnt/<mount-point-name>. Every workspace that mounts it reads and writes the same files, live. It is collaborative shared storage, not per-user storage.

Two AWS backends are supported, both through the efs.csi.aws.com driver:

  • Amazon EFS — elastic NFS file storage.
  • Amazon S3 Files — a file system built on EFS over an S3 bucket. The same bytes are reachable as objects and as files.

Important

AWS Mount Points depend on AWS resources that Citrix SecurSpaces™ does not create and does not validate. Unlike Azure file storage, the EFS CSI driver cannot create a file system — it can only carve access points inside a file system that already exists. You must provision the file system, mount targets, security groups, IAM roles, and StorageClasses yourself before anyone can use the feature.

If these prerequisites are missing, the feature usually fails silently rather than reporting an error. An empty create dialog, a workspace that hangs while starting, or a mount that runs unencrypted are all symptoms of incomplete AWS preparation.

Priority checklist

Review these before your first deployment. Each one either breaks the feature or weakens data security.

Requirement What happens if you miss it
Set tls as a mount option on every StorageClass and every PersistentVolume you author. NFS traffic travels unencrypted over the VPC on port 2049.
Grant the workspace service read access to StorageClasses. The encryption check cannot run and is skipped, so an unencrypted mount can succeed.
Name an access point in volumeHandle. Never publish a bare file system id. The mount exposes every other project’s data on that file system.
Label every PersistentVolume you author with strong.network/mount-point-scope. An unlabeled volume is offered to nobody. A wrongly scoped one is offered to the wrong projects.
Set persistentVolumeReclaimPolicy: Retain on volumes you author. Deleting a Mount Point can destroy the underlying data.
Set storageClassName: "" on volumes you author. Kubernetes applies the default StorageClass and the static bind fails.
Create one mount target per Availability Zone your node group uses, and allow NFS on port 2049. Workspaces scheduled in an Availability Zone with no mount target hang while starting.
Create the file system with encryption at rest, and enable automatic backups. Data is stored unencrypted, and deletions are permanent and unrecoverable.
Use one cloud provider per cluster. Mixed AWS and Azure StorageClasses withdraw the feature from all users.

Warning

Do not rename the technical identifiers in this article to match the product name. The volume label key strong.network/mount-point-scope, the metric names, and the Helm value paths kept their original spelling deliberately. A renamed label makes the volume visible to nobody, with no error message.

How to use this section

Page What it covers
Prepare the AWS resources Mount targets, security groups, Amazon EFS and Amazon S3 Files prerequisites, IAM scoping, instance metadata hardening
Configure SecurSpaces The StorageClass, encryption in transit, and enabling the feature
Author a PersistentVolume Publishing your own volume for Attach Existing
Troubleshooting Symptoms, causes, and fixes
Mount point limits and behavior Quotas, deletion semantics, Amazon S3 Files behavior, multi-region, and metrics
Prepare AWS storage for Mount Points