View sandbox persistent-workspace files in Azure Portal

When a Sandbox Policy uses persistence mode persistent-workspace, FoundationaLLM mounts durable storage at /workspace in the Kata sandbox pod. The policy storage SKU chooses how that volume is provided:

SKU	What is mounted	Typical StorageClass
standard-smb	One Standard (HDD) Azure Files share per conversation	foundationallm-sandbox-azurefile
shared-ssd	A folder on a shared Premium Files share. Class workspace_bytes is enforced in the pod (FUSE quota), not as an Azure per-folder quota.	foundationallm-sandbox-azurefile-ssd-shared
dedicated-ssd	One Premium Files share per conversation	foundationallm-sandbox-azurefile-ssd
dedicated-disk	One Premium SSD, Premium SSD v2, or Ultra managed disk	foundationallm-sandbox-disk-premium / foundationallm-sandbox-disk-premiumv2 / foundationallm-sandbox-disk-ultra

This guide records the access pattern for Azure Files SKUs when storage account keys are disabled (keyless CSI / workload-identity mounts). Dedicated disks are inspected as managed disks in the node resource group, not as file shares.

This guide records the access pattern that works when storage account keys are disabled (keyless CSI / workload-identity mounts).

Background

Item	Typical value in the secure-sandbox development topology
Persistence mode	persistent-workspace
Kubernetes StorageClass	foundationallm-sandbox-azurefile
Storage account	Configured on the StorageClass (for example stl43jljq2i5ox6)
Share naming	Dynamically provisioned shares named pvc-<guid>
PVC naming	workspace-<sha256(conversationId)[0:32]> in the sandboxes namespace

Ephemeral mode does not keep the live workspace on these Azure Files shares; it uses an in-pod FUSE quota over local emptyDir backing and discards /workspace when the sandbox is deleted.

Why Browse fails with only SMB Share Reader

Azure Portal Browse with Microsoft Entra user account uses OAuth over REST. It does not use the SMB share roles alone.

Role	What it enables
Storage File Data SMB Share Reader / Contributor	SMB access (Kerberos / identity-based SMB)
Storage File Data Privileged Reader / Privileged Contributor	Portal Browse (and related OAuth file data APIs)

Microsoft documents Portal Entra browse as requiring Storage File Data Privileged Reader or Privileged Contributor, plus an Azure Resource Manager role that can navigate the storage account (for example Reader, Contributor, or Owner). See Authorize access to file data in the Azure Portal.

What made admin Browse work in practice: assigning the operator Storage File Data Privileged Reader on the storage account (in addition to any control-plane Owner/Contributor rights).

Storage File Data SMB Share Reader alone is not sufficient for Portal Browse.

Prerequisites

1. Microsoft Entra Kerberos (identity-based access) enabled on the storage account, because account keys are often disabled in this topology.
2. Your Entra user can open the storage account in the portal (ARM Reader or higher).
3. Permission to assign Azure RBAC on the storage account (or ask a subscription admin).

Steps

1. Enable Microsoft Entra Kerberos (if not already)

1. Open the storage account → Data storage → Classic file shares.
2. Next to Identity-based access, open the status (for example Not configured).
3. Under Microsoft Entra Kerberos, select Set up, check Microsoft Entra Kerberos, and Save.
4. Leave Domain name / Domain GUID empty unless you specifically need Windows File Explorer ACL editing against on-premises AD.
5. Leave Default share-level permissions as Disable permissions… when you grant access via IAM to specific admins (preferred over “all authenticated users”).
6. If prompted later, grant admin consent to the Entra enterprise application named like [Storage Account] <account>.file.core.windows.net (Entra admin center → Enterprise applications → app → Permissions → Grant admin consent).

Enabling Kerberos does not replace the CSI workload-identity mount path used by sandbox pods.

2. Assign Storage File Data Privileged Reader

1. Storage account → Access control (IAM) → Add role assignment.
2. Role: Storage File Data Privileged Reader (use Privileged Contributor only if admins must write/delete via data-plane APIs).
3. Assign to the admin user or a small operators group.
4. Scope: the storage account (or a specific share if you prefer tighter scope).
5. Wait one to two minutes for RBAC propagation.

Do not rely on Storage File Data SMB Share Reader for Portal Browse.

3. Locate the conversation’s file share

1. Map the User Portal chat / conversation id to the PVC:

   • PVC name: workspace- + first 32 hex chars of SHA-256(UTF-8 conversation id).
   • Example: kubectl get pvc -n sandboxes workspace-<hash>.

2. Read the bound PV’s CSI volumeHandle. It looks like:

   <resourceGroup>#<storageAccount>#pvc-<guid>###<namespace>
   

3. The Azure Files share name is the pvc-<guid> segment.

4. In the portal: storage account → Classic file shares → open that share (search by pvc-…; sorting by name alone can hide newly created shares).

4. Browse with Microsoft Entra

1. Open the share → Browse.
2. Set Authentication method to Microsoft Entra user account.
3. Refresh. You should see the files that appear under /workspace in the sandbox.

If Browse still fails after Privileged Reader is assigned, confirm Kerberos admin consent and that Conditional Access / MFA is not blocking the storage account’s Entra Kerberos application.

Security notes

• Privileged Reader at storage account scope can list data on all pvc-* sandbox workspaces in that account. Prefer a small admin group and remove assignments when the investigation is done.
• Do not enable “permissions for all authenticated users” on a shared sandbox storage account unless you intentionally accept that blast radius.
• Prefer reading verification markers through the User Portal / Management API when sufficient; use Portal Browse for operator diagnostics.

Related

• Secure Sandbox Contract v1
• Sandbox Policy persistence modes (ephemeral, persistent-workspace) in the AKS Pod Sandbox plan and sandbox-policy-domains-v1 contract.