Describe the feature you'd like to have.
The operator should properly secure all components (CSI, Gluster pods, etcd) at time of deployment.
The CR will contain a reference to a secret with a CA key pair. This key pair should be used to secure the Gluster cluster.
What is the value to the end user? (why is it a priority?)
In a kubernetes environment, pods can get traffic from arbitrary sources. In order to maintain the integrity of the infrastructure and properly protect user data, the operator should properly secure all components via TLS (or other supported/appropriate method)
How will we know we have a good solution? (acceptance criteria)
The CA secret is used by Gluster pods on startup to generate a pod keypair
The CSI driver (on each node), at startup, generates a keypair using the CA secret so that it can access the Gluster cluster
The GD2 management API is properly secured
Keys are properly distributed between GD2 and etcd to secure that communication channel (NOTE: this will eventually need to be broken into a separate issue)
Describe the feature you'd like to have. The operator should properly secure all components (CSI, Gluster pods, etcd) at time of deployment. The CR will contain a reference to a secret with a CA key pair. This key pair should be used to secure the Gluster cluster.
What is the value to the end user? (why is it a priority?) In a kubernetes environment, pods can get traffic from arbitrary sources. In order to maintain the integrity of the infrastructure and properly protect user data, the operator should properly secure all components via TLS (or other supported/appropriate method)
How will we know we have a good solution? (acceptance criteria)
Additional context Depends on: