Backup and Restore Resources

[ailox]

This concerns the page https://cert-manager.io/next-docs/tutorials/backup/

This issue is related to cert-manager/cert-manager#2112.

I'm sorry, but the backup/restoration process does simply not work as advertised, and conveys a false sense of security. I'd argue it should be removed or, at the very least, augmented with a warning of some kind.

[rpherrera]

This procedure is really misleading and does not work like that... Luckily I did it on staging environment first...

[rpherrera]

I could manage to restore my backup using the following (suboptimal/error prone/bizarre) procedure:

• Take a 2nd backup from the created resources that we wanna overwrite:

kubectl get -o yaml \
     --all-namespaces \
     issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup-2.yaml

• Just to play safe: please don't forget to version your 1st backup YAML file before continuing...

• Put your 1st backup (let's say: cert-manager-backup-1.yaml) side by side with the 2nd backup (cert-manager-backup-2.yaml) on the text editor...

• On the 1st backup file, make sure to replace the following fields using the values from the 2nd backup on their equivalent code regions:

  • creationTimestamp
  • resourceVersion
  • uid
  • lastTransitionTime

• Apply the changes you made on top of your 1st backup file:

kubectl apply -f cert-manager-backup-staging.yaml

• It worked for me and I hope that helps while we don't have a "clean" backup/restore procedure that we can follow...

[wallrj]

Hey @ailox

Thanks for the bug report. There are a bunch of similar issues in the cert-manager repo too.
We need to document (and test) an improved process for restoring cert-manager backups:

[wallrj]

/priority important

[jetstack-bot]

@wallrj: The label(s) priority/important cannot be applied, because the repository doesn't have them

In response to this:

/priority important

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[wallrj]

In #397 (comment) @meyskens wrote:

Is it better to backup these secrets, or let LE re-issue?

Probably better to backup the secrets too unless you think the storage medium of your backups is compromised/easy to infiltrate.
It will allow to:

restore certificates before everything us online to solve the ACME challenges
not hit the LE rate limits

If you are sharing the backup on something like a Git repo, Slack, shared computer,... I would avoid it as it will leak your private key.

[wallrj]

In cert-manager/cert-manager#2112 (comment) @munnerz wrote:

As noted above, I don't think it's trivial for us to create an entirely 'restorable' resource that can be applied during the restore phase.

I think we can take this issue and turn it into one of two things:

Documenting how to perform the backup/restore process with something like Velero
Extending our own CLI tool to have a dedicated backup and restore subcomannd.

I think (2) would be really interesting/useful for users, although in a lot of cases (1) may be more appropriate if you're running backups across a large number of clusters/regularly.