You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Folks, I've seen a couple discussion threads regarding velero/restic against an S3 provider that requires SSL with custom a CA, and therefore needing to override the default system CA. This is our use case. We use rook-ceph as our S3 provider and we have a custom CA that is a corporate resource. We configure rook-ceph to provide a cert that is validated by this CA.
Based on this documentation -- https://golang.org/pkg/crypto/x509/ -- it looks like the go runtime honors the SSL_CERT_FILE environment variable. So I configured our velero deployment and restic daemonset manifests to mount our CA from a secret and then I set SSL_CERT_FILE to point to that mounted CA in the deployment and daemonset.
I've tested and so for this seems to work fine. Do you see anything fragile or subject to future breakage from this approach? Thanks.
The text was updated successfully, but these errors were encountered:
This seems like an acceptable solution short term. However, the issue I see with this approach is that, by setting the SSL_CERT_FILE environment variable, we will be forcing this ca cert to be used for all ssl connections. This can become a problem if you are trying to connect to multiple endpoints which may not recognize the corporate ca cert. This also applies to the other velero plugins that you may have as part of your deployment.
Folks, I've seen a couple discussion threads regarding velero/restic against an S3 provider that requires SSL with custom a CA, and therefore needing to override the default system CA. This is our use case. We use rook-ceph as our S3 provider and we have a custom CA that is a corporate resource. We configure rook-ceph to provide a cert that is validated by this CA.
Based on this documentation -- https://golang.org/pkg/crypto/x509/ -- it looks like the go runtime honors the SSL_CERT_FILE environment variable. So I configured our velero deployment and restic daemonset manifests to mount our CA from a secret and then I set SSL_CERT_FILE to point to that mounted CA in the deployment and daemonset.
I've tested and so for this seems to work fine. Do you see anything fragile or subject to future breakage from this approach? Thanks.
The text was updated successfully, but these errors were encountered: