Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.raven.io/llms.txt

Use this file to discover all available pages before exploring further.

At Raven, we design all Helm charts for our platform to balance developer convenience in development environments with security best practices in production environments. This documentation explains how to manage and inject secrets into your Kubernetes clusters using Helm charts and various secrets management tools.

​
Secrets Management Overview

We support two primary methods for managing secrets in our platform:
  1. Directly Setting Secrets in Helm Charts: Suitable for development environments where convenience is prioritized.
  2. Using External Secrets Managers: Recommended for production environments to meet security best practices.

​
Method 1: Directly Setting Secrets in Helm Charts

You can directly set secrets in the Helm values file. This method is straightforward and suitable for development environments.

​
Method 2: Using External Secrets Managers

For production environments, we recommend using well-known secrets managers such as:
  • Hashicorp Vault Operator
  • External Secrets Operator
  • 1Password Connect
These tools allow you to securely load secrets into Kubernetes and reference them in your Helm charts.

​
Example: Configuring ingestion-service

The ingestion-service microservice requires the following parameters/values: 
ingestion-service:
  clickhouse:
    host: "clickhouse-host"
    port: "9000"
    tls: false
    user: "default"
    database: "default"
    password: "" # Leave empty to not use it and attach a pre-created secret using extraSecrets
  extraSecrets:
    - clickhouse-secret

​
Development Environment

In a development environment, you can hardcode the clickhouse password directly in the Helm values file and pass an empty extraSecrets array: 
ingestion-service:
  clickhouse:
    host: "clickhouse-host"
    port: "9000"
    tls: false
    user: "default"
    database: "default"
    password: "your-dev-password"
  extraSecrets: []

​
Production Environment

In a production environment, leave the password field empty and provide an extraSecrets element that references a pre-created Kubernetes secret: 
ingestion-service:
  clickhouse:
    host: "clickhouse-host"
    port: "9000"
    tls: false
    user: "default"
    database: "default"
    password: ""
  extraSecrets:
    - clickhouse-secret
Here, clickhouse-secret is a Kubernetes secret loaded using your chosen secrets manager/operator.

​
Loading Secrets with a Secrets Manager

  1. Using Hashicorp Vault Operator Ensure you have the Vault Operator installed and configured in your Kubernetes cluster. First, store your secret in Vault: 
    vault kv put secret/clickhouse password=your-production-password
    Create a VaultSecret resource in Kubernetes: 
    apiVersion: "kubernetes-client.io/v1"
kind: ExternalSecret
metadata:
  name: clickhouse-secret
spec:
  backendType: vault
  data:
    - name: password
      key: secret/clickhouse
      property: password
  2. Using External Secrets Operator Install and configure the External Secrets Operator in your cluster. Define the external secret resource: 
    apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
  namespace: default
spec:
  provider:
    vault:
      server: "https://vault.example.com"
      path: "secret"
      version: "v2"
      auth:
        tokenSecretRef:
          name: vault-token
          key: token

    apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: clickhouse-secret
spec:
  secretStoreRef:
    name: vault-backend
  target:
    name: clickhouse-secret
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/clickhouse
        property: password
  3. Using 1Password Connect Configure 1Password Connect to sync your secrets with Kubernetes. Define the secret in 1Password and sync it with your cluster. First, create a Kubernetes secret for the 1Password Connect credentials: 
    apiVersion: v1
kind: Secret
metadata:
  name: op-connect
type: Opaque
data:
  token: <base64-encoded-token>
  url: <base64-encoded-url>
    Create an ExternalSecret resource: 
    apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: onepassword-backend
spec:
  provider:
    onePassword:
      url: "https://<1password-connect-url>"
      tokenSecretRef:
        name: op-connect
        key: token

    apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: clickhouse-secret
spec:
  secretStoreRef:
    name: onepassword-backend
  target:
    name: clickhouse-secret
  data:
    - secretKey: password
      remoteRef:
        key: <1password-vault-id>
        property: password

​
Injecting Secrets into Microservices

Most secrets in Raven Helm charts can be injected into microservices containers as environment variables. Ensure you define the required secrets in your Helm values file and use the appropriate method to manage them.

​
Conclusion

Managing secrets securely is crucial for the reliability and security of your applications. By following the methods outlined in this guide, you can ensure that your secrets are managed efficiently and securely in both development and production environments. For further assistance, refer to the Raven Documentation or contact support.