Configuration¶

This guide covers the essential configuration needed to get Velero Dashboard running.

Configuration Files¶

Velero Dashboard uses two main configuration files that support hot-reloading:

1. Cluster Configuration (`config/clusters.yaml`)¶

Defines the Kubernetes clusters you want to manage.

2. Permission Policies (`config/casbin_policy.csv`)¶

Defines who can access what resources using Casbin RBAC.

Cluster Configuration¶

File Location¶

config/clusters.yaml

Basic Example¶

clusters:
  - name: dev-cluster
    description: Development Environment
    environment: development
    api_server: https://k8s-dev.example.com:6443
    auth_method: kubeconfig
    kubeconfig_path: /path/to/kubeconfig
    is_active: true

  - name: prod-cluster
    description: Production Environment
    environment: production
    api_server: https://k8s-prod.example.com:6443
    auth_method: token
    token: "eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9..."
    certificate_authority_data: "LS0tLS1CRUdJTi..."
    is_active: true

Configuration Fields¶

Field	Required	Description
`name`	Yes	Unique cluster identifier
`description`	Yes	Human-readable description
`environment`	Yes	Environment tag (dev, staging, production, etc.)
`api_server`	Yes	Kubernetes API server URL
`auth_method`	Yes	Authentication method: `kubeconfig` or `token`
`is_active`	Yes	Enable/disable this cluster
`kubeconfig_path`	If kubeconfig	Path to kubeconfig file
`context_name`	No	Specific context to use from kubeconfig
`token`	If token	Service account bearer token
`certificate_authority_data`	If token	Base64 encoded CA certificate

Authentication Methods¶

Method 1: Kubeconfig¶

Best for local development or when kubeconfig files are mounted into containers.

clusters:
  - name: my-cluster
    description: My Cluster
    environment: development
    api_server: https://kubernetes.default.svc
    auth_method: kubeconfig
    kubeconfig_path: ~/.kube/config
    context_name: my-context  # optional, uses current context if not specified
    is_active: true

Method 2: Service Account Token¶

Best for production deployments in Kubernetes.

clusters:
  - name: remote-cluster
    description: Remote Production Cluster
    environment: production
    api_server: https://k8s.example.com:6443
    auth_method: token
    token: "eyJhbGciOiJSUzI1NiIsImtpZCI6..."
    certificate_authority_data: "LS0tLS1CRUdJTi..."
    is_active: true

Getting Token and CA Data:

# Get service account token
kubectl get secret <service-account-token-secret> -n <namespace> -o jsonpath='{.data.token}' | base64 -d

# Get CA certificate
kubectl get secret <service-account-token-secret> -n <namespace> -o jsonpath='{.data.ca\.crt}'

Hot-Reload¶

The cluster configuration file is watched for changes and automatically reloaded when modified. No restart required!

# Edit the file
vim config/clusters.yaml

# Changes are picked up automatically within seconds
# Check logs to confirm: "Cluster configuration reloaded"

Permission Configuration¶

File Location¶

config/casbin_policy.csv

Casbin Model¶

Velero Dashboard uses a domain-based RBAC model with the following format:

Domain: <cluster>:<namespace>:<environment>
Object: Resource type (backup, restore, schedule, etc.)
Action: Permission (view, list, create, delete, logs)

Basic Example¶

# Define role permissions
p, velero.admin, *, *, .*
p, velero.operator, *, backup, (view|list|create|delete|logs)
p, velero.operator, *, restore, (view|list|create|logs)
p, velero.operator, *, schedule, (view|list|create|delete)
p, velero.viewer, *, *, (view|list|logs)

# Assign roles to users
g, admin@example.com, velero.admin
g, devops@example.com, velero.operator
g, john@example.com, velero.viewer

Policy Syntax¶

Permission Rules (p)¶

Format: p, <role>, <domain>, <object>, <action>

# Admin can do everything on all domains
p, velero.admin, *, *, .*

# Operator can manage backups on all domains
p, velero.operator, *, backup, (view|list|create|delete|logs)

# Viewer can only view on production environment
p, velero.viewer, *:*:production, *, (view|list)

# Dev team can only access dev-cluster
p, dev.team, dev-cluster:*:*, *, (view|list|create|delete)

Role Assignments (g)¶

Format: g, <user>, <role>

# Assign user to role
g, alice@example.com, velero.admin
g, bob@example.com, velero.operator
g, charlie@example.com, velero.viewer

# User can have multiple roles
g, alice@example.com, velero.admin
g, alice@example.com, special.admin

Domain Patterns¶

Domains use the format cluster:namespace:environment and support wildcards:

Pattern	Matches
`*`	Everything
`prod-cluster::`	All namespaces/envs in prod-cluster
`:velero:`	Velero namespace in all clusters
`::production`	All production environments
`prod-::*`	All clusters starting with "prod-"
`prod-cluster:app-:`	Namespaces starting with "app-" in prod-cluster

Action Patterns¶

Actions support regex matching:

Pattern	Matches
`.*`	All actions
`(view\|list)`	Only view and list
`(view\|list\|create)`	View, list, and create
`delete`	Only delete

Common Permission Scenarios¶

1. Super Admin¶

Full access to everything:

p, velero.admin, *, *, .*
g, admin@example.com, velero.admin

2. Environment-Specific Admin¶

Admin access only to production:

p, prod.admin, *:*:production, *, .*
g, prod-admin@example.com, prod.admin

3. Read-Only Viewer¶

Can only view and list, cannot create or delete:

p, velero.viewer, *, *, (view|list|logs)
g, viewer@example.com, velero.viewer

4. Backup Operator¶

Can manage backups and restores but not schedules or configurations:

p, backup.operator, *, backup, (view|list|create|delete|logs)
p, backup.operator, *, restore, (view|list|create|logs)
g, backup-team@example.com, backup.operator

5. Namespace-Specific Access¶

Access limited to specific namespaces:

p, app.team, *:myapp-*:*, backup, (view|list|create|delete)
p, app.team, *:myapp-*:*, restore, (view|list|create)
g, app-team@example.com, app.team

6. Cluster-Specific Access¶

Access limited to specific clusters:

p, dev.team, dev-cluster:*:*, *, .*
p, staging.team, staging-cluster:*:*, *, .*
g, developers@example.com, dev.team
g, qa-team@example.com, staging.team

Hot-Reload¶

Like cluster configuration, permission policies are automatically reloaded when the file changes:

# Edit policies
vim config/casbin_policy.csv

# Add new user or change permissions
# Changes take effect immediately (within seconds)
# Check logs: "Policy file changed, reloading enforcer"

Environment Variables¶

Required Variables¶

# Flask secret key (must be random and secret!)
SECRET_KEY="your-random-secret-key-at-least-32-characters"

# OIDC configuration
OIDC_CLIENT_ID="velerodashboard"
OIDC_CLIENT_SECRET="your-oidc-client-secret"
OIDC_DISCOVERY_URL="https://dex.example.com/dex"

Optional Variables¶

# Flask environment
FLASK_ENV="production"  # or "development"
FLASK_DEBUG="False"     # Set to "True" for development only

# Application URL
APP_URL="https://velerodash.example.com"

# OIDC settings
OIDC_VERIFY_SSL="True"   # Set to "False" for self-signed certs (dev only)
USE_DEX_PROXY="False"    # Set to "True" to use built-in Dex proxy

# Dex proxy (if USE_DEX_PROXY=True)
DEX_BASE_URL="http://dex.dex-system.svc.cluster.local:5556/dex"

# Pagination
DEFAULT_ITEMS_PER_PAGE="100"

# Kopia (for repository browsing)
KOPIA_BIN="/usr/local/bin/kopia"

Generating SECRET_KEY¶

# Python method
python -c 'import secrets; print(secrets.token_hex(32))'

# OpenSSL method
openssl rand -hex 32

# Using /dev/urandom
head -c 32 /dev/urandom | base64

Docker Configuration¶

When using Docker, mount configuration files:

docker run -d \
  --name velerodashboard \
  -p 8000:8000 \
  -e SECRET_KEY="$(openssl rand -hex 32)" \
  -e OIDC_CLIENT_ID="velerodashboard" \
  -e OIDC_CLIENT_SECRET="secret" \
  -e OIDC_DISCOVERY_URL="https://dex.example.com/dex" \
  -v $(pwd)/config:/app/config:ro \
  velerodashboard:latest

Kubernetes Configuration¶

When using Helm, configuration goes in values.yaml:

dashboard:
  config:
    secretKey: ""  # Auto-generated if empty

    oidc:
      clientId: velerodashboard
      clientSecret: your-secret
      discoveryUrl: https://dex.example.com/dex

    clusters:
      - name: my-cluster
        description: My Cluster
        environment: production
        # ... cluster config ...

    casbin:
      policies: |
        p, velero.admin, *, *, .*
        g, admin@example.com, velero.admin

Verification¶

Check Cluster Connectivity¶

# View logs
docker logs velerodashboard
# OR
kubectl logs -n velero-dashboard -l app=velerodashboard

# Look for:
# "Loaded 2 clusters from configuration"
# "Successfully connected to cluster: dev-cluster"

Check Permissions¶

Log in to the dashboard
Navigate to Profile page
Check "Roles" section to see assigned roles
Try accessing different features to verify permissions

Test Hot-Reload¶

# Edit a config file
echo "# Test comment" >> config/clusters.yaml

# Check logs for reload message
tail -f /var/log/velerodashboard.log
# Should see: "Cluster configuration file changed, reloading..."

Configuration¶

Configuration Files¶

1. Cluster Configuration (config/clusters.yaml)¶

2. Permission Policies (config/casbin_policy.csv)¶

Cluster Configuration¶

File Location¶

Basic Example¶

Configuration Fields¶

Authentication Methods¶

Method 1: Kubeconfig¶

Method 2: Service Account Token¶

Hot-Reload¶

Permission Configuration¶

File Location¶

Casbin Model¶

Basic Example¶

Policy Syntax¶

Permission Rules (p)¶

Role Assignments (g)¶

Domain Patterns¶

Action Patterns¶

Common Permission Scenarios¶

1. Super Admin¶

2. Environment-Specific Admin¶

3. Read-Only Viewer¶

4. Backup Operator¶

5. Namespace-Specific Access¶

6. Cluster-Specific Access¶

Hot-Reload¶

Environment Variables¶

Required Variables¶

Optional Variables¶

Generating SECRET_KEY¶

Docker Configuration¶

Kubernetes Configuration¶

Verification¶

Check Cluster Connectivity¶

Check Permissions¶

Test Hot-Reload¶

Next Steps¶

1. Cluster Configuration (`config/clusters.yaml`)¶

2. Permission Policies (`config/casbin_policy.csv`)¶