About permissions

Access to items in Trust Protection Platform is controlled through permissions that are granted to individual users, or groups that users belong to.

Before you begin working in permissions, you should have a working understanding of the following:

What policies are and how the policy tree works. See About Policies.
What permissions are and how they are assigned. See Permissions overview.
How permission inheritance works in Trust Protection Platform. See Permission inheritance and flow down.

In Venafi Platform, permissions can be viewed for objects (certificates, keysets, devices, folders) and identities. When you are viewing object permissions, the permissions that are applied to those objects depend on where the objects are in the policy tree, because objects inherit the permissions set at the parent level (or higher) in the tree. Venafi Platform shows you both the permissions set on the current object, as well as the permissions that are effectively applied based on the object's position in the policy tree.

Permissions for objects (including certificates, keysets, folders, and devices, and jobs)

NOTE Permissions information is only available to users who have the Manage Permissions permission for the object they are viewing.

To view permissions for a certificate, keyset, folder, device, or job, locate the object, and then click Permissions.

Permissions panel for certificates in the Aperture console

The Permissions panel shows both local permissions (#1 in the graphic above) that are applied to this specific item (e.g. certificate or device), as well as cumulative permissions (#2) that this object inherits based on its position in the folder structure.

Permissions that are explicitly granted to this object appear as editable check boxes. Permissions that are implied based on being granted by another permission appear grayed-out, indicating they are read-only. For example, for #3 in the image above, the Read permission is an implied permission because of the Write permission that was explicitly given.

For more information about where a specific user or group was granted a permission, click Troubleshoot Permissions. For more information, see Troubleshooting Permissions .

Permissions for SSH keysets

In Trust Protection Platform you can manage permissions for keysets independent of the devices they are connected to. You can do this either by using policies, or through permissions set on the keyset itself.

Permissions on a keyset through policies

Keys can be moved individually, or in bulk to policy folders whereupon the applicable policy settings will be applied to the keysets. If a keyset is in a policy folder and the user has the Manage Permissions permission, a new tab appears on the keyset details page, allowing the user to view and edit the keyset's permissions.

When keysets are added to a policy folder, their permissions are no longer coming from the device they are connected to. Therefore, you can have a case where a user has permissions to view or edit a keyset, but doesn't have permissions to view or edit the device the keyset is linked to. In this situation, a user can still rotate the keyset, but will not be able to add keys.

Permissions on a keyset through keyset settings (for application owners)

In previous versions of SSH Protect, you had to have permissions on the device where a key was installed if you wanted to take action on the keyset. This was difficult for application owners who needed to manage keys for their application, but they didn't have admin permissions on the device.

SSH Protect now allows you to store permission information on the individual keyset, in addition to the permissions on the device object.

The table below (click the headline to expand) shows what permissions are needed to take specific actions on a key or keyset, depending on whether the permissions are set at the device level or on the keyset. (Note in the comments when an option is provided that requires some level of permissions on both the device and the keyset.)

SSH Permissions required for devices vs. keysets

SSH Permissions required on device or on keyset for specific actions
Action	Device	Keyset	Comments
See SSH keys	`[View & Read]`	`[View & Read]`
Add automated private key to an existing keyset	`[View & Read & Write & Private Key Read]`	see comments	Another option is to have (on device) `[View & Create]` AND have (on keyset) `[View & Read & Write & Private Key Read]`
Add automated public key to an existing keyset	`[View & Read & Write]`	see comments	Another option is to have (on device) `[View & Create]` AND have (on keyset) `[View & Read & Write]`
Delete a key	`[Delete & Write]`	`[Delete & Write]`
Add or change passphrase of an SSH key	`[View & Read & Write]`	`[View & Read & Write]`
Rotate a keyset	`[View & Read & Delete]`	`[View & Read & Write]`
Move an existing keyset to a policy		(Source Folder: `[Delete]`) AND (Target Folder: `[View & Read & Write & Create]`)

Permissions for identities

To view permissions for an identity, locate the object, and then click Permissions Granted on the left.

The Permissions Granted panel shows the object in the policy tree (policy/folder, certificate, or device) where the permission is explicitly granted. If the permission is granted to a group, you can click the name of the group to open the group identity, and see the permissions that have been granted to that group.

Object permissions

An overview of permissions
Permission	Allows the user to...
View	The user can see the object in the tree, but cannot select the object or read the values.
Read	The user can see and select the object in the tree. Additionally, the user can read the object data, but no buttons are enabled; the user cannot edit or manage the object. In Certificate objects, users with Read permissions to the certificate can see only the associated applications to which they have View or higher permissions to the Application object. In Application objects, users with Read permissions to the application can see only the associated certificate if they have View or higher permissions to the Certificate object. For SSH keysets, users with Read permissions to the keyset (if in a policy folder) can view all keys in the keyset. If the keyset is not in a policy folder, then the user can see all the keys in the keyset if they have Read permissions on all devices in the keyset.
Write	The user can edit and modify object attributes. To move objects in the tree, the user must have Write permissions to the objects and Create permissions to the target folder. Read permissions are inferred. Rename is selected by default but can be deselected. In Certificate and Application objects, the user also has access to the following options in the designated pages:
	Certificate Summary Page	Users with Write permissions to the Certificate object have access to the Restart, Retry, Reset, and Revoke options.
	Certificate Settings Page	Users with Write permissions to the Certificate object have access to the Renew Now option.
	Certificate Associations Page	Users with Write permissions to the Certificate object can see all associated applications, regardless of their permissions to the individual applications. Users with Write permissions to the Certificate object can add associations only to those applications to which they have either Write, or both Associate and View permissions. Users with Write permissions to the Certificate object have access to the Retry Installation option only for those applications to which they have either Write or both Associate and View permissions. Users with Write permissions to the Certificate object can push the certificate and private key only to those applications to which they have either Write or both Associate and View permissions. Users with Write permissions to the Certificate object can enable or disable the certificate only on those applications to which they have either Write or both Associate and View permissions.
	Application Settings Page	Users with Write permissions to the Application object can add associations only if no certificate is currently associated with the Application object or if they have either Write or both Associate and View permissions to the associated Certificate object. Users with Write permissions to the Application object have access to the Retry Installation option only if they have either Write or Associate and View permissions to the associated Certificate object. Users with Write permissions to the Application object can push the certificate and private key to the application only if they have either Write or Associate and View permissions to the associated Certificate object.
	For SSH keys, users with Write permissions to a keyset can rotate keys, delete keys from a keyset, add a new key, and can add a passphrase to a key. However, if the user doesn't have Write permissions to write to the key's associated device, then the user cannot add keys.
Create	The user can create subordinate objects, such as devices and applications. View is inferred. For SSH keys, you must have the Create permission in the target folder to move a keyset into that folder.
Manage Policy	Lets users modify policy values on folders. Read and Write permissions are implied; the View permission is not. In order for the Manage Policy permission to be useful, users should be granted the View permission, as well. For SSH keys, you must have the Manage Policy permission in the target folder to move a keyset into that folder.
Delete	Lets the user delete objects. For SSH keys, you need to have the Delete permission to remove keysets from all folders (returning the keyset to device-level permissions). For SSH keys, you need the Delete permission in the source folder when moving a keyset from one folder to another.
Rename	Lets the user rename objects or move them within the tree. To move an object, the holder must have the Create permission in the target location. When an object is moved, locked policy attributes are recalculated.
Associate	If you have Write permissions to a Certificate object and both Associate and View permissions to the application(s) where the certificate is installed, you can perform the following functions in the Certificate object’s Certificate Associations page: Associate or disassociate the application with the certificate Push the certificate and private key to that application Retry the certificate installation Enable or disable the processing of certificates on the application. When you disable processing, Trust Protection Platform does not attempt to install, renew, process, or validate certificates for the current application. If you have Write permissions to an Application object and Associate and View permissions to the certificate installed on the application, you can perform the following functions in the Application object’s Settings page: Associate or disassociate the certificate with the application Push the certificate and private key to that application Retry the certificate installation This permission is relevant only to Policy, Application and Certificate objects.
Revoke	Revoking a certificate makes it invalid. You must have Write permissions to the certificate. Once you Revoke a certificate, you cannot undo the action.
Private Key Read	You can download the private key from the Trust Protection Platform database, if the key is archived in the Trust Protection Platform database. This permission is relevant only to Policy and Certificate objects.
Private Key Write	You can upload a certificate private key file to the Trust Protection Platform database. This permission is relevant only to Policy, Certificate, and Private Key Credential objects.
Admin (Policy Tree only)	Grant other user or group Identities permissions to the current object or subordinate objects. In the Aperture console, this permission is called Manage Permissions.
Manage Permissions (Aperture console only)	Grant other user or group Identities permissions to the current object or subordinate objects. In Policy Tree, this permission is called Admin.