From ab3dfbf2a73d1c544ba89e4215393106ddb94343 Mon Sep 17 00:00:00 2001 From: Bipul Adhikari Date: Fri, 15 Nov 2024 10:08:48 +0545 Subject: [PATCH 1/2] docs: add design for using services for addons pods Signed-off-by: Bipul Adhikari --- docs/design/podService.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 docs/design/podService.md diff --git a/docs/design/podService.md b/docs/design/podService.md new file mode 100644 index 00000000..b052a71f --- /dev/null +++ b/docs/design/podService.md @@ -0,0 +1,24 @@ +# Add support for TLS certificates for CSI Addons communication + +The Kubernetes CSI Addons project currently connects the CSI Addons Manager to the add-on sidecar without TLS in place. +We propose a introduction of an arugment which enabled should mount the TLS certificates into the sidecar container. +The operator is only responsible for propagation of the certificates. + +## Problem Statement + +CSI addons sidecar which is being deployed here needs certificates. Currently we have no argument to enable this propagation of certificates. + +## Proposed Solution + +### Introduce a new argument for TLS + +We introduce a new argument in the commands to enable TLS. It is diabled by default. But if this is enabled the deployer is expected to have mounted a secret that contains the required certificates. We will essentially need a certifiate that is compatible with the hostname that the manager will be issuing network calls using it. + + +### Operator changes + +The Ceph CSI Operator is only responsible for taking in the information mounted to it and project those as volumes in the CSI Addons sidecar. The deployer of CSI Addons should create these certificates and mount it at `/etc/tls/tls.crt` and `/etc/tls/tls.key`. We keep this hardcoded to reduce the number of new arguments introduced. The logger should provide enough information if the user is not mounting this correctly for easy debugging. + +## Guide to the deployeer for handling certificates + +Since we use host networking the certificates should have these IP addresses as valid Subject names. From 54f3cab7171fe4cdfec81c1cd67a52b03affb6ba Mon Sep 17 00:00:00 2001 From: Bipul Adhikari Date: Thu, 5 Dec 2024 15:22:37 +0545 Subject: [PATCH 2/2] Addressing more comments; Makes changes to the proposal Signed-off-by: Bipul Adhikari --- docs/design/podService.md | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/docs/design/podService.md b/docs/design/podService.md index b052a71f..05e5cbf0 100644 --- a/docs/design/podService.md +++ b/docs/design/podService.md @@ -10,15 +10,36 @@ CSI addons sidecar which is being deployed here needs certificates. Currently we ## Proposed Solution -### Introduce a new argument for TLS - -We introduce a new argument in the commands to enable TLS. It is diabled by default. But if this is enabled the deployer is expected to have mounted a secret that contains the required certificates. We will essentially need a certifiate that is compatible with the hostname that the manager will be issuing network calls using it. +### Introduce a new argument for TLS +We introduce a new argument in the commands to enable TLS. It is diabled by default. But if this is enabled the deployer is expected to have mounted a secret that contains the required certificates. We will essentially need a certifiate that is compatible with the hostname that the manager will be issuing network calls using it. ### Operator changes -The Ceph CSI Operator is only responsible for taking in the information mounted to it and project those as volumes in the CSI Addons sidecar. The deployer of CSI Addons should create these certificates and mount it at `/etc/tls/tls.crt` and `/etc/tls/tls.key`. We keep this hardcoded to reduce the number of new arguments introduced. The logger should provide enough information if the user is not mounting this correctly for easy debugging. +The Ceph CSI Operator when deploying the sidecar for CSI Addons should will the secret provided in the OperatorConfig in `/etc/tls` folder. The infomration about the secret should be provided via OperatorConfig which in then will be used during sidecar creation. The secret contains information the certficate that is going to be used by the CSI Addons sidecar. + +## Guide to the operator incharge of creating certificates (Optional) + +Based on the type of networking that is to be used. Hostnames used to connect to the Sidecar endpoint should be set in the certificate accordingly. + +## Changes proposed to OperatorConfig + +``` +// New struct proposed +type TLSConfiguration struct { + certificateSecretname string + cretificateSecretNamespace string + enableTLS bool +} -## Guide to the deployeer for handling certificates +// OperatorConfigSpec defines the desired state of OperatorConfig +type OperatorConfigSpec struct { + //+kubebuilder:validation:Optional + Log *OperatorLogSpec `json:"log,omitempty"` -Since we use host networking the certificates should have these IP addresses as valid Subject names. + // Allow overwrite of hardcoded defaults for any driver managed by this operator + //+kubebuilder:validation:Optional + DriverSpecDefaults *DriverSpec `json:"driverSpecDefaults,omitempty"` + TLSConfiguration *TLSConfiguration // Conigure TLS certificates for CSI addons +} +```