-
Bug
-
Resolution: Unresolved
-
Critical
-
OADP 1.2.0, OADP 1.3.0
-
4
-
False
-
-
False
-
ToDo
-
-
-
0.000
-
Very Likely
-
0
-
None
-
Unset
-
Unknown
-
No
Background - https://redhat-internal.slack.com/archives/C0144ECKUJ0/p1714577996520399
AWS - DPA ( THIS WORKS ) apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample namespace: openshift-adp spec: backupLocations: - velero: config: customerKeyEncryptionFile: /credentials/customer-key profile: default region: us-west-2 credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: cvpbucketuswest2 prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - openshift - aws - csi featureFlags: - EnableCSI snapshotLocations: - velero: config: profile: default region: us-west-2 provider: aws
Credentials are mounted on the velero pod in /credentials !! WIN !!
A Minio setup behaves slightly different, the aws creds are copied to /tmp/
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample namespace: openshift-adp spec: backupLocations: - velero: config: customerKeyEncryptionFile: /credentials/customer-key insecureSkipTLSVerify: "true" profile: default region: minio s3ForcePathStyle: "true" s3Url: http://10.131.0.140:9000 credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: velero prefix: velero provider: aws configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - openshift - aws - csi featureFlags: - EnableCSI
The additional cred `customerKeyEncryptionFile` is never copied nor mounted to the velero pod.
At this moment having both cloud-credentials/[cloud, customerKeyEncryptionFile] only works when using AWS S3 buckets, and does NOT work w/ s3 aws compatible storage.
- Nooba may work, I need to retest.
WORKAROUND: include a snapshotLocation config:
snapshotLocations:
- velero:
config:
profile: default
region: minio
provider: aws
- relates to
-
OADP-889 Mount SSE-C Encryption file for AWS plugin
-
- Closed
-
- links to
[OADP-3971] Additional secrets cannot be added to velero pod without restart
tkaovila@redhat.com punt this to 1.6.0 due to https://github.com/vmware-tanzu/velero/issues/8692 ?
Tiger Kaovilai
added a comment - Upstream velero issue linked . AI:
- Tiger will open an upstream bug to avoid having to restart Velero when a new credential is added.
- Fix in oadp/nac (temporary?):
- Mount single secret
- When a volume contains data from a Secret, and that Secret is updated, Kubernetes tracks this and updates the data in the volume, using an eventually-consistent approach.
- Updates to Secrets can be either propagated by an API watch mechanism (the default), based on a cache with a defined time-to-live, or polled from the cluster API server on each kubelet synchronisation loop.
- As a result, the total delay from the moment when the Secret is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay, where the cache propagation delay depends on the chosen cache type (following the same order listed in the previous paragraph, these are: watch propagation delay, the configured cache TTL, or zero for direct polling).
FIX:
- always create the cloud-credentials secret, even if empty
- always mount cloud-credentials
Need to test if keys added to the secret propagate to the mount on the velero pod
yes
On Tue, Mar 4, 2025 at 3:13 PM Wes Hayutin (Jira) <jira-issues@redhat.com>