Execution Environment Volume Mounts

Administrators can configure volume mounts for specific execution environments instead of configuring global external storage. By default, content only has access to its own app directory.

Overview

Content running in an execution environment has access to any volume mounts configured for that environment. This allows content to access data on shared filesystems, like NFS, without exposing that data to other content.

For information on who can access a particular execution environment, see Execution Environment Permissions.

Administrators can configure NFS or PVC volume mounts that are available in the Kubernetes cluster for an execution environment. The same volume can be mounted in multiple execution environments with different paths and access modes as needed.

Security considerations

Warning

Critical Security Warning

Never mount Connect’s data directory (Server.DataDir) or any storage containing it to execution environments, especially when Connect runs in rootless mode. This would allow publishers to access all of Connect’s sensitive data, including user credentials, content, and system configuration.

Common exposure risks:

  • Mounting NFS exports that include Connect’s data directory. For example, if Connect’s Server.DataDir is mounted from nfs://nfs-server/export/rstudio-connect/data, do not mount nfs://nfs-server/export or nfs://nfs-server/rstudio-connect as they include Connect’s data directory.
  • Mounting a PVC that points to the same source location as Connect’s variable data. For example, if Launcher.DataDirPVCName is "pvc-connect-data", which points to a network storage location /export/rstudio-connect/data, do not mount any PVCs that point to /export, /export/rstudio-connect, or /export/rstudio-connect/data as that would expose Connect’s data directory to the content.

Before configuring volume mounts, verify the storage is completely isolated from Connect’s data directory.

Best practices

When configuring volume mounts for execution environments:

  1. Isolate data directories: Ensure mounted volumes contain only the data that content legitimately needs to access.

  2. Use dedicated storage: Create separate NFS exports or PVCs specifically for content data, isolated from Connect’s system directories.

  3. Apply least privilege: Configure volume mounts as read-only when content only needs to read data.

  4. Audit mount points: Regularly review configured volume mounts to ensure they don’t inadvertently expose sensitive directories.

  5. Test access scope: Before deploying to production, test that mounted volumes expose only the intended data and nothing more.

Volume types

Connect supports two types of volume mounts:

  1. Persistent Volume Claims (PVC). To configure a PVC volume mount, provide:
    • Source: The name of the PVC in your Kubernetes cluster
    • Target: The mount path where the volume will be accessible within the execution environment
    • Mode: Read-only or read-write access
  2. Network File System (NFS). To configure an NFS volume mount, provide:
    • Source: The NFS server host and export path
    • Target: The mount path where the volume will be accessible within the execution environment
    • Mode: Read-only or read-write access

Configuration

Administrators can use the Connect API or the Connect UI to configure volume mounts for a specific execution environment.

To configure execution environment volume mounts in the Connect UI, visit the System>Environments tab. The expanded view for an environment shows any currently configured volume mounts.

Environment view showing an expanded environment with configured volume mounts

Environment view showing an expanded environment with configured volume mounts

When adding or editing an environment, configure any the volume mounts in the Volume Mounts section of the environment dialog.

Environment dialog with volume mounts configuration section

Environment dialog with volume mounts configuration section
  • To add a volume mount for an environment, locate the Volume Mounts section and click the Add Volume Mount button at the top of that section. This opens a dialog to configure the settings for the PVC or NFS volume mount.
  • To edit an existing volume mount, locate the volume mount in the list and click the Edit button (pencil icon) within that row. This opens a dialog to configure the settings for the PVC or NFS volume mount.
  • To remove a volume mount, locate the volume mount in the list and click the Delete button (trash icon) within that row.

Changes to the volume mount configurations take effect the next time the execution environment is launched. Execution environments remain running until all instances of content running within the execution environment pod exit. To stop all running content for a specific execution environment immediately, please use this cookbook script.

Accessing volume mounts from content

Once volume mounts are configured for an execution environment, content running within that environment can access the data at the specified target path.

Troubleshooting

Volume mount not accessible

If content cannot access the mounted volume, verify the following:

  1. Check that the execution environment with the volume mount is correctly associated with the content.
  2. Verify that the volume mount is configured correctly in the execution environment settings.
  3. Ensure the NFS server is accessible from the Kubernetes cluster (for NFS mounts).
  4. Check that the PVC exists and is bound to a Persistent Volume (for PVC mounts).
  5. Verify that the Kubernetes user running the execution environment has appropriate permissions to access the volume.
  6. Check the content logs for any permissions errors when attempting to access the mounted path.

Changes not taking effect

If changes to volume mount configurations don’t seem to be taking effect:

  1. Ensure that all running instances of content using the execution environment have been stopped by navigating to System > Processes within the Connect UI.
  2. Use the cookbook recipe Stop all running jobs for content that uses the execution environment to force the execution environment to restart.
  3. Verify that the execution environment pod has been recreated by checking the Kubernetes logs.

Permission denied errors

If users encounter “Permission denied” errors when accessing mounted volumes:

  1. Check the access mode configured for the volume mount (read-only vs. read-write).
  2. Verify file system permissions on the NFS server or underlying storage.
  3. If the execution environment has Access Control set, ensure that the user has been added to the list.