[RFE] Possibility to add a custom CA to VolSync mover

[fjcloud]

Hello,

You can't add a custom CA on restic mover and be able to do backup/restore with custom S3 storage in HTTPS. Workaround is to rebuild image[2] with a custom CA and change image in ENV variable of operator[3].

It can be a good idea to define a config map in spec of replicationSource or replicationDestination with customCA.

PS: Awesome project!

[1]https://github.com/backube/volsync [2]https://github.com/backube/volsync/blob/main/mover-restic/Dockerfile [3]https://github.com/backube/volsync/blob/ac3a4361fe4de370a90c286083894901edf37db5/config/manager/kustomization.yaml#L38

[dymurray]

This is critical for OADP as well moving forward.

[JohnStrunk]

Looking into this a bit, I've got the following scenario:

Deploying the minio chart w/ TLS enabled and an autogenerated cert:

$ helm upgrade --create-namespace -n minio --debug --set auth.rootUser=access --set auth.rootPassword=password --set defaultBuckets=mybucket --set "securityContext.enabled=false" --set "volumePermissions.enabled=true" --set tls.enabled=true --set tls.autoGenerated=true --wait --timeout=300s minio bitnami/minio

This generates a cert in a Secret:

$ kubectl -n minio describe secret/minio-crt
Name:         minio-crt
Namespace:    minio
Labels:       app.kubernetes.io/instance=minio
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=minio
              helm.sh/chart=minio-11.7.18
Annotations:  meta.helm.sh/release-name: minio
              meta.helm.sh/release-namespace: minio

Type:  kubernetes.io/tls

Data
====
ca.crt:   1123 bytes
tls.crt:  1379 bytes
tls.key:  1675 bytes

The ca.crt is the part of interest here, and can be retrieved:

$ kubectl -n minio get secret/minio-crt -ojson | jq -r '.data["ca.crt"]' | base64 -d > ca.crt

Port forwarding and initializing a restic repo:

$ kubectl port-forward -n minio svc/minio 9000:9000
Forwarding from 127.0.0.1:9000 -> 9000
Forwarding from [::1]:9000 -> 9000

# In another terminal we try w/o the ca.crt (just the system default), and it fails
$ AWS_ACCESS_KEY_ID=access AWS_SECRET_ACCESS_KEY=password restic -r s3:https://localhost:9000/restic init
enter password for new repository: 
enter password again: 
Fatal: create repository at s3:https://localhost:9000/restic failed: client.BucketExists: Get "https://localhost:9000/restic/?location=": x509: certificate signed by unknown authority

# Providing the downloaded ca.crt succeeds
$ AWS_ACCESS_KEY_ID=access AWS_SECRET_ACCESS_KEY=password restic -r s3:https://localhost:9000/restic --cacert ca.crt init
enter password for new repository: 
enter password again: 
created restic repository 090c9709ab at s3:https://localhost:9000/restic

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

So it looks like we just need to mount a Secret into the mover pod at a fixed path and pass a single filename to the restic exe w/ the --cacert flag.

[JohnStrunk]

/assign

[JohnStrunk]

@dymurray @fjcloud Does this look like it solves your use case? Docs pulled from the PR: https://volsync--398.org.readthedocs.build/en/398/usage/restic/index.html#using-a-custom-certificate-authority