Secret silently not restored #4051
Replies: 1 comment 1 reply
-
I have seen something similar. I have a use case where I require the Secret token to be restored as it was and not skipped (as described here) for a new token to be generated in its place. We are providing access to team specific AKS namespaces via Service Accounts. The teams can access their namespaces via a Service Connection in e.g. Azure DevOps by referencing a Secret token generated via Service Account. The issue is that after running a Velero restore, the Secret token is re-created (e.g. new token value) and all our application teams are required to update their Service Connections with the new token. This is not feasible from a UX perspective. Anyone that has a workaround for this issue? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a secret that's not restored in my tests of my production cluster. When I create the backup, I see it logged. It appears in the resource list of the backup. When I restore, the secret is logged as being restored, but the restored cluster lacks the secret.
The secret is named
dev/vault-auth-tokenreview-token
in this example. I suspect that the generateddev/vault-auth-tokenreview-token-j5sql
somehow "masks" the secret I need restored; to be clear they are not the same.Beta Was this translation helpful? Give feedback.
All reactions