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
Add ability to install custom CA certificates in the Operator.
Use cases
To enable TLS communication between the operator and the connect-api, a valid certificate needs to be provided. Currently, a self-signed certificate or a certificate signed by a custom CA will make the operator request fail.
Given the common use case of deploying the connect-api service in private networks, obtaining a valid certificate from a valid CA does not seem an achievable solution.
Proposed solution
Add volumeMounts (and volumes) field to the specifications of the Operator. These fields are used to mount custom volumes into the Operator pod. E.g.
I'm also having kind of the same issue. The operator is failing to verify the certificate since it's using the internal container name "connect-sync" to reach the connect-api . Therefore this is not a valid hostname for my certificate.
If someone found a workaround for this I would be interested !
Commenting to try and boost this. It is a major problem. Even adding the ability to mount a volume on the operator pod would help, as I think there is a way to manually configure the CA IF I could get it on the pod.
Summary
Add ability to install custom CA certificates in the Operator.
Use cases
To enable TLS communication between the operator and the connect-api, a valid certificate needs to be provided. Currently, a self-signed certificate or a certificate signed by a custom CA will make the operator request fail.
Given the common use case of deploying the connect-api service in private networks, obtaining a valid certificate from a valid CA does not seem an achievable solution.
Proposed solution
Add
volumeMounts
(andvolumes
) field to the specifications of the Operator. These fields are used to mount custom volumes into the Operator pod. E.g.Furthermore, the CA store needs to be updated at container boot (or provided the ability to do so)
Is there a workaround to accomplish this today?
No.
The text was updated successfully, but these errors were encountered: