-
Notifications
You must be signed in to change notification settings - Fork 605
Description
kgateway version
2.0.0
Is your feature request related to a problem? Please describe.
Discussion from slack with Troy:
The current kind is only Secret that maps to k8s secret. In many environment, k8s secret is not deemed as a medium that should store key material. I think it is good to have different kind. I can think of two:
File based
cert:
kind: File
name: <path_to_key>;<path_to_cert>
This instruct the kgateway to just load the cert from local file system. The actual key material can be mount onto the gateway pod as in-memory volume. And another container can be the one that write into the volume. This allow the key issuing disengaged from gateway proxy's lifecycel. This also provide flexibility.
SDS based
cert:
kind: SDS
name: <path_to_uds>;<credential_name>
Because envoy supports SDS natively, we can mount a SDS server to gateway proxy to serve the key material. This opens up direct integration with SPIFFE/SPIRE as well because spire-agent serves as SDS already. This provides flexibility for environments that already has established SPIRE infrastructure.
For vast majority of the user base I think file is a easier approach to understand. However it may encourage bad security practice if user just carelessly drop file on the pod.
SDS certainly has deeper adoption curve, but I think it is more generalized and future proof. For the environment I’m building on we already has spire setup so it is welcomed.
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional Context
No response