Quality Gate passed

Issues
29 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

So, first of all. What is this? :)

Second of all, it's all obviously llm generated so I'm not even going to take a glance before your refactor it all and give it a humane touch. I'm not saying llms are bad for generating initial code, but I expect you to go over it and make it easier to read and grasp for HUMANs. Thanks.

Hello @Skarlso :)
Thanks for your message.

Yes, everything is definitely a first POC, llm based, and that's why I put it as a draft, to definitely not merge it.
I was intending to work on it more, but other subjects took me away.

The main reason of all this work is to able to add private internal providers to ESO.
So it add an interface a plugin can implement.

The goal is to get ESO less dependent on providers code integration.

Basically, for a company like us, with our own vault technology.
Having ESO working should just be the upstream project + our own internal sidecar (from private registry).

Ahh I see. Interesting. Though I think the contract for external plugins or providers should be API based. I'm imagining something like the capi/capa relationship. But we'll see how that goes. :)

Yes, could also be with the kubernetes interface.
But I really fear the complexity of a provider that needs to deal with all the API server.
Something, I think, ESO is doing really well.

I think a provider could be as simple as "implement this go interface" (just like the current provider in ESO code).
After that, go-plugin is automatically doing the job to forward everything, through grpc, to ESO.

I've done something like that for kubeswitch we are using for an internal platform
https://github.com/danielfoehrKn/kubeswitch/blob/master/pkg%2Fstore%2Fkubeconfig_store_plugins.go

Hey @guilhem, thanks for your effort so far. I'd like to raise awareness for #4792 - where we're designing out of tree providers for ESO (SecretStore v2 essentially) which overlaps 100% with your proposal.

I think your implementation will be beneficial to the proposal while you're exploring this domain.
The interface of this plugin and the "SecretStore v2 interface" should be the same, as they provide the same service.

Please keep this in mind that we may raise concerns related to the design/implementation of the out of tree providers.

I've looked into the plugin functionality an eternity ago: and found that hashicorp/go-plugin does not provide the right abstraction that we need (spawns a subprocess, sets up an UDS in /tmp to talk to it, terminates after completion, there's no sane way to reconnect to a service), one would probably better off to implement it from scratch with a grpc lib.

Hey @guilhem, thanks for your effort so far. I'd like to raise awareness for #4792 - where we're designing out of tree providers for ESO (SecretStore v2 essentially) which overlaps 100% with your proposal.

Thanks for linking to this. :)

I've looked into the plugin functionality an eternity ago: and found that hashicorp/go-plugin does not provide the right abstraction that we need (spawns a subprocess, sets up an UDS in /tmp to talk to it, terminates after completion, there's no sane way to reconnect to a service), one would probably better off to implement it from scratch with a grpc lib.

You are perfectly right; that's why the example provider doesn't use go-plugin at all.
In fact, go-plugin is currently used only for 1 interface. It could be totally removed.

I removed any go-plugin reference.

Hey @guilhem how are you progressing with the plugin system? Do you have capacity to work on this? Please let me know, i may want to take a shot at this in the near future, too. I want to prevent two people working on this simultaneously ;)

Quality Gate passed

Issues
29 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@moolen what do you think of the current plugin architecture in this PR?
Installing plugins as sidecars
communicating with gRPC
using Unix sockets with an emptydir

Because some adjustment can be done, but most of it is already ok.

Just thinking out loud: systemd has a concept of loading credentials from unix socket as well (https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#Credentials) - how about using the exact same mechanism? Here is a nice blog post that provides an example implementation in python: https://medium.com/@umglurf/using-systemd-credentials-to-pass-secrets-from-hashicorp-vault-to-systemd-services-928f0e804518

I guess for a PoC using a unix socket would be fine, but for the real deal i would like to avoid that due to:

1. the sidecar by default inherits the same serviceAccount, hence has the same RBAC permissions
2. related to 👆: IRSA/PodIdentity/WorkloadIdentity is based on the serviceaccount, hence all sidecars would get these cloud permissions by default, which is something to avoid.
3. a sidecar runs in the same network namespace, hence it is subject to the same network policies.

I would like to force users to have separate deployments for eso-core and the plugin provider.

@moolen you convince me :)

This pr is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.

This pr is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.