Learn Velero - Backup Encryption & Object Storage Security

#Introduction

In episode 13 you secured the safe's key (credentials). Episode 14 secures the contents of the safe itself. The point that often surprises: a Velero backup contains raw Kubernetes Secrets — database passwords, API tokens, even TLS keys. Anyone who manages to read your bucket, or steals a disk snapshot, gets all those secrets.

That's why encryption isn't optional — it's the last line of defense. Imagine secret archives stored in a plain folder vs a locked folder. Velero + unencrypted object storage is the plain folder: safe as long as nobody touches it, wide open the moment someone does.

#Encryption in Object Storage

#Server-Side Encryption (SSE)

Always enable server-side encryption at the bucket level — data is encrypted at rest and automatically decrypted when Velero reads it:

aws s3api put-bucket-encryption --bucket velero-backups \
  --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "aws:kms"}}]
  }'

Two common options:

• SSE-S3 (AES256): encryption by S3, no KMS cost, no key control.
• SSE-KMS: keys managed by KMS — you can restrict, audit, and disable the key if it's stolen.

#Encryption on GCS and Azure

• GCS: enable kmsKeyName on the bucket, or default encryption with customer-managed keys.
• Azure Blob: encryption is enabled by default (storage service encryption); for full control use customer-managed keys in Key Vault.

#Volume Snapshot Encryption

#EBS Snapshots with KMS

Cloud volume snapshots can also be encrypted. For the AWS plugin, set kmsKeyId in the VSL configuration:

apiVersion: velero.io/v1
kind: VolumeSnapshotLocation
metadata:
  name: default
  namespace: velero
spec:
  provider: aws
  config:
    region: us-east-1
    kmsKeyId: arn:aws:kms:us-east-1:123456789012:key/abc123

Every EBS snapshot Velero creates is now encrypted with that KMS key — and can only be read with the same permissions.

#Kopia/Restic Repository Encryption

File-level backups (kopia) are always encrypted by their repository — the key is created automatically when the repository is first created and stored as a kopia-repo-* Secret in the velero namespace. Never delete this repository Secret; without the key, the data can't be decrypted.

View kopia repository Secrets

kubectl get secrets -n velero -l velero.io/repository-type=kopia

#TLS to the S3 Endpoint

#HTTPS for All Endpoints

An absolute rule: object storage must be accessed via HTTPS in any environment except a lab. MinIO in a lab may use http://, but production (including internal MinIO) must use TLS:

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: minio-prod
  namespace: velero
spec:
  provider: aws
  objectStorage:
    bucket: velero
    prefix: backups
    caCertRef:
      name: minio-ca
      key: ca.crt
  config:
    region: minio
    s3ForcePathStyle: "true"
    s3Url: https://minio.internal:443

caCertRef points to a Secret containing the internal CA (Velero 1.18 supports Secret-based CA on BSL) — for MinIO endpoints using internal self-signed certificates.

#NetworkPolicy for Velero

#Restricting Communication

On clusters with network policies enabled, Velero components should only communicate with what they need: the API server and the external object storage endpoint.

Egress NetworkPolicy for velero-server

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: velero-egress
  namespace: velero
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: velero
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
      ports:
        - protocol: TCP
          port: 443
        - protocol: TCP
          port: 6443
    - to:
        - ipBlock:
            cidr: 10.0.0.0/16
      ports:
        - protocol: TCP
          port: 443

Note: the ipBlock entry is a placeholder for your object storage CIDR — adjust it to your network. The policy above restricts Velero's outbound traffic to the API server and object storage only.

#Backup Security Checklist

• S3/GCS bucket with SSE enabled (ideally SSE-KMS).
• EBS snapshots use kmsKeyId in the VSL.
• All object storage endpoints are HTTPS (except labs).
• Kopia repository Secrets are never deleted.
• NetworkPolicy restricts Velero component egress.
• Periodic key rotation and bucket access audit.

#Closing

Key takeaways:

• Backups contain raw Secrets — storage encryption is the last line of defense.
• SSE-S3/AES256 or SSE-KMS at the bucket level; make sure IAM is allowed to use the KMS key.
• EBS snapshots are encrypted via kmsKeyId in the VSL.
• Kopia/restic repositories are always encrypted; don't delete the repository Secrets.
• Use HTTPS (with caCertRef for internal CAs) and NetworkPolicies to restrict communication.

In episode 15 next, we build Backup Policies & Compliance — immutability with object lock, per-policy compliance retention, and audit via server logs and backup/restore events.