User Accounts, Roles, and Partitions
The Key Manager web interface uses role-based access control (RBAC) for managing how users are allowed to access it. Every user account is assigned a set of roles and a set of HSM partitions. This page describes the available roles, their functions, and what permissions they have.
Key Manager UI Roles
The Key Manager offers three separate roles: Admin, Key Manager, and Read-only. Each role is distinct and has a unique set of permissions associated with it. The following table shows the general permissions and tasks associated with each role.
| Role | General Description |
|---|---|
| Admin | Manages Users, HSM Partitions, secrets and global settings. Does not have access to keys, certificates, and data objects on the HSM. |
| Key Manager | Can manage the lifecycle of keys, certificates, and data objects (create, rotate, delete, ...). Can manage SKA approvers and profiles. Can manage other functionality (compliance, KMIP, ...). Cannot manage HSM partitions, KMS users, or KMS configuration. |
| Read-only | Auditor role, has read permission over keys, certificates, audit logs, alerts, etc. |
Currently, it is not possible to define custom permissions or additional roles.
For a full breakdown of the permission lists, navigate to Administration > Users > Role Definitions.
Creating New Accounts
When the Key Manager is first installed, the Initial Wizard in the web interface guides you through creating the first account. This first account has the Admin role.
An Admin can add more user accounts by going to Administration > Users > Create User. When creating a user, the Admin selects their initial role and assigned partitions.
Additional user accounts can also come from identity providers (SSO) that are configured in the Key Manager Administration > Identity Provider. When using an identity provider, the user must log in once before they can be managed. When they log in for the first time, they are granted the Key Manager role and no Partition access.
Partitions
The Key Manager accesses HSM partitions through the REST API (TSB). Therefore, when an Admin adds a new partition, the following are required:
- URL to the TSB instance
- JWT access token
As a TSB operator, see the TSB documentation for how to configure JWT-based access control.
After a Admin has added a partition to the Key Manager, it can be assigned to user accounts.
HSM Sub-Roles
The TSB JWT access tokens can be scoped to a specific Primus HSM sub-role. For example, by using the HSM's "read" sub-role, you can ensure that the HSM (not the Key Manager auth service) enforces the read-onlyness of the partition access.
If this separation is desired, the Key Manager Admin should add the partition multiple times to the Key Manager, once for each HSM sub-role. Note that Key Manager does not inspect what type of JWT token it is. Instead, the Admin manually needs to choose the assignment of partitions to user accounts.
For example, when you create an account for an auditor, you can assign it:
- The "Read-only" Key Manager UI role
- A partition that has a JWT linked to a "read" HSM sub-role
Why it Matters
Assigning dedicated and distinct roles for your users is crucial for a properly managed KMS instance.
- Separation of duties: only the Key Manager role grants permission to use the keys in the HSM. Similarly, only the Admin can configure the Key Manager UI and the Read-only role can be given to users for review and auditing.
- Least privilege: Roles let you hand out the minimum permissions needed for each user based on their role in the company.
- Auditability and compliance: standards like SOC 2, ISO 27001, PCI-DSS, and FIPS expect clear, documented access boundaries. Roles make it possible to show auditors who can do what.
- Reduced exposure: if a user is compromised only permissions based on their role are exposed, minimizing overall impact.