In IT consultancy, balancing vendor-provided system with customer-specific requirements is a common challenge. This constant negotiation between adhering to predefined guidelines and accommodating unique client policies often demands creative solutions.
We encountered such a scenario while installing the SAS Viya platform (SAS Intelligent Decisioning as a product). SAS provides deployment guidelines and scripts for cloud services like AWS EKS and EFS, but its default integration with AWS Elastic File System (EFS) doesn't fully utilize the platform’s capabilities. Specifically, encryption-in-transit for EFS — an AWS supported feature — is not configured in SAS Viya's out-of-the-box deployment workflows.
However the customer’s policy required us to use EFS with both encryption at rest and in transit, prompting us to find a workaround.
Important Note:
Not every feature vendor doesn’t claim to support can actually be used. In our case, encryption-in-transit was feasible because it was managed at the infrastructure level, leaving the application itself unaffected. This approach ensured compliance with the client’s policy while preserving Viya’s operational abstraction layers.
NFS plays a critical role in the persistence layer of SAS applications, supporting both stateful and stateless components by providing necessary storage - whether for temporary disk space or long-term data retention. Since SAS applications rely on mounted volumes to meet these storage needs, understanding how NFS operates at the infrastructure level is key to enabling encryption in transit.
Kubernetes offers multiple ways to connect to an NFS server, including:
SAS typically relies on (1) and (3). However, since the only reliable way to enable EFS encryption-in-transit in Kubernetes is with AWS-provided CSI drivers, we aimed to replace (1) and (3) with (2).
So, grab a coffee, and let’s walk through the step-by-step implementation!
Key components underneath a neat picture are the following:
sas Storage Class enable SAS to interact with dynamically created folders in EFS.Several folder paths are used in SAS within EFS:
There are two primary categories:
Here’s an illustration of how these relationships work:
.png)
Before diving into the implementation, let’s clarify the difference between dynamic and static provisioning for Kubernetes and EFS.
In Kubernetes:
In EFS:
Terminology can be a bit tricky - what’s considered static provisioning in EFS may still be classified as dynamic in Kubernetes.
Here’s an example of static provisioning in EFS for the driver:
Key considerations:
mountOptions to ensure encryption-in-transit.ensureUniqueDirectory: "false" to prevent automatic folder creation inside the specified directory defined by the subPathPatternThis ensures static behavior in EFS terms.directoryPerms: "777" to allow multiple PODs — each potentially running under a different uid/gid — to operate within the same directory. This is critical for horizontal scalability, where multiple processes need concurrent access to EFS.Another essential aspect of the setup process involves properly defining the PVC’s (PersistentVolumeClaim) manifest:
The key parameter here is accessModes: ReadWriteMany which allows multiple pods to connect to the same PVC, making it easy to scale workloads that rely on shared storage.s accessModes: ReadWriteMany which allows multiple pods to connect to the same PVC, making it easy to scale workloads that rely on shared storage.
As for dynamic provisioning: only sas Storage Class utilizes it. Take a look at a typical dynamically provisioning Storage Class example:
Let’s break down some important aspects here:
uid/gid parameters - unlike static provisioning Storage Classes we don’t define these parameters in stone. They are assigned dynamically.basePath vs. subPathPattern. Instead of defining subdirectories with subPathPattern, the basePath parameter is utilized for folder definitions.reclaimPolicy: Delete. This setting ensures that used PVs are automatically removed when no longer in use.Here’s the schema we came up with for our set of SAS Viya products:
.png)
The concept stays consistent across other configurations.
The key takeaway? Understanding which connections are dynamic and which remain static is crucial for a smooth transition to the ****efs-csi-driver .
Before proceeding with Amazon EKS, ensure that the efs-csi-driver ****is installed. If not, you can add it easily as an add-on in just a few clicks. Just follow Step 2 of the official AWS guide .
Now let’s dive in!
We’ll walk through each step manually to provide a detailed technical breakdown. However, for the target-state installation process, we recommend a different strategy. Since all changes happen at the Kubernetes level, they can be neatly incorporated into SAS’s installation pipeline. Think of Steps 1-3 in this guide as building blocks that should ultimately be incorporated into the pipeline — using SAS’s kustomization mechanism for seamless automation.
SAS Viya assumes that the EFS folder structure is pre-created. Some access points may be set up but never actively used from EKS.
To create the folder structure we use a simple busybox Pod, which allows us to connect to /export and manually define the required directories. No dynamic provisioning is needed - this is static one.
Below is the complete set of Kubernetes manifests required to set up the structure:
File system ID should be gathered from AWS EFS:
.png)
Persistent Volume Claim manifest:
Busybox Pod manifest:
Once the Pod is running, you can connect to it and create the required folder structure:
Now let’s create Storage Classes. In our case here’s the list:
Static Storage Classes are nearly identical, except for the differences in path configuration:
As for dynamic folder creation in EFS, the Storage Class configuration should look like this:
The good news? No changes are required for the PVCs that utilize the sas Storage Class. It’s designed to work seamlessly with the existing setup.
To proceed, we need to set up PVCs for statically provisioned EFS folders. Initially, the setup relied on an nfs type of volume, but we will switch to PVCs instead. Here’s the updated PVCs manifest:
Before modifying the manifests, here’s a quick recap of the installation process.
Let’s start in reverse order. It’s controversial, but It’s actually easier to work backwards while discussing steps here:
Kubernetes: kubectl apply -f <manifest>kustomize build -o site.yamlansible-playbook <...> playbook.yaml --tags "viya,install"
The real focus here is on Last step - 1. This is where any required kustomizations are implemented. Interestingly, SAS itself applies kustomizations at this step to tweak the basic manifest. A great example is the introduction of NFS-client usage through:
Here, we’ll tweak the files to:
Here’s how the updated cas-add-nfs-mount.yaml looks like:
Here’s the updated compute-server-add-nfs-mount.yaml:
With these adjustments, you’re ready to complete the installation.
Once deployed, SAS Viya will be fully integrated with Amazon EFS, with encryption-in-transit enabled.
Congratulations — you did it! 🎉
We switched from nfs-client to AWS’s native efs-csi-driver, enabling the encryption-in-transit feature. Here’s how we did it:
/export folderbusybox Pod connected to the /export folderUseful tips:
busybox Pod as a debugging and configuration tool:viya-prepare) for provisioning and managing related objectsThis is just one example of the custom solutions we implement for marketing automation projects. At T1A, we specialize in end-to-end implementations, helping businesses maximize the potential of tools like SAS Viya.
From deploying marketing automation tools to training teams and building tailored marketing strategies, we help businesses unlock value at every step.
Ready to elevate your marketing technology stack?
Contact us today to explore how our expertise can empower your success.
