Managing Accessors

Accessors enable Agents to connect to storage sources and targets by creating an access method. Follow the steps below to create an Accessor.

Creating an Accessor

1. Click Orchestration > Accessors in the left-hand navigation panel.
   The list of existing Accessors displays. 
   
    
2. Click Create Accessor at the top-right.
   The Create Accessor window appears. 
   
    
3. In the Name field, enter the Accessor name; typically, it's the name of the associated storage.
   NOTE: Agents can have multiple Accessors.  
   
    
4. In the Scope field, select a scope to define access control for the Accessor.
   
    
5. From the Accessor Type drop-down, chose the appropriate type and configure the necessary details based on the selected type:
   •  
     •  
       • Local  
         Path – Specify the directory or path to be used on the Agent.
         
          
       • AWS 
         CloudSoda supports two access methods for AWS resources: Access Key and Credential Provider Chain.
         
         Access Key ID – The IAM user's Access Key, either created manually or retrieved under the Options tab from a CloudFormation Template or an existing bucket.
         
         Secret Access Key – The corresponding Secret Access Key, either created manually or retrieved under the Options tab from a CloudFormation Template or an existing bucket.
         
         Default Credential Provider Chain - AWS system that automatically discovers and retrieves the necessary credentials for interacting with AWS services. It allows administrators to define how AWS credentials are obtained by leveraging multiple sources, such as environment variables, configuration files, IAM roles, and more. 
         
         To use the Credential Provider Chain in CloudSoda, set the Accessor Type and the agents will handle credential management automatically. For more details, refer to the Credential Provider Chain.
         
         Advanced - This section allows you to configure a custom S3 API endpoint through which all traffic will be routed. This is very common when using a S3 VPC endpoint and a direct connect.
         
          

       • Azure 
         CloudSoda supports three access methods for Azure resources: Client Certificate Credential,  Client Secret Credential and Default Azure Credential.
         
         Client Certificate Credential & Client Secret Credential - Microsoft recommends using Client Certificate Credential or Client Secret Credential as preferred authentication methods to access Azure storage resources. 
         
         Default Azure Credential - Dynamically determines the most suitable authentication method based on its environment. It sequentially attempts various credentials, including:

         • Environment variables

         • Managed identity

         • Azure CLI credentials

         This allows CloudSoda to access Azure Blob Storage using the best available authentication method—without requiring explicit credential management in the application code.
         
         To enable CloudSoda to use the Default Azure Credential: 

         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 can authenticate with Azure services that support Azure AD authentication - without embedding credentials in the code ​(MS Learn). 

         For step-by-step instructions, refer to Microsoft’s documentation on configuring managed identities for Azure resources using the Azure CLI.
         
          

       • Google Cloud 
         CloudSoda supports two authentication methods for accessing Google Cloud Platform (GCP): Service Account Key and Default Application Credentials.
         
         Service Account Key – Generate a key from a service account with the necessary access permission. The key should be a single .JSON document. 
         
         Default Application Credentials - Used by Google authentication libraries to automatically locate credentials based on the application environment. Allows seamless authentication without manual credential management. To use Default Application Credentials in CloudSoda, set the Accessor Type and the agents will manage the rest.
         
         For more details, refer to How Application Default Credentials Works in Google's documentation. 
         
          
       • Custom S3 
         API URL – An endpoint URL for an S3-compatible API, using either HTTP or HTTPS with an IP address or FQDN. Example: https://s3.mydomain.com  
         
         Access Key ID – The public identifier for the access key pair. 
         
         Secret Access Key – The private key for secure programmatic access.
         
          
       • NFS - To integrate NFS with CloudSoda, mount the NFS share on the appropriate server and use the Local Path Accessor to configure access.
     •  
       • SMB - CloudSoda supports SMB Accessors to connect to SMB shares.
         
         Network Share – The UNC path specifies the location of the SMB resource. It uses this format, FQDN followed by the share name. 
         Example: \\myserver.mydomain.com\myshare 
         
         Mount Options – Mount options define how the system interacts with files on SMB storage. CloudSoda supports the following set of Linux CIFS mount options: mapchars, nomapchars, domain, mapposix, nomapposix, vers. Mount options should be specified without spaces, using a comma-separated format. 
         Example: iocharset=utf8, mapchars 
         
         Username – Public name of the user account requesting access. 
         Password – Secret password used for authenticating the user account. 
         
         NOTE: SMB read/write operations are performed as the user/group specified in the storage. The user should have full access to the data on the storage. 
         
         For AD domains, use the mount option of domain= to authenticate properly.
         
         When transferring files between Windows, Mac, Linux, and object storage, some characters may be invalid or unrecognized in Linux or object storage environments. If this occurs, use one of these options to resolve the issue:  
              1. Fix the invalid character name manually before transferring files.
              2. Use the mapchars mount option to automatically replace unsupported characters.
         
          

         • When using mapchars, invalid characters are replaced with a placeholder symbol (e.g., a black diamond with a white question mark or an empty square box).

         • If preserving the exact filename is critical, do not use mapchars; instead, manually correct filenames before transfer.
           
            

         • Wasabi
           CloudSoda supports a single access method for Wasabi buckets.
           
           Access Key ID – The public identifier for the access key pair. 
           
           Secret Access Key – The private key for secure programmatic access.
           
            
         • Dell PowerScale
           CloudSoda support a Dell PowerScale accessor running OneFS 9.1.0.16 or newer for accessing the storage over the HTTP API interface. 
           
           Node URLs - The URL for the accessor 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 - Please use the root user or a user with the same level of permissions.
           
           Password - Secret password used for authenticating the user account.
           
           Skip TLS Verification - This advanced feature is disabled by default and should only be enabled if you want to perform this function.