Admin Keys

All KeyControl data (policy information, encryption keys, user account information, and so on) are held in an encrypted object store that is shared across all KeyControl nodes in the cluster.

The object store is ultimately protected (through multiple layers of key wrappings) by an Admin Key that KeyControl generates and maintains. This key is required if you ever need to restore KeyControl from a backup or you need to change the hardware configuration of a KeyControl node.

When you install the first KeyControl node in your system, KeyControl generates an Admin Key as soon as you log into the KeyControl webGUI for the first time. The initial key has a single part and is assigned to the default secroot user account. As you add additional Security Administrator accounts to the system, KeyControl shifts to an "n of m" Admin Key backup model, where "m" is the number of user accounts with Security Admin privileges and "n" is a user-defined value that states how many key parts must be uploaded before KeyControl considers the Admin Key to be valid.

For example, if you have five Security Admins and you set n to 3, then at least three of the Security Admins will need to upload their Admin Key parts in order to restore KeyControl from a backup. If you set n to 1, then any one of the five Security Admins can restore KeyControl without consulting with any of the other Security Admins.

While you can regenerate Admin Key parts at any time, in order to restore KeyControl from a backup image you must have the required number of Admin Key parts that were valid when the backup was created. You cannot regenerate the Admin Key parts and then immediately use those new key parts to restore KeyControl from a previously-created back up.

The Admin Key is assigned a generation count that is incremented each time a new Admin Key is generated. This generation count allows you to identify which Admin Key parts go together. The email that each Security Admin receives when a new Admin Key is generated contains the generation count. For example:

This current Key Part supersedes any you may have previously received from this cluster. The Key Part is associated by a "generation count" with its relevant backups. The generation count for this key is:


The generation count is also included in the Admin Key Part filename, which is attached to the email. The attachment name is username_kc-ip-addr.key.gen#, where username is the Security Admin's KeyControl account name, kc-ip-addr is the KeyControl IP address from which the Admin Key was generated, and # is the generation count. For example, secroot_10.238.66.235.key.gen8. This same naming convention is used if a Security Admin downloads their Admin Key Part from the KeyControl webGUI.

If you want to restore KeyControl from a backup created when the Admin Key shown above was valid, you must make sure that all the Admin Key Parts you upload have generation count = 8.

External Admin Key Storage

You can also store the entire Admin Key on an external KMIP  (Key Management Interoperability Protocol) server or on a Hardware Security Module (HSM). If you select one of these options, you can restore the Admin key using either the parts sent to the Security Administrators or the entire key from the external key server (EKS).

This has the advantage that Security Admins do not need to worry about which Admin Key parts are required for which backup image. KeyControl automatically fetches the appropriate key from the EKS and no manual synchronization is needed.

For details about using an EKS, see Configuring KeyControl as a KMIP Client and Hardware Security Modules with KeyControl.