Managing Accessors

Accessors are records in CloudSoda that may contain credentials, mount options, file paths, keys, etc. required by an agent to attach/mount a particular storage. For example, to enable an agent to connect (attach) to an AWS bucket, you would create an AWS accessor that contains the Access Key ID and the Secret Access Key with permission to access the bucket.

Creating an accessor

1. From the Orchestration dashboard, select the Accessors option from the left hand navigation bar.
2. From the Accessors screen click the Create Accessor button at the top right of the page.
3. Enter a name for the accessor to help you identify it. It could be the same as the name of the storage that it will be used with or it could be more generic in case the accessor will be used for multiple storage of the same type. e.g. Media Buckets AWS key or SMB credentials for Art Department shares or Google Cloud archiver identity.
4. Select the Account (likely Default) and Scope to control access to the accessor.
5. Select an Accessor Type. Each type is described below.

AWS

CloudSoda supports two methods for accessing AWS buckets:

Access Key

An Access Key ID and Secret Access Key that are either created manually or retrieved under the options tab from a CloudFormation Template or an existing bucket.

Default Credential Provider Chain

The agent will automatically discover and retrieve the necessary credentials for interacting with AWS services by interrogating its host environment.  It allows administrators to define how credentils are obtained by leveraging multiple sources, such as environment variables, configuration files, IAM roles and more. Each possible source is considered a link in the "chain" of providers. This is often, but not exclusively, used when the agent is running on an EC2 instance. Refer to Understand the credential provider chain for more information.

Advanced Options

API URL: Allows you to configure a custom S3 API endpoint to access the bucket instead of relying on the public endpoints. This is very common when using an S3 VPC endpoint and a direct connect.

Direct Connect: When enabled, this lets CloudSoda know to use Amazon's direct connect prices when calculating egress expenses instead of the standard egress prices. This doesn't have any affect on how the agent accesses the bucket.

Azure

CloudSoda supports three methods for accessing Azure containers:

Default Azure Credential

Interrogates the agent host's environment for credentials. It searches environment variables, the Azure managed identity service (when the agent is running on Azure) and Azure CLI credentials. 

This allows CloudSoda to access Azure Blob Storage using the best available authentication method - without requiring explicit credentials in the accessor.

To enable CloudSoda to use the Default Azure Credential (reference at MS Learn):

1. Set up a managed identity for your VM via the Azure CLI
2. Choose either a system-assigned or user-assigned managed identity.
3. Once configured, CloudSoda agents can automatically authenticate with Azure services that support Azure AD authentication

Client Certificate Credential or Client Secret Credential

Refer to Authentication and Access Management Between CloudSoda and Azure Cloud Storage for instructions on setting up a client certificate or secret.

Custom S3

Custom S3 is for accessing S3-compatible storage systems.

API URL: The endpoint to the S3-compatible server.

Access Type: Access Key and Default Credential Provider Chain. See the AWS accessor section above for an explanation of access types.

Dell PowerScale

The CloudSoda accessor requires OneFS 9.1.0.16 or newer, but the latest OneFS version is strongly recommended due to bugs in the OneFS HTTP API.

Node URLs: The URL for the agent to access the cluster. This can be an IP of a node or the URL for the cluster. If you use a URL, we recommend that the DNS be fast or you use host files so DNS lookups don't become a bottleneck.

Username: Use the root user or a user with the same level of permissions.

Password: Password for the authenticating user

Advanced

• Skip TLS Verification: Instructs the agent to skip TLS verification. This can be necessary if the if the cluster nodes use TLS with a self-signed certificate.

Google Cloud

CloudSoda supports two ways of accessing Google Cloud Storage (GCS) buckets.

Service Account Key

Use the Google Cloud Console to generate a key for a service account with the necessary permission to access your GCS bucket. The key is the .json file that you download from the Google Cloud Console.

Application Default Credentials

Interrogates the agent host's environment for credentials to access the bucket. Refer to How Application Default Credentials works for more information.

Local

A Local accessor just contains the path to a directory. The path should be the root you want to use for your storage.

NFS

Starting with the July 2026 release, CloudSoda supports an NFS accessor that enables agents to directly mount NFS exports in-process so you don't have to manually mount the export on the agent's host.

Address: The NFS server's address (IP or domain)

Export: Path to the NFS export

Mount Options (optional): CloudSoda provides support for the below mount options as a string of comma separated values. For example: tcp,resvport

• tcp: Same as proto=tcp
• udp: Same as proto=udp
• proto=: Either tcp or udp. Instructs the agent to connect to the NFS server using TCP or UDP.
• resvport: Instructs the agent to use a privileged port (< 1024) when communicating with the NFS server. The agent must be running as root or have the cap_net_bind_service capability (Linux).
• noresvport (default): Instructs the agent to use a non-privileged port when communicating with the NFS server. The NFS server must be configured to allow clients to connect via non-privileged source ports.

SMB

CloudSoda agents can mount/map SMB shares directly in-process so you don't have to wrestle with local and AD permissions.

Network Share

The UNC path to the SMB share. If the UNC path points to a sub-directory of the share, that will be the root of the storage.

Examples:
\\my.domain.com\myshare
\\my.otherdomain.net\anothershare\dirA\dirB

Mount Options

CloudSoda supports mount options as a string of comma separated values.

• domain: Required for shares that belong to an AD domain
• mapchars: Map reserved file name characters using the Services for Unix scheme. This is equivalent to using mapchars when mounting a share in Linux.
• mapposix: Map reserved file name characters using the Services for Mac scheme. This is equivalent to using mapposix when mounting a share in Linux.

Authorization

Use guest authorization or specify a username and password to access the share.

Additional Notes

• SMB operations are performed as the authenticating user, so make sure the user has sufficient permission to access the storage.
• Exercise caution when transferring files between Windows shares and other storage types and file system. File names with characters that are reserved on Windows will result in an 8.3 file name being written to the share. Use mapchars or mapposix to map reserved characters and avoid 8.3 files names. If preserving the exact file name is critical, do not use mapchars or mapposix - manually correct the file names before transferring.

Wasabi

Accessing a Wasabi bucket requires an access key id and secret access key pair that you can generate in the Wasabi dashboard.