velero-plugin-for-openstack-fips

packaged by Chainguard

Chainguard Container for velero-plugin-for-openstack-fips

FIPS-enabled 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-fips: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-fips image is a FIPS-enabled 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.

FIPS Support

This image builds the plugin binary with the Chainguard go-msft-1.27 FIPS toolchain, which routes crypto/* through the FIPS 140-3 validated OpenSSL provider when that provider loads in the runtime the plugin executes in. If the provider fails to load, the toolchain falls back to its embedded Go FIPS module.

Only the plugin binary is copied into the Velero container (cp -rT /plugins/ /target/); the running process inherits its filesystem, system libraries, and FIPS mode from the Velero image it is loaded by. Pair this image with cgr.dev/ORGANIZATION/velero-fips so the plugin executes in a FIPS-capable runtime.

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. Set OS_SWIFT_TEMP_URL_DIGEST=sha256 (or sha512) on the Velero container, as the examples below do, because the default SHA-1 digest is refused in FIPS mode.

Getting Started

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

cat > values.yaml <<EOF
image:
  repository: cgr.dev/ORGANIZATION/velero-fips
  tag: latest
initContainers:
  - name: velero-plugin-for-openstack
    image: cgr.dev/ORGANIZATION/velero-plugin-for-openstack-fips: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
    - name: OS_SWIFT_TEMP_URL_DIGEST
      value: sha256
credentials:
  existingSecret: cloud-credentials
EOF

Create the credentials secret from your clouds.yaml 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-fips:latest \
  --plugins cgr.dev/ORGANIZATION/velero-plugin-for-openstack-fips: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 OS_SWIFT_TEMP_URL_DIGEST=sha256

If you already run Velero with the upstream plugin image as its first init container, switch both the server and the plugin to the FIPS images and set the temp-URL digest:

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

Verifying the FIPS build

The plugin runs as a child process of the Velero server, so check its crypto backend in the Velero logs. Enable verbose FIPS reporting and debug logging, which forwards the plugin's stderr, in a single rollout:

kubectl -n velero patch deployment velero --type=json -p '[
  {"op":"add","path":"/spec/template/spec/containers/0/env/-","value":{"name":"GODEBUG","value":"cgr_verbose=1"}},
  {"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--log-level=debug"}
]'
kubectl -n velero rollout status deployment/velero
kubectl -n velero logs deployment/velero -c velero | grep 'cgr_fips.*pluginName=velero-plugin-for-openstack'

The output includes the backend the plugin uses:

level=debug msg="cgr_fips: openssl" cmd=/plugins/velero-plugin-for-openstack logSource="pkg/plugin/clientmgmt/process/logrus_adapter.go:75" pluginName=velero-plugin-for-openstack

Debug logging records every OpenStack API exchange, so roll back to the previous revision once you have checked the backend:

kubectl -n velero rollout undo deployment/velero

Configuration

Credential discovery and location configuration are identical to the velero-plugin-for-openstack image: Velero mounts its credentials secret at /credentials/cloud, and the plugin reads it as a clouds.yaml file once OS_CLIENT_CONFIG_FILE=/credentials/cloud and OS_CLOUD=<cloud-name> are set on the Velero deployment. 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
• Chainguard FIPS container images

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.