Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

Security

The Security tab provides an audit trail of all API activity on the system and manages bearer tokens for programmatic access.

Overview​

The tab has two independent sections:

  • API Security Audit Log — shows every HTTP request the backend has received: who made it, what they did, and whether it succeeded.
  • API Token Management — creates long-lived bearer tokens for automation scripts or CI/CD pipelines that call the API without an interactive session.

API Security Audit Log​

The audit log is a paginated table of every API call made to the console backend. Use it to investigate configuration changes, detect unexpected access, and confirm that automation is behaving as intended.

ColumnDescription
TimestampThe date and time the backend received the request, in UTC.
MethodThe HTTP method of the request, such as GET, POST, PUT, or DELETE.
PathThe request path, for example /api/settings/clusters. Query parameters are included where present.
Status CodeThe HTTP response code. 200 or 201 indicates success, 401 or 403 an authentication or authorization failure, and 500 a backend error.
IP AddressThe source IP of the caller. In Kubernetes deployments behind a load balancer or ingress, this may be the cluster-internal IP rather than the originating client IP.
UsernameThe authenticated user or token name for the request. Unauthenticated requests show as anonymous.
DurationThe time in milliseconds the backend took to process the request.

The log records all requests, including health checks and read-only polling. High-volume sources such as agents that send frequent heartbeats add many rows, so filter by path to reduce noise when investigating specific events.

Export to CSV​

Export to CSV downloads the audit log as a comma-separated values file. Use it for compliance reporting, offline analysis, or archiving before you clear the log.

note

The audit log retains up to 1,000,000 entries. When the limit is reached, the oldest records are trimmed automatically. The CSV export contains the log as it is at the time of download, so it may not include every record ever written.

Clear Log​

Clear Log permanently deletes all API audit log entries. A confirmation dialog appears first. There is no recycle bin or recovery path, so export the log first if you need to keep a history.

API Token Management​

API tokens are long-lived bearer tokens for programmatic access to the console API. They are an alternative to session-cookie authentication for non-interactive callers.

  • Token Name — a human-readable label for the token. Use names that identify the caller, such as ci-pipeline.
  • Scope — every token created here has full access to the API, the same as a signed-in administrator: it can read and change settings and start jobs. The token list shows this scope as API.
  • Create Token — generates a token with the given name. The full token value is shown once, in the creation dialog. Copy it immediately, because it cannot be retrieved after you close the dialog.
  • Revoke Token — permanently invalidates a token. Any caller that uses it receives a 401 response from then on. Revoke tokens that are no longer needed or that may have been compromised.

Every token has full API access, so treat it like an administrator password: give each caller its own token, and revoke any token that may have leaked. If a token value is lost, revoke the token and create a new one.

Quantum Signed Keys​

This section is visible only when Quantum Trust Signed (QTS) delivery is available on your installation. It shows the post-quantum cryptographic keys used for QTS software delivery.

Trusted Superna Signing Keys (ML-DSA-87)​

The table lists every Superna-issued signing key loaded by this console. A QTS package must be signed with one of these keys to be accepted for installation.

ColumnDescription
Key IDThe unique identifier embedded in the .qtspkg package manifest. The console uses it to find the correct public key during validation.
AlgorithmAlways ML-DSA-87 (CRYSTALS-Dilithium Level 5), a post-quantum digital signature algorithm that is secure against both classical and quantum computer attacks.
StandardThe NIST standard the key implements, for example NIST FIPS 204.
StatusACTIVE for production keys. A yellow DEV badge appears when the console generated a keypair automatically in development mode because no production signing keys were found in /data/superna-signing-keys/.

If no signing keys are shown, contact Superna to obtain the current public key set, and place the keys in /data/superna-signing-keys/ on the server. Without a trusted key, QTS uploads fail with UNKNOWN_SIGNING_KEY.

System Public Key (ML-KEM-1024)​

This is the console's post-quantum delivery identity keypair. It is generated once per installation and stored encrypted on the PVC. It is used for Quantum Customer Encrypted (QCE) deliveries, in which Superna encrypts a package exclusively for this installation so that no other system can install it.

  • Fingerprint — a short identifier derived from the SHA-256 hash of the public key. Share it with Superna to confirm that you have the right key.
  • Algorithm — always ML-KEM-1024 (CRYSTALS-Kyber Level 5, NIST FIPS 203).
  • Copy Public Key — copies the Base64-encoded public key to the clipboard. Share it with Superna when you request a customer-encrypted delivery.
  • Download PEM — downloads the public key as a PEM file, for secure out-of-band transmission such as email or a support ticket to Superna.

The private half of the keypair never leaves the server. Even Superna cannot decrypt a QCE delivery intended for a different installation.

Workflows​

Investigate a suspicious configuration change​

  1. Open the Security tab and go to the API Security Audit Log section.
  2. Filter or search by the path of the endpoint that was called, for example /api/settings.
  3. Check the Timestamp, Username, and IP Address columns to identify who made the change and when.
  4. If the IP address or username is unexpected, revoke any API tokens that may have been compromised.

Export the audit log for compliance review​

  1. Click Export to CSV.
  2. Open the downloaded file in a spreadsheet application or import it into your compliance tool.

Clear the audit log after archiving​

  1. Click Export to CSV and confirm that the download is complete.
  2. Click Clear Log.
  3. Confirm the deletion in the dialog.

Tips​

  • In Kubernetes, configure the ingress or load balancer to forward the X-Forwarded-For header so that the recorded IP address is the true client IP rather than the cluster-internal hop.