Domain Management
A domain is a logical division that isolates users and cryptographic keys. Resources like keys are isolated to a single domain and cannot be accessed across domains.
CipherTrust Manager's domains form its multitenancy model. Multitenancy enables the creation of multiple restricted or local domains within a single CipherTrust Manager appliance. Enterprises can use multitenancy to segregate key access (or other resource access) to better control usage of product by line of business or use case.
Every CipherTrust Manager appliance has a root domain by default. Additional child domains can be created, and child domains can have their own children domains. We have validated 100 domains for Virtual CipherTrust Manager k170v, and 1000 domains for every other model. A domain administrator role controls the creation, deletion, and user assignment of domains.
Note
You need a valid Virtual CipherTrust Manager license to create child domains. The license can be the included 90-day trial license, or a purchased license. Without a license, only the root domain is available. To activate your instance with a trial evaluation, or a term or perpetual license, see Licensing.
We have introduced a technical preview feature to optionally anchor a child domain to a Luna Network HSM partition. All keys and secrets within an HSM-anchored domain are wrapped and unwrapped by the HSM itself. This strengthens the security and isolation of the multitenancy model. There are back up and performance considerations for this option, which should be planned for before enabling the feature.
Not all resources are segregated. Certain settings and configurations are only configurable in the root domain. This includes:
System settings such as syslog servers and NTP servers.
Authentication settings such as LDAP servers.
CipherTrust Manager allows you to partition a single instance into multiple domains, and allows separate administrators with separation of duties to manage encryption keys, security controls, and auditing in each domain.
Domain Planning
As part of configuring CipherTrust Manager, the domain administrator should think about the requirements for the domains to be included within the configuration.
Note
Domains do not support patch operations. Therefore, domain-related properties except the Syslog message redirection cannot be modified.
Among the requirements to be considered before creating the domain are the following:
Administration
Number and type of administrators required. Administrators can assign user groups to the domain and manage child domains. If administrators have the correct permissions, they can also perform operations on domain resources directly.
Number of users requiring access to the domain's resources.
Administrative operations/practices
Backup and Key Rotation Schedule
Access to and storage of logs on an external syslog server for auditing purposes
Selecting Parent CA
The default CA of a domain is signed by the parent CA selected while creating the domain.
The duration of domain's default CA cannot be more than the parent CA duration.
The maximum duration of a domain's default CA can be 10 years.
Key hierarchy
- Whether to anchor the domain to an HSM partition.
Caution
This feature is a technical preview for evaluation in non-production environments. A technical preview introduces new, incomplete functionality for customer feedback as we work on the feature. Details and functionality are subject to change. This includes API endpoints, UI elements, and CLI commands. We cannot guarantee that data created as part of a technical preview will be retained after the feature is finalized.
If you choose to anchor the domain to an HSM, there are additional dependencies and limitations:
Configuration of the HSM partition(s) is required.
Configuration of the HSM connection(s) is required.
Backup and restore operations are more constricted for HSM-anchored domains. Domain objects can only be backed up and restored as part of a system backup. Domain scoped backups are unavailable. As well, to successfully restore the backup, the CipherTrust Manager needs an active connection to the HSM partition.
There might be a performance impact to applications that frequently interact with the domain keys.
User Management
When a domain is created, one or more initial administrators must be defined. When administrators subsequently log into the domain, they can use assign additional users to the domain and also use groups to assign user permissions.
Note
The CipherTrust Manager allows you to create users in a non-root domain if you set the allow-user-mgmt
property to true
while creating the domain.
The defined Admins should, at minimum, have group permissions to create domains, users, and groups. You can assign the admins to the 'Domain Admins' and 'User Admins' system-defined groups to have the correct permissions.
Creating Domains
A new domain is automatically a child domain of the logged-in domain at the time of creation. So, if you are logged into the root domain, and create a new domain, the new domain is a child of root.
By default, a parent domain and its descendants are part of the same certificate chain. You can create domains in a parent-child hierarchy down to ten levels before having to manually replace their associated certificates for client certificate authentication.
The workflow to create a domain varies depending on whether you wish to have the domain anchored in CipherTrust Manager software or in an HSM partition.
To create a domain anchored in CipherTrust Manager software
Review the domain planning considerations.
Log into the CipherTrust Manager Management Console as an Admin with domain creation permissions.
Navigate to the domain by clicking Admin Settings and selecting Domains.
Select Add Domain.
Enter the following information in the Add Domain dialog:
Name: Name of the domain
Admins: Define the initial set of Admins who can log into the domain, assign users to groups to the domain, and create child domains. These Admins should have the correct permissions.
The following information is optional:
Parent CA: Each domain has a default Certificate Authority (CA) automatically created. This field defines the parent CA which signs the Default CA for the new domain. If no parent CA is provided, the oldest CA in the root domain is used.
Allow Subdomain User Management: Select the check box to allow the creation and management of users in non-root domains.
Meta: Additional reference information regarding the domain. Must be JSON formatted. This can be used to attach information – such as the department or contact details – to the domain. It can then be queried and viewed later. This field is not used internally by CipherTrust Manager.
To create an HSM-anchored Domain
Caution
This feature is a technical preview for evaluation in non-production environments. A technical preview introduces new, incomplete functionality for customer feedback as we work on the feature. Details and functionality are subject to change. This includes API endpoints, UI elements, and CLI commands. We cannot guarantee that data created as part of a technical preview will be retained after the feature is finalized.
Review the domain planning considerations, especially the key hierachy considerations.
Configure a Luna Network HSM version partition following Luna Network documentation.
Supported Luna Network HSM firmware versions are 7.7.x and higher. Consult Luna Network HSM documentation for FIPS 140-2 certified versions.
Configure a connection to the HSM partition in Connection Manager.
Create the new domain using
ksctl domains create
. Provide the following required parameters:name
: Name of the domainadmins
: Define the initial set of Admins who can log into the domain, assign users to groups to the domain, and create child domains. These Admins should have the correct permissions.hsm-connection-id
: The ID of the HSM partition connection created in Connection Manager.
The following settings are optional:
hsm-kek-label
: An optional name for the domain Key Encryption Key (KEK) stored in the HSM partition. If not provided, a random UUID is assigned for KEK label.parent-ca-id
: Each domain has a default Certificate Authority (CA) automatically created. This setting defines the parent CA which signs the Default CA for the new domain. If no parent CA is provided, the oldest CA in the root domain is used.allow-user-management
: Set to true to allow the creation and management of users in non-root domains.meta
: Additional reference information regarding the domain. Must be JSON serializable. This can be used to attach information – such as the department or contact details – to the domain. It can then be queried and viewed later. This field is not used internally by CipherTrust Manager.
Certificate-based Login for Domain Users
Add New Domain
Deploy the CipherTrust Manager.
Log on to the CipherTrust Manager Management Console as an administrator with domain creation permissions.
In the left pane, click Admin Settings > Domains.
Select Add Domain.
Enter the required details. Refer to the To create a domain anchored in CipherTrust Manager software section for the description of fields.
Select Allow Subdomain User Management.
Click Save.
Add New Domain User
Switch to the newly created domain.
Navigate to Access Management > Users.
Click Add User and enter the required details.
Select Allow user to login using certificate. Refer to Enable the "Certificate based Login" Option for a User for details.
Click Add User to save the details.
Download Local CA Certificate
Navigate to CA > Local.
Click Add Local CA.
Specify the required details. Refer to Create and Download the Web Certificate for details.
Under Name, click the link of the newly generated local CA.
Click Issue Certificate.
Enter the Common Name for this certificate.
Note
This common name should be the same common name that you specified while creating the user.
Select the desired algorithm (RSA or ECDSA).
In the Name field, specify the same details that you specified in the
certificate_subject_dn
property of the user.Click Issue Certificate.
Click save private key to download the key.pem file.
Click Issue Certificate. The newly created certificate is displayed in the certificates list.
Download the certificate issued by the local CA and save it at the same location where the private key is saved.
Download External CA and Update Certificate
Navigate to CA > External.
Download the external CA.
Append the local CA and external CA to the certificate downloaded above.
Create and Import PKCS#12 (PFX) File
Run
openssl pkcs12 -export -out user.pfx -inkey key.pem -in certificate.pem
. Refer to Create and Install pkcs12 Formatted Certificate for details.Import
user.pfx
to truststore.
Log on as Domain User
Clear the browser cookies.
Select the web certificate and log on to the CipherTrust Manager as domain user.
Deleting Domains
Domain administrators can delete domains.
If the domain is HSM-anchored, you can optionally specify to delete the domain Key Encryption Key (KEK) stored in the HSM partition in the CLI and API. For example ksctl domains delete --id <domain-name-or-id> --delete-hsm-kek
deletes both the domain and its associated KEK in the HSM.
Warning
Deleting the domain KEK means that you cannot restore older backups of the domain on any CipherTrust Manager directly. This can result in permanent loss of domain contents. An HSM administrator might be able to recover deleted KEKs through HSM backup and restore.
Domain Authentication
Once the domain(s) have been created, the specified Administrator can log in to the domain. Users that are assigned to the domain can also login to the domain to perform key operations.
GUI
In the GUI, in the upper right hand corner, click on the Root/Admin link and Select Switch Domains. Once the domain has been selected, the Admin is taken to the specified domain. From this point forward, all key management and admin activity is constrained to the selected domain.
CLI
In the CLI, you operate in the root domain by default. There are two ways to perform actions inside a child domain:
Log into the domain with the
ksctl login --user <user_with_domain_permission> [--password <user_password>] --domain <domain_name_or_id>
command. If you don't specify the password, you are prompted for it. All subsequent commands in the session are within the domain.Use the
--domain <domain_name_or_id>
option with--user <user_with_domain_permission>
for the particular key management or administrative command you wish to perform. You can specify the password with--password
or enter it when prompted
Note
You can use ksctl tokens self-domains --user <user_name> [--password <user_password>]
to view the domains that a user can access.
REST API
In the REST API, the POST command to authenticate goes to the root domain by default. You can include a child domain name in the schema with domain
, as well as the domain administrator username and password. After this initial authentication, subsequent API requests apply to the authenticated domain.
You can also use the GET /v1/auth/self/domains/ endpoint to return a list of domains that the current user is assigned to.
Domain Scoped Backups
You can scope a backup to a single domain.
Work in Progress
The following functionalities are planned for inclusion in future CipherTrust Manager releases.
Service Provider Functionality: Service Providers may wish to have additional configuration in each domain – authentication servers, for example.
Licensing: Currently, licenses applied to the root domain are available to all child domains on the appliance. Work is underway to better track license consumption on a per domain basis. Therefore, we recommend customers allocate licenses as is expected to be enforced.
Logging: Currently, server and client logging are aggregated at the macro level. Activity from individual domains is tagged, but not separately stored in a domain unique log.
To be added:
The ability for system administrators to disallow per domain syslog configuration if they wish to consolidate information into other systems for support and usage tracking purposes.
Managing Syslog Messages Redirection to Parent Domain using ksctl
Syslog messages redirection allows you to send the syslog messages of the current domain to the syslog server configured in its parent domain.
If the current domain is receiving the syslog messages from its child domain, those syslog messages will also be sent to the syslog server configured in the parent domain of the current domain.
It allows you to perform the following operations:
Enabling/Disabling syslog messages redirection
Status of the syslog messages redirection
Enabling/Disabling Syslog Messages Redirection
To enable syslog messages redirection to the parent of the current domain, run:
ksctl domains syslog-redirection enable
To disable syslog messages redirection to the parent of the current domain, run:
ksctl domains syslog-redirection disable
Note
To enable/disable the redirection of syslog messages to the parent domain is not applicable for the root domain.
Getting Status of Syslog Messages Redirection
It returns the syslog messages redirection status of the current domain. This status shows whether the redirection to parent domain is enabled or disabled. To get the status, run:
ksctl domains syslog-redirection status
Note
Status will always be false for the root domain.