mirrors/velero
1
0
Fork 0
mirror of https://github.com/vmware-tanzu/velero.git synced 2026-01-06 13:26:26 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Remove design for new secret functionality

Browse Source 
Signed-off-by: Carlisia <carlisia@vmware.com>
This commit is contained in:
Carlisia
2020-04-02 10:44:48 -07:00
parent d763e7518b
commit 203bb7cbe7
1 changed files with 0 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
design/cli-install-changes.md
View File

@@ -270,69 +270,6 @@ A `velero backup-location (create|set) --cacert mapStringString` flag is also be
See discussion https://github.com/vmware-tanzu/velero/pull/2259#discussion_r384700723 for more clarification.
#### Credentials and secrets
Currently, Velero only supports a single AIM access credential secret per provider. But, given that a set of object store and/or volume snapshot for the same provider usually resides in the same plugin, it is also accurate to say Velero only supports a single credential secret per plugin.
Velero creates and stores the plugin credential secret under the hard-coded key `secret.cloud-credentials.data.cloud`. This makes it so switching from one plugin to another necessitates overriding the existing credential secret with the appropriate one for the new provider. This is made more evident with the new CLI command organization.
To improve the UX for configuring the velero deployment with multiple plugins/providers, and corresponding IAM secrets, the following changes will be made:
- the name of the flag changes from `secret-file` to `velero plugin set --credentials-file`. This is to be consistent with the name of the new flag `velero plugin set --cacert-file`.
- The `velero plugin (create|set) --credentials-file` will be a map of provider name as a key, and the path to the file as a value. This way, we can have multiple credential secrets and each secret per provider/plugin will be unique.
See discussion https://github.com/vmware-tanzu/velero/pull/2259#discussion_r384700723 for the two items below.
- The `velero backup-location (create|set)` will have a new `--credentials mapStringString` flag which sets the name of the corresponding credentials secret for a provider. Format is provider:credentials-secret-name.
- The `velero snapshot-location (create|set)` will have a new `--credentials mapStringString` flag which sets the list of name of the corresponding credentials secret for providers. Format is (provider1:credentials-secret-name1,provider2:credentials-secret-name2,...).
Note that for this logic to work, either the plugin for which the secret corresponds to must have been installed in the system, or we must have a loop checking for when both are present before marking the BSL/VSL as ready.
#### Examples of mounting secrets and environment variables
With the changes proposed in the previous section (Credentials and secrets), the resulting deployment `yaml` would look like below:
AWS
```
spec:
containers:
volumeMounts:
- mountPath: /credentials
name: cloud-credentials-aws
- args:
- server
name: velero
env:
- name: AWS_SHARED_CREDENTIALS_FILE
value: /credentials/cloud
volumes:
- name: cloud-credentials
secret:
secretName: cloud-credentials
```
Azure
```
spec:
containers:
volumeMounts:
- mountPath: /credentials
name: cloud-credentials-azure
- args:
- server
name: velero
env:
- name: AZURE_SHARED_CREDENTIALS_FILE
value: /credentials/cloud
volumes:
- name: cloud-credentials-azure
secret:
secretName: cloud-credentials-azure
```
#### Renaming "provider" to "plugin"
As part of this change, we should change to use the term `plugin` instead of `provider`. The reasoning: in practice, we usually have 1 plugin per provider, and if there is an implementation for both object store and volume snapshotter for that provider, it will all be contained in the same plugin. When we handle plugins, we follow this logic. In other words, there's a plugin name (ex: `velero.io/aws`) and it can contain implementations of kind `ObjectStore` and/or `VolumeSnapshotter`.