Folder Structure

Using Folders to Control Access (Inherit Permission)

You can apply permissions (View/Edit/Owner) at the secret level. This allows you to apply very granular permissions on a single secret if needed. Managing permissions on each secret is powerful for situations where you need that flexibility, but it tends to be harder to manage over hundreds or thousands of secrets. Instead, you should consider using folders to control permissions for most secrets. This can be done by creating a folder structure that best represents your organization, teams or data being stored and then applying permissions on the folders, using inheritance across folders where appropriate. Secrets placed in a folder can then inherit the permissions of the folder.

Deciding on your Folder Structure

The folder structure creates a hierarchy for organization and permissions. This means that folders near the root level need to break out access in high level terms and then get more specific permissions (typically breaking inheritance) as you move down to the "leaf level" sub-folders.

For example:

— Customers

— Human Resources

— Information Technology

—— Development Services

——— Programmers

—— Technical Services

——— Database

———— Oracle

———— SQL Server

——— Systems

———— Network Infrastructure

———— Unix

———— Windows

— Vendors

The most typical configuration is to break out the folders based on the teams that need to use those folders with the most restrictive permissions at the deepest subfolders of the tree.

For instance, an Oracle DBA might have the following permissions on the above folders:

— Information Technology (view)

—— Database (view)

——— Oracle (view/edit/owner)

——— SQL Server (view/edit)

—— Technical Services (view)

If the "require view permission on a specific folder for visibility" setting (Admin > Configuration > Folders) is enabled, a user cannot see the full folder structure unless they have view permissions on all the parent folders of a folder. For example, a user with view on the Oracle folder in our example, would also need view on Database, Technical Services, and Information Technology to see the full folder path.

There are settings under Admin > Configuration > Folders to control whether inheritance on folders and secrets should be turned on and also whether users should always see all folders. There are many ways to configure this for your organization.

The most common approach is:

  • Use inheritance.
  • Do not allow users to see folders unless they explicitly have view permission by enabling the "require view permission on a specific folder for visibility" setting.
  • Require all secrets to have a folder.
Consider using our User Teams Overview feature to align your groups within Secret Server to a team. This can help prevent users from sharing secrets with other individuals outside of their own team.

This approach allows different teams or even different departments within your organization to use the same Secret Server instance independently.

If a business need arises to break permission inheritance on a folder or secret, we recommend tracking or auditing those folders because manually applying permissions can increase your administrative overhead.