- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Configuring automation capabilities
- Solutions
- Audit
- Settings
- Registry
- Notifications
- Folders Context
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Indexes
- Queues
- Assets
- Connections
- Business Rules
- Storage Buckets
- Agent Gateway
- Orchestrator testing
- Resource Catalog Service
- Integrations
- Troubleshooting
Credential store folder access: how a tenant credential store can be limited to selected folders, how the assignment is inherited by subfolders, and where the limit applies.
Feature availability depends on the cloud offering that you use. For details, refer to the Feature availability page.
Credential stores are created and managed at tenant level, and by default every folder in the tenant can use every store. Folder access is a setting on each store that narrows this: a store set to Selected folders only can be used solely in the folders it is assigned to. Teams that work in separate folders can therefore keep separate vaults, without a separate tenant for each team.
Folder access controls where a store can be used. It is not a guarantee that the credentials themselves are unreachable by other means.
The procedures for assigning stores to folders are described in Assigning credential stores to folders.
Folder access modes
Each credential store is in one of two modes.
| Mode | Description |
|---|---|
| All folders | Any folder in the tenant can use the store. This is the default, and it matches how credential stores behaved before the setting existed. |
| Selected folders only | Only the folders the store is assigned to can use it. |
The Stores page reports the current mode for each store in the Restricted to folders column.
Folder assignments can be recorded while a store is still set to All folders, but they have no effect until the mode changes. Equally, setting a store back to All folders keeps its assignments, so they apply again if the store is later set to Selected folders only.
Inheritance across subfolders
A store assigned to a folder is also available in every subfolder beneath it, however deep the hierarchy goes. A store assigned to a root folder is therefore available across that whole folder tree.
Inheritance cannot be interrupted. There is no way to assign a store to a folder while excluding its subfolders, and a subfolder cannot opt out of what it inherits.
Each folder's credential stores page shows where a store's access comes from, in the Access origin column.
| Access origin | Meaning |
|---|---|
| Assigned | The store is assigned directly to this folder. |
Inherited from <folder> | The store is assigned to an ancestor of this folder, named in the value. |
| Inherited from tenant | The store is set to All folders, so every folder can use it. |
A store can have more than one access origin at once. A store assigned both to a folder and to its parent, for example, shows as assigned and inherited.
Personal workspaces
A store can be made available to all personal workspaces at once, by assigning it to the personal workspaces folder. Individual personal workspaces cannot be assigned, and the credential stores page is not available inside a personal workspace.
Where folder access applies
Folder access is evaluated in the folder an operation runs in, at the moment the credentials are used.
| Resource | How folder access applies |
|---|---|
| Assets | An asset in a folder that the store is not assigned to cannot be read or written. The operation fails with an error naming the store and the folder. |
| Storage buckets | The same as assets. |
| Unattended robot credentials | If no robot in the folder can reach the store when a job runs, the job faults. Setting or updating an account's credentials is a tenant-level action and is unaffected. |
Because the check happens when the credentials are used rather than when they are configured, setting a store to Selected folders only takes effect immediately for every resource already pointing at it.
There is no per-folder default store. The default stores for robots and assets are set once for the tenant, so a default store set to Selected folders only fails in any folder it is not assigned to.
Who can change folder access
Folder access introduces no new permission.
| Action | Permissions |
|---|---|
| Creating, editing, or deleting a credential store, including changing its Folder access | Settings at tenant level, as for any credential store change |
| Viewing the folders a store is assigned to | View on Settings and View on Folders |
| Assigning a store to folders, or unassigning it | Edit on Settings, plus Edit on Folders or Edit on Subfolders for every folder involved |
| Viewing the credential stores a folder can use | View on Folders or View on Subfolders for that folder |
Folder administrators cannot assign stores to their own folders on their own: folder permissions alone are not enough, Edit on Settings is also required. This keeps the decision about which vaults enter a folder with the tenant administrator.
Limitations
- A store assigned to a folder is always inherited by that folder's subfolders, and the inheritance cannot be blocked.
- Individual personal workspaces cannot be assigned. A store can only be granted to all personal workspaces at once.
- Setting or updating the credentials on a robot account is not limited by folder access. Only retrieving them when a job runs is.