Open v0lkan opened 1 month ago
From the dupe story:
thinking out loud: This is a custom resource that can act as if you are using VSecM Sentinel; ideally it will talk to VSecM Sentinel since sentinel is the only entry point to the system.
It would be visible only to cluster admins; it would reconcile whatever the VSecMSecret defines as a command.
In practice a VSecMSecret will create either a secret in VSecM Safe, or on Kubernetes, or both.
If the secret exists, it will update it; if it does not, it will create it.
when the secret is changed by someone else, it will reconcile the secret back to its former value.
Of course, the security of VSecMSecret will be paramount in this case.
This will be an optional feature (as it might impact, and maybe even reduce) the security of the overall system, while increasing convenience.
This needs a careful design, and a technical spec before starting the coding work.
We need a custom resource that can pull from a local (in-cluster) or external (federated cluster) VSecM and generate a Kubernetes Secret.
The Operator that does it will have a special clusterSPIFFEID and it would be able to securely talk to a VSecM Safe that it's configured to talk to as if it is VSecM Sentinel.
The interaction between the operator and VSecM Safe will be doubly encrypted since the secrets might be passing across the wire too.
Note: this means, we might not need the VSecM Relay Client and VSecM Relay Server, especially for use cases that require creation of Kubernetes Secrets only.
Note++: If the remote cluster has VSecM installed, we can also create VSecM Secrets there.