Reporting and logs

View KeySafe 5 logs

You can view logs for the central KeySafe 5 platform and the KeySafe 5 Agent from the command line on the KeySafe 5 cluster.

Logs for the central KeySafe 5 platform

The central KeySafe 5 platform application is configured to log to stdout. You can view logs by running standard kubectl commands.

For example, to get the KeySafe 5 backend services logs:

$ kubectl logs -n nshieldkeysafe5 nshield-keysafe5-0 hsm-mgmt
$ kubectl logs -n nshieldkeysafe5 nshield-keysafe5-0 sw-mgmt

To get the KeySafe 5 UI logs:

$ UI_POD=$(kubectl -n nshieldkeysafe5 get pods -l app=keysafe5-ui-app -o jsonpath='{.items[0].metadata.name}')
$ kubectl logs -n nshieldkeysafe5 $UI_POD

Because all logs are directed to stdout, you can integrate the application logs with third-party log monitoring tools such as Prometheus or Splunk. This integration is beyond the scope of this document.

Logs for the KeySafe 5 Agent

On Linux-based systems, the KeySafe 5 Agent log file is located at /opt/nfast/log/keysafe5-agent.log, unless configured otherwise.

On Windows-based systems:

  • The KeySafe 5 agent log file is located at C:\ProgramData\nCipher\Log Files\KeySafe5-agent.log, unless configured otherwise.

  • The KeySafe 5 Windows Service actions are emitted to the Windows event log under the nShieldKeySafe5 source identifier.

You can use the nshieldeventlog utility to extract these log entries and output them to the console or a text file. For example:

nshieldeventlog.exe --source=nShieldKeySafe5

As required, specify:

  • -c | --count: The number of records read from the event log.
    The default is 10000.

  • -f | --file: The output filename.

See the nShield Security World Software documentation for more information on the nshieldeventlog utility.

Resource health measurements

Many of the resource pages in KeySafe 5 include health measurements.

Liveness checks

The central platform receives updates from KeySafe 5 agents on host machines and HSMs. These updates are used to determine how recently the central platform communicated with the resource.

A resource is considered to be "live" if it has been communicated with during a pre-configured liveness interval.

For example, if the central platform last communicated with an HSM at 12:00:00 and there is a configured liveness interval of 5 minutes:

  • API requests up to 12:05 will have a healthy liveness check

  • API requests after 12:05 will have a failing liveness check.

To configure the liveness interval, see the KeySafe 5 Installation Guide.

The liveness check behaves according to the following table:

Health Status Host Agent Connect Agent

Healthy

Live

Live

Not Live

Live

Warning

Live

Not Live

Failure

Not Live

Not Live

HSM Management Service

The following health measurements relate to HSM management.

Measurement Description

liveness

This check passes if the resource has been communicated with during the last health interval.

The time returned in the liveness check is the time at which the check was performed.

See Liveness checks.

hardwareStatus

This check passes if the hardware status of the HSM is "OK".

Check omitted if the HSM does not support reporting its hardware status.

remoteConnectionStatus

This check passes if the remote connection status of the HSM is "OK".

Check only valid for Host Health when a Hardserver is configured with a remote module.

hsmQuorum

This check is used for Pool health.

  • pass indicates all HSMs in the Pool are healthy.

  • warn indicates at least one HSM in the Pool is healthy, but not all HSMs in the Pool are healthy.

  • fail indicates all HSMs in the Pool are unhealthy, or there are no HSMs in the Pool.

clockSkew

This check is used for Host health.

It passes if the clock on this host is different by no more than the allowed clock skew from the clock on the machine running the HSM Management service.

It takes into consideration different time zones between the host machine and the central platform.

The allowed clock skew is configurable in the central platform, see the KeySafe 5 Installation Guide.

Security World Management Service

The following health measurements relate to Security World management.

Measurement Description

liveness

This check passes if the resource has been communicated with during the last health interval.

The time returned in the liveness check is the time at which the check was performed.

See Liveness checks.

poolHealthStatus

This check is used for Authorized Pool health and returns the overall health status of a HSM Pool. This is returned by the HSM Management service API endpoint.

hsmUsableQuorum

This check is used for Authorized Pool health:

  • pass indicates that all HSMs in the Authorized Pool are currently in a "Usable" module state by the Security World that the Pool is authorized to use.

  • warn indicates that at least one HSM in the Pool is not in "Usable" module state.

  • fail indicates that no HSMs in the Pool are in "Usable" module state.