Add Plugins

[JU4N98]

Changes proposal:

Adds support for plugins according with issue #65, on each X.509 SVID, JWT SVID or JWT Bundle update, the helper will notify this change to all the loaded plugins. The block plugins is added to the config file where the configuration of every plugin is specified. For example:

agentAddress = "/var/run/api.sock"
cmd = "/run/client/assert.sh"
cmdArgs = ""
certDir = "/run/client/certs/"
renewSignal = "SIGUSR1"
svidFileName = "svid.crt"
svidKeyFileName = "svid.key"
svidBundleFileName = "root.crt"
jwt_audience = "example.org"
jwt_svid_file_name = "jwt.json"
jwt_bundle_file_name = "jwk.json"

plugins {
    "simple-plugin" {
        path="/opt/helper/simple-example"
        checksum="7ae182614c5b2f96b0c6655a6bf3e1e64fb0dbb9142fa50c8cf0002c5c5bb9c5"
        from="Bob"
        to="Alice"
        message="hi alice!"
    }
}

In this example a plugin called simple-plugin is going to be loaded into the spiffe-helper, there are two mandatory fields:

• path: the path of the plugin binary.
• checksum: the sha256 hash of the binary, needed to validate it.

But it is also possible to specify other string configurations for each plugin, in this case the simple-plugin has three: from, to and message. All the configurations will be shared on the plugin load.

[JU4N98]

Hi @faisal-memon, it would be great if you can take a look to this proof of concept. It is related to 65.

[kfox1111]

Whats the status of this? I think it is useful to the helm-charts-hardened project.

[JU4N98]

Whats the status of this? I think it is useful to the helm-charts-hardened project.

Hi @kfox1111 I'm going to keep working on this

[kfox1111]

A thought....

This plugin support requires spire-helper to execute the plugin. In a traditional environment, that works very well.

In a containerized environment such as Kubernetes though, that would require spire-helper along with the plugins to be in the same container, which is more difficult as generally those come from different sources. In that environment, its much easier for them to be different containers, have Kubernetes exec the containers, and share between them with unix sockets.

Could this pr be updated to support that mode of operation too?

[JU4N98]

A thought....

This plugin support requires spire-helper to execute the plugin. In a traditional environment, that works very well.

In a containerized environment such as Kubernetes though, that would require spire-helper along with the plugins to be in the same container, which is more difficult as generally those come from different sources. In that environment, its much easier for them to be different containers, have Kubernetes exec the containers, and share between them with unix sockets.

Could this pr be updated to support that mode of operation too?

I think something like that is out of scope for this PR, the main idea was to add support for plugins that runs alongside the helper in the same container. But is the initial approach, maybe that could be added in other PR as other kind of plugins.

[kfox1111]

Probably ok to do in a followon, but maybe make sure the api leaves room so that it can be done via socket instead of exec without having to move around config items?

[kfox1111]

Looks like that could be done by adding a 'type' field or something to the plugin to specify that path is an executable (default) vs named socket, so, I think we're good already?

[JU4N98]

Looks like that could be done by adding a 'type' field or something to the plugin to specify that path is an executable (default) vs named socket, so, I think we're good already?

Yes, a field like type should be enough to treat the differently. I think isn't necessary to add anything since I'm parsing each plugin into a map of string.