Secret Management - ResolveAI

The Resolve Satellite uses two types of secrets:

Ingest Token: Authenticates the Satellite over an encrypted channel
Integration Tokens: Authenticate with on-premises data sources (e.g., Grafana, Elasticsearch, Splunk)

For security best practice, use Kubernetes secrets and encrypt etcd at rest. The satellite automatically mounts these secrets as files in the pod at /etc/secrets/<secret-name>/. The raw secret values are never exposed to Resolve’s Cloud and stay strictly within the walls of your Satellite deployment. They are used to authenticate with on-premises data sources.

Security Recommendation for Production EnvironmentsWe recommend using secret management solutions already approved by your security team.In order to ensure that secrets are properly encrypted and managed according to enterprise security standards:

If you use Kubernetes Secrets as your secret management solution, encrypt etcd at rest. Encrypting data at rest protects secret data stored in the cluster.
Alternatively, integrate with external secrets management systems like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager using controllers like External Secrets Operator.

Choose Your Setup Method

Select the approach that matches your environment and security requirements: Setup Ingest Token:

Kubernetes Secrets: Ingest Token with Kubernetes Secret - If you use native Kubernetes secrets
External Secrets Manager: Ingest Token with External Secrets Manager - If you use AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or similar

Setup Tokens for Your Integrations: See Integration Token Configuration to connect on-premises data sources.

Configuring Your Ingest Token

The Satellite requires an ingest token to authenticate with the Resolve backend. Choose one of the following methods based on your environment.

Ingest Token with Kubernetes Secret

This method stores your ingest token as a native Kubernetes secret, keeping it separate from your configuration files.

Step 1: Create the Secret

Create a Kubernetes secret containing your ingest token:

Create secret

kubectl create secret generic resolve-satellite-token --from-literal=token=<your-resolve-satellite-token>

Step 2: Reference in Values File

Reference the secret in your resolve-values.yaml:

resolve-values.yaml

ingest:
  tokenSecretName: resolve-satellite-token

clusterName: <your cluster name>
environment: <your environment>

Security Best PracticeThis values file should be applied by a cluster admin and should not be checked into version control systems. Use your organization’s secure deployment practices for managing Helm values files.

The Satellite will automatically read the token from the secret at runtime.

Ingest Token with External Secrets Manager

For enterprise environments using external secrets managers. This method integrates with AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or other providers via the Secrets Store CSI Driver.

Prerequisites

Secrets Store CSI Driver installed in your cluster
Secret named resolve-satellite-token created in your secrets manager with the ingest token value

Step 1: Create Secret Provider Class

Create a secret-provider-class.yaml file configured for your secrets provider. Refer to the Secrets Store CSI Driver documentation for provider-specific configuration.

secret-provider-class.yaml

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: resolve-satellite-secrets
spec:
  provider: <your-provider>  # aws, azure, gcp, vault, etc.
  parameters:
    # Provider-specific parameters - see your provider's documentation

Step 2: Apply the Secret Provider Class

kubectl apply -f secret-provider-class.yaml

Step 3: Configure Values File

Configure your resolve-values.yaml to use the external secrets:

resolve-values.yaml

ingest:
  providerSecretName: resolve-satellite-token

clusterName: <your cluster name>
environment: <your environment>

externalSecretsStore:
  secretProviderClass: resolve-satellite-secrets

Note: The token will be mounted from /mnt/secrets-store/resolve-satellite-token. Ensure your secret contains the token value in plain text or as a JSON object with a token key.

Integration Token Configuration

Integration tokens authenticate the Satellite with on-premises data sources like Grafana, Elasticsearch, Splunk, and others. The setup pattern is similar to ingest tokens—you create a Kubernetes secret, then reference it in your values file.

Step 1: Create the Kubernetes Secret

Create a secret containing your integration credentials. Most integrations need only an API token:

Create integration secret

kubectl create secret generic <secret-name> --from-literal=token="<your-api-token>"

Example for Logz.io:

kubectl create secret generic logz-token --from-literal=apiToken="your-logz-token"

For integrations requiring multiple credentials (username/password, multiple keys), use multiple --from-literal flags. See Kubernetes Secret Operations below for more examples.

Step 2: Configure Integration in Values File

Reference the secret in your resolve-values.yaml file. See the Reference Schema for integration-specific connection parameters.

resolve-values.yaml

integrations:
  <integration-name>:
    type: "<integration-type>"
    create: true
    secretName: <secret-name>
    connection:
      # See integration-specific documentation for connection parameters

Example for Logz.io:

resolve-values.yaml

integrations:
  logzio:
    type: "logzio"
    create: true
    secretName: logz-token
    connection:
      url: api.logz.io

The Helm chart includes a file watcher that automatically detects integration updates, removing the need to manually restart the Satellite after each change. See Install the Resolve Satellite for deployment instructions.

Reference: Kubernetes Secret Operations

This section provides reference commands for creating and managing Kubernetes secrets.

Creating Secrets

Create a secret with a single key:

Single key secret

kubectl create secret generic <secret-name> --from-literal=<key>="<your-token>"

Create a secret with multiple keys:

Multiple key secret

kubectl create secret generic <secret-name> \
  --from-literal=<key1>="<value1>" \
  --from-literal=<key2>="<value2>"

Resulting Secret:

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: <secret-name>
type: Opaque
data:
  <key>: <value>  # base64 encoded value

Verifying Secrets

Check if your secret exists:

Check secret

kubectl get secret <secret-name>

Verify secret contents (be careful with sensitive data):

Verify contents

kubectl get secret <secret-name> -o jsonpath='{.data.<key>}' | base64 -d

​Choose Your Setup Method

​Configuring Your Ingest Token

​Ingest Token with Kubernetes Secret

​Step 1: Create the Secret

​Step 2: Reference in Values File

​Ingest Token with External Secrets Manager

​Prerequisites

​Step 1: Create Secret Provider Class

​Step 2: Apply the Secret Provider Class

​Step 3: Configure Values File

​Integration Token Configuration

​Step 1: Create the Kubernetes Secret

​Step 2: Configure Integration in Values File

​Reference: Kubernetes Secret Operations

​Creating Secrets

​Verifying Secrets

Choose Your Setup Method

Configuring Your Ingest Token

Ingest Token with Kubernetes Secret

Step 1: Create the Secret

Step 2: Reference in Values File

Ingest Token with External Secrets Manager

Prerequisites

Step 1: Create Secret Provider Class

Step 2: Apply the Secret Provider Class

Step 3: Configure Values File

Integration Token Configuration

Step 1: Create the Kubernetes Secret

Step 2: Configure Integration in Values File

Reference: Kubernetes Secret Operations

Creating Secrets

Verifying Secrets