velero-plugin-for-openstack

packaged by Chainguard

Chainguard Container for velero-plugin-for-openstack

OpenStack Cinder, Manila, and Swift plugin for Velero backups

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/velero-plugin-for-openstack:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The velero-plugin-for-openstack image is a drop-in replacement for the upstream Velero plugin for OpenStack image (lirt/velero-plugin-for-openstack). It keeps the upstream init-container contract: the plugin binary is at /plugins/velero-plugin-for-openstack, and the entrypoint cp -rT /plugins/ /target/ copies it into a shared volume that the Velero server loads plugins from.

The image runs as nobody:nogroup (65534:65533), the same as upstream, so the volume at /target must be writable by that user. An emptyDir volume meets this requirement.

Prerequisites

Before Velero can use this plugin, the OpenStack project needs:

• A Keystone user or application credential with the roles that back the providers you plan to use (Swift object operations for backups, Cinder for volume snapshots, Manila for shared-filesystem snapshots).
• For downloading backups through the Velero CLI or UI, the Swift account must have a temporary-URL key set (swift post -m "Temp-URL-Key:<secret>"); the plugin signs download URLs with it.

Getting Started

Install with the Velero Helm chart. Create a values file that uses the Chainguard images, configures the OpenStack locations, and points the plugin at the credentials file:

cat > values.yaml <<EOF
image:
  repository: cgr.dev/ORGANIZATION/velero
  tag: latest
initContainers:
  - name: velero-plugin-for-openstack
    image: cgr.dev/ORGANIZATION/velero-plugin-for-openstack:latest
    volumeMounts:
      - mountPath: /target
        name: plugins
configuration:
  backupStorageLocation:
    - name: default
      provider: community.openstack.org/openstack
      bucket: my-swift-container
  volumeSnapshotLocation:
    - name: cinder
      provider: community.openstack.org/openstack-cinder
  extraEnvVars:
    - name: OS_CLIENT_CONFIG_FILE
      value: /credentials/cloud
    - name: OS_CLOUD
      value: openstack
credentials:
  existingSecret: cloud-credentials
EOF

Create the credentials secret from your clouds.yaml (format in Configuration) and install the chart:

kubectl create namespace velero
kubectl -n velero create secret generic cloud-credentials --from-file=cloud=./clouds.yaml
helm install velero velero --repo https://vmware-tanzu.github.io/helm-charts -n velero -f values.yaml

To install with the Velero CLI instead, run:

velero install \
  --provider community.openstack.org/openstack \
  --image cgr.dev/ORGANIZATION/velero:latest \
  --plugins cgr.dev/ORGANIZATION/velero-plugin-for-openstack:latest \
  --bucket my-swift-container \
  --secret-file ./clouds.yaml

velero install mounts the secret at /credentials/cloud but does not set the variables the plugin reads, so set them on the deployment:

kubectl -n velero set env deployment/velero OS_CLIENT_CONFIG_FILE=/credentials/cloud OS_CLOUD=openstack

If Velero already runs with the upstream plugin image as its first init container, point that init container at this image:

kubectl -n velero patch deployment velero --type=json -p '[
  {"op":"replace","path":"/spec/template/spec/initContainers/0/image","value":"cgr.dev/ORGANIZATION/velero-plugin-for-openstack:latest"}
]'

Configuration

The plugin reads credentials with gophercloud (src/utils/auth.go), which looks for either standard OS_* environment variables or an os-client-config clouds.yaml file. Velero mounts its credentials secret at /credentials/cloud, so the examples above set OS_CLIENT_CONFIG_FILE=/credentials/cloud to point gophercloud at that file and OS_CLOUD=openstack to select the openstack entry in it. You can also set OS_* variables directly from a secret with envFrom; leave OS_CLOUD unset in that case, or the plugin reads clouds.yaml instead of the variables.

A minimal clouds.yaml for application credentials looks like this:

clouds:
  openstack:
    auth:
      auth_url: https://keystone.example.com:5000/v3
      application_credential_id: <id>
      application_credential_secret: <secret>
    auth_type: v3applicationcredential
    region_name: RegionOne
    interface: public
    identity_api_version: 3

The Helm values above create a BackupStorageLocation that uses Swift and a VolumeSnapshotLocation that uses Cinder. To add the same locations to an existing installation, apply:

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: default
  namespace: velero
spec:
  provider: community.openstack.org/openstack
  objectStorage:
    bucket: my-swift-container
---
apiVersion: velero.io/v1
kind: VolumeSnapshotLocation
metadata:
  name: cinder
  namespace: velero
spec:
  provider: community.openstack.org/openstack-cinder

See the upstream OpenStack authentication configuration section for all supported authentication variables and location options.

Documentation and Resources

• Velero plugin for OpenStack repository
• Velero supported providers

The upstream project is licensed under the MIT License.

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.