Installing and configuring Velero — install paths, credentials, and namespace selection

Velero is installed with the velero install command, which deploys the controller, the credentials Secret, the BackupStorageLocation (BSL), and optionally the VolumeSnapshotLocation (VSL) and the Restic/Kopia DaemonSet. This lesson walks the install path, the credentials, the BSL and VSL, and the validation that must follow before any production backup is trusted.

The install command

velero install \
  --provider aws \
  --bucket velero-backups \
  --prefix prod-cluster \
  --secret-file ./credentials-velero \
  --use-restic \
  --use-volume-snapshots=true \
  --backup-location-config region=us-east-1,sse=aws:kms,sseAwsKmsKeyId=arn:aws:kms:us-east-1:123:key/abcd \
  --snapshot-location-config region=us-east-1 \
  --namespace velero

The flags:

The credentials file

The --secret-file is a Kubernetes Secret manifest containing the cloud credentials:

apiVersion: v1
kind: Secret
metadata:
  name: velero-credentials
  namespace: velero
type: Opaque
stringData:
  cloud: |
    [default]
    aws_access_key_id = AKIA...
    aws_secret_access_key = ...

The Secret is consumed by the Velero controller’s ServiceAccount. The controller mounts the Secret as a volume and reads the credentials when it needs to talk to S3. Rotating the credentials requires updating the Secret and restarting the Velero Deployment.

BackupStorageLocation and VolumeSnapshotLocation

flowchart LR
    A[velero install] --> B[BackupStorageLocation]
    A --> C[VolumeSnapshotLocation]
    B --> D[Object storage plugin]
    C --> E[CSI snapshot plugin]
    D --> F[S3 bucket]
    E --> G[CSI driver]

BSL and VSL are CRDs that configure the destinations:

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: default
  namespace: velero
spec:
  provider: aws
  objectStorage:
    bucket: velero-backups
    prefix: prod-cluster
  config:
    region: us-east-1
    sse: aws:kms
    sseAwsKmsKeyId: arn:aws:kms:us-east-1:123:key/abcd
---
apiVersion: velero.io/v1
kind: VolumeSnapshotLocation
metadata:
  name: default
  namespace: velero
spec:
  provider: aws
  config:
    region: us-east-1

A cluster can have multiple BSLs and VSLs; the velero backup create --storage-location <name> flag selects which one to use. This is how multi-cloud or multi-region backups are configured.

RBAC and ServiceAccount

Velero runs with a dedicated ServiceAccount in its namespace. The default install creates:

• A ClusterRole granting Velero full access to every API resource (read for backup, create for restore).
• A ClusterRoleBinding binding the ClusterRole to the Velero ServiceAccount.
• A ServiceAccount in the Velero namespace.

For production, the default RBAC is excessive. A production install restricts Velero to the namespaces it should back up, using a Role and RoleBinding per namespace instead of a ClusterRole. The trade-off is convenience (one install) vs security (Velero can read every secret in the cluster).

Validating the install

Three tests must pass before trusting the install:

# 1. The BSL is Available
velero backup-location get

# 2. A test backup completes
velero backup create test-install --include-cluster-resources=true
velero backup get
# Wait for Phase: Completed

# 3. A test restore works
velero restore create --from-backup test-install
velero restore get
# Wait for Phase: Completed

# 4. Cleanup
RESTORE=test-install-20260818150405   # name from `velero restore get`
velero backup delete test-install
velero restore delete "$RESTORE"

If any of these fail, the install is broken and scheduled backups will fail in the same way. The validation is part of the install procedure, not a nice-to-have.

The operational failure modes

Install fails in production for predictable reasons:

• Credentials missing or wrong. The Secret is not present, or the keys do not have access to the bucket. The install completes but the BSL stays Unavailable.
• Bucket region mismatch. The credentials are for us-east-1 but the bucket is in us-west-2. The controller logs show region errors.
• Plugin not installed. --provider aws requires the AWS plugin binary. If the Velero image does not include the plugin, the BSL stays Unavailable.
• RBAC insufficient. The Velero ServiceAccount lacks permission to read Secrets or to create VolumeSnapshots. Backups fail with permission errors.
• CSI driver missing. --use-volume-snapshots=true requires a CSI driver that supports snapshots. If the driver does not, backups fall back to Restic but the VSL stays Unavailable.

Quiz

Production discipline

Velero install in production rests on five non-negotiable elements:

• Validate in staging first. Install Velero in a staging cluster and run the three tests before installing in production. The production install is not a place to discover credential or bucket issues.
• Use a dedicated namespace. Velero’s namespace contains the controller, the credentials Secret, and the BSL/VSL CRDs. It should not contain application workloads.
• Restrict RBAC for sensitive environments. The default ClusterRole grants Velero access to every Secret. PCI/HIPAA deployments restrict Velero to per-namespace RBAC and run multiple installs.
• Rotate credentials through the Secret. When the cloud keys rotate, update the Secret and restart the Deployment. Do not put the credentials in a ConfigMap.
• Run a periodic restore test. The install is validated once and then assumed. Quarterly restore tests prove the install still works.

Velero install is production infrastructure. Treating it as a one-time setup means the next disaster discovers the install was broken the day it shipped.