9ffffda11e
* Use Credential from BSL for restic commands This change introduces support for restic to make use of per-BSL credentials. It makes use of the `credentials.FileStore` introduced in PR #3442 to write the BSL credentials to disk. To support per-BSL credentials for restic, the environment for the restic commands needs to be modified for each provider to ensure that the credentials are provided via the correct provider specific environment variables. This change introduces a new function `restic.CmdEnv` to check the BSL provider and create the correct mapping of environment variables for each provider. Previously, AWS and GCP could rely on the environment variables in the Velero deployments to obtain the credentials file, but now these environment variables need to be set with the path to the serialized credentials file if a credential is set on the BSL. For Azure, the credentials file in the environment was loaded and parsed to set the environment variables for restic. Now, we check if the BSL has a credential, and if it does, load and parse that file instead. This change also introduces a few other small improvements. Now that we are fetching the BSL to check for the `Credential` field, we can use the BSL directly to get the `CACert` which means that we can remove the `GetCACert` function. Also, now that we have a way to serialize secrets to disk, we can use the `credentials.FileStore` to get a temp file for the restic repo password and remove the `restic.TempCredentialsFile` function. Signed-off-by: Bridget McErlean <bmcerlean@vmware.com> * Add documentation for per-BSL credentials Signed-off-by: Bridget McErlean <bmcerlean@vmware.com> * Address review feedback Signed-off-by: Bridget McErlean <bmcerlean@vmware.com> * Address review comments Signed-off-by: Bridget McErlean <bmcerlean@vmware.com> |
||
|---|---|---|
| .github | ||
| changelogs | ||
| cmd | ||
| config | ||
| design | ||
| examples | ||
| hack | ||
| internal | ||
| pkg | ||
| site | ||
| test/e2e | ||
| third_party/kubernetes/pkg/kubectl/cmd | ||
| tilt-resources | ||
| .dockerignore | ||
| .gitignore | ||
| .goreleaser.yml | ||
| ADOPTERS.md | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| GOVERNANCE.md | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| Makefile | ||
| PROJECT | ||
| README.md | ||
| ROADMAP.md | ||
| SECURITY.md | ||
| SUPPORT.md | ||
| Tiltfile | ||
| go.mod | ||
| go.sum | ||
| golangci.yaml | ||
| netlify.toml | ||
| restore-hooks_product-requirements.md | ||
README.md
Overview
Velero (formerly Heptio Ark) gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a public cloud platform or on-premises. Velero lets you:
- Take backups of your cluster and restore in case of loss.
- Migrate cluster resources to other clusters.
- Replicate your production cluster to development and testing clusters.
Velero consists of:
- A server that runs on your cluster
- A command-line client that runs locally
Documentation
The documentation provides a getting started guide and information about building from source, architecture, extending Velero, and more.
Please use the version selector at the top of the site to ensure you are using the appropriate documentation for your version of Velero.
Troubleshooting
If you encounter issues, review the troubleshooting docs, file an issue, or talk to us on the #velero channel on the Kubernetes Slack server.
Contributing
If you are ready to jump in and test, add code, or help with documentation, follow the instructions on our Start contributing documentation for guidance on how to setup Velero for development.
Changelog
See the list of releases to find out about feature changes.