Add Support for API Server Sidecar Containers in Karmada Operator

[jabellard]

What would you like to be added:
Encryption of confidential data at rest in Kubernetes is very crucial for ensuring a strong security posture. To enable that, Kubernetes supports a few options for configuring encryption at rest. Given that using a KMS-based encryption provider ensures a very robust security posture as compared to the other options, it's a great choice in an environment where integration with such a system is possible. When using a KMS-based provider, a KMS plugin is required to enable the integration. For instance, this is the plugin to bridge the integration for the AWS KMS offering. Once set up, the API server communicates to the plugin over a UNIX domain socket using gRPC. For that to work, when the API server is deployed as a pod as is the case when provisioned by the Karmada operator, the plugin has to run as a sidecar of the API server container.

Why is this needed:
At Bloomberg, we're currently building a managed Karmada platform and want to use the Karmada operator to manage the entire lifecycle of managed Karmada instances. One of our core requirements is to configure encryption at rest for managed Karmada control planes. Do do so, we want to integrate with our internal KMS as that will ensure a very strong security posture that adheres to our operational standards.

[jabellard]

@RainbowMango , I'd love to hear your thoughts.

[zhzhuang-zju]

@jabellard Based on your description, by combining this capability with the existing ability of the karmada-operator to customize the extraVolumes of the API Server, it should be able to meet the requirement of integrating the KMS with karmada-apiserver to achieve the encryption of confidential data at rest. Am I right?
Additionally, is this capability specifically designed for the KMS plugin, or will it offer a high level of configurability where the KMS plugin is just one of the use cases?

[jabellard]

@jabellard Based on your description, by combining this capability with the existing ability of the karmada-operator to customize the extraVolumes of the API Server, it should be able to meet the requirement of integrating the KMS with karmada-apiserver to achieve the encryption of confidential data at rest. Am I right?
Additionally, is this capability specifically designed for the KMS plugin, or will it offer a high level of configurability where the KMS plugin is just one of the use cases?

You're absolutely correct. Given that we already have support for extra volumes, this support will enable setting up the plugin for this use case. That's just one use case serving as the motivation for the feature, but it's not specific to the use case.

[jabellard]

I just submitted this proposal.

[zhzhuang-zju]

I'm fine with this feature as long as it can be highly configurable. Also, I think this use case is quite suitable for writing a blog post.

[jabellard]

I'm fine with this feature as long as it can be highly configurable. Also, I think this use case is quite suitable for writing a blog post.

Yeah. I agree.

[RainbowMango]

I'm not familiar with the Encryption of confidential data at rest, but sounds good to me to enhance the karmada-operator to support that.
I'll turn to your proposal and leave my comments there. Thanks.