diff --git a/docs/proposals/karmada-operator/external-etcd-credentials-ref/README.md b/docs/proposals/karmada-operator/external-etcd-credentials-ref/README.md new file mode 100644 index 000000000..7868e420a --- /dev/null +++ b/docs/proposals/karmada-operator/external-etcd-credentials-ref/README.md @@ -0,0 +1,92 @@ +--- +title: Enhance `EcternalEtcd` Configuration to Support Retrieving etcd Client Credentials from a Kubernetes Secret +authors: +- "@jabellard" +reviewers: +- "@RainbowMango" +- "@zhzhuang-zju" +approvers: +- "@RainbowMango" +- "@zhzhuang-zju" + +creation-date: 2024-07-26 + +--- + +# Enhance `EcternalEtcd` Configuration to Support Retrieving etcd Client Credentials from a Kubernetes Secret + +## Summary + +This proposal aims to enhance the `EternalEtcd` configuration in the Karmada API by introducing support for loading external etcd client credentials from a Kubernetes secret. +This change will improve the security and manageability of sensitive data, such as TLS certificates and private keys by leveraging Kubernetes' native secret management capabilities. + +## Motivation + +The current implementation of the `ExternalEtcd` configuration requires the etcd client credentials, including the certificate private key, to be provided inline within the configuration. +This approach poses security risks and can be cumbersome to manage, especially in CI/CD scenarios driven by GitOps. By enabling the ability of loading those credentials from a secret, we can ensure that sensitive data is stored securely and managed more efficiently. +Additionally, this enhancement is very well-aligned with Kubernetes best practices for managing sensitive information and provides a more flexible and secure way to configure external etcd connections. + +### Goals + +- Add support for connecting to an external etcd cluster. +- Enable the use of Kubernetes secrets for storing and retrieving external etcd connection credentials. +- Improve the security of sensitive data by leveraging Kubernetes' native secret management capabilities. +- Simplify the management of external etcd configurations. + +### Non-Goals + +- Modifying the internal etcd configuration. +- Changing the existing inline configuration approach. + +## Proposal + +Introduce a new field, `SecretRef`, within the `ExternalEtcd` configuration to reference a Kubernetes secret that contains the necessary etcd connection credentials. +The existing inline configuration fields will be preserved to maintain backward compatibility. However, given that they are currently unused, it would make sense to mark them as deprecated. + +## Design Details + +Introduce the new field `SecretRef` within the `ExternalEtcd` configuration: +```go +// ExternalEtcd describes an external etcd cluster. +type ExternalEtcd struct { + // Other, existing fields + + + // SecretRef references a Kubernetes secret containing the etcd connection credentials. + // The secret must contain the following data keys: + // ca.crt: The Certificate Authority (CA) certificate data. + // tls.crt: The TLS certificate data. + // tls.key: The TLS private key data. + // +optional + SecretRef *LocalSecretReference `json:"secretRef,omitempty"` +} +``` + +Type `LocalSecretReference` already exists in the API. + +### Secret Structure + +The Kubernetes secret referenced by `SecretRef` must contain the following data keys: + +- `ca.crt`: The Certificate Authority (CA) certificate data. +- `tls.crt`: The TLS certificate data. +- `tls.key`: The TLS private key data. + +Example: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: tenant1-etcd-credentials + namespace: tenant1 +type: Opaque +data: + ca.crt: + tls.crt: + tls.key: +``` + +### Control Plane Component Configurations + +Today, the Karmada operator stores the in-cluster etcd client credentials in a secret. That secret is then used as the source of a volume that is mounted into control plane component containers +that need to connect to etcd such as `karmada-apiserver`, `karmada-aggregated-apiserver` and `karmada-search`. The configuration for these components will be very similar when connecting to an external etcd cluster. \ No newline at end of file