Customer credentials

This topic explains how Edge secures the credentials and secrets required to connect to different systems. It details the encryption standards used to protect sensitive data at rest and outlines the specific lifecycle management rules for different credential types, including rotation limitations for system secrets.

Note You can manage your data source secrets and credentials by using Vaults.

Credentials storage

Edge stores all sensitive data and encrypts it using the native k3s mechanism. Similarly, the native Edge encryption mechanism encrypts all user-entered credentials.

Secret encryption

For Virtual Machine or Bare Metal installations (k3s-based), the native Kubernetes mechanism encrypts all secrets. This mechanism encrypts the full cluster state, including secrets and ConfigMaps. The system uses the AES 128 encryption algorithm with CBC mode and PKCS#7 padding. You can verify the encryption status by running the following command: sudo /usr/local/bin/k3s secrets-encrypt status

Additionally, if you don't use vaults, k3s and k8s add an extra layer of AES 256 ecryption to any data at rest and not currently communicating from one node to another. For more information, go to the Kubernetes documentation Encrypting Confidential Data at Rest.

The /var/lib/rancher/k3s/server/db/state.db file stores the entire database, including the SQLite data.

Credential encryption

The Edge site-specific red public key additionally encrypts every value marked as To be encrypted by Edge management.

The encryption process follows this algorithm:

  1. A user enters sensitive text via the Web UI or REST API.
  2. The system places the text in a command queue for your Edge site to execute, similar to other commands like "run job" or "cancel job". The Edge site's polling mechanism picks up the text for execution and stores the Edge site credentials as a Kubernetes secret.
  3. The Edge management module retrieves the red public key for the specific site.
  4. The system generates a new AES 128 symmetric key (encryption key).
  5. The system uses the encryption key to encrypt the sensitive text.
  6. The system encrypts the encryption key itself using the red public key.
  7. The system concatenates the encrypted encryption key and encrypted text, then encodes them using Base64 encoding to form the Edge secret.
  8. The system sends the Edge secret directly to the Edge site, which stores it as a Kubernetes secret.

In short, the system uses the following algorithms:

  • RSA 2048 in EBC mode and PKCS#1 padding
  • AES 128 in EBC mode and PKCS#7 padding

Credentials transfer

When the Collibra server (Edge management module) has encrypted the credentials, they are sent to the Edge site using the HTTP TLS 1.3 protocol.

Collibra platform credentials

Apart from the credentials that users need to enter in order to connect to the data sources, there are also credentials which are needed to access the Collibra server itself.

These credentials include:

Credential type Details
Collibra server credentials

If you installed your Edge site before 2025.08, or use Collibra Platform for Government or Collibra Platform Self-Hosted, your Collibra server uses username and password authentication, stored in the dgc-secret Secret.

You can rotate these credentials by using the script: edge update-dgc-cred

If you installed your Edge site with 2025.08 or later, your Collibra server uses OAuth authentication.
Datadog API key

Stored in the datadog-secret Secret.

Rotation is currently not possible. You have to reinstall Edge.
JFrog credentials

Stored in the collibra-edge-repo-creds Secret.

Rotation is currently not possible. You have to reinstall Edge.

The JFrog credentials are also stored in the /etc/rancher/k3s/registries.yaml file for K3S-based installations

Note This file is unencrypted, but it is only accessible by a root user.