KBS | Plugin system design

[Xynnn007]

Now we have a resource plugin system which will be used by clients to perform complex operations not only for simple get resource. #396

Let's re-examine the entire plug-in design mechanism from the architectural level. We can easily find that we are facing three typical overall potential plugin interfaces.

Client Request Plugins

They are plugins that extend the way for clients to call KBS. A long discussion has been talked about this in the issue. Here I want to claim a design that with path of KBS /kbs/v0/<plugin-name>/..., the request of client will be delivered to different plugins. How to parse the concrete parameters is decided by the concrete plugin (e.g. queries or paths). Actually up to now we support the following plugins

1. resource. This plugin helps the client to retrieve confidential data/resource from KBS. Conceptually it's a simple KV store authorized by a successfully remote attestation and resource policy filter. The resource is indexed by the following <repository>/<type>/<tag>
2. auth and attest. Well, this is actually a same plugin used to do remote attestation to perform RCAR handshake.

Potentially we could implement other plugins, like

• Nebula plugin nebula/. This is also a way for nebula to integrate with KBS in a more standard way without influence resource API. @cclaudio
• Pod identity auth API, e.g. register/. This is another form of auth/attest, but the result is that the KBS provisions a public key cert to the pod/guest.

Server Admin Plugins

They are plugins extending the way for KBS owner/admin to call KBS. We have such use cases for now and potentially have more. What we have as admin plugin, for example is Set Resource API that helps the owner of KBS to store arbitrary data with given resource URI when the admin public key authentication passes.

Potential needs include

1. Observability for KBS. Pointed out by @fitzthum , we need some admin API to see the status of KBS. For example how many pods/clients are attested, etc.
2. Change the policy for KBS resource.

We might need a flexible plugin design for those, to help developers to integrate different admin plugins who share a same admin authentication method.

Server Request Plugins

Different from Client Request Plugins, Server Request Plugins are plugins providing ways for KBS to call clients. This kind of needs exist, e.g. split api design from @c3d @ray-valdez. KBS needs to call APIs from guest/pods. Typically KBS is publicly exposed to the client while the KBS cannot connects directly to client. Thus we might need a mechanism to keep a long connection tunnel (e.g. websocket, round-robin task fetch, ...) between the client and KBS once the client accesses KBS. Then, some reverse calls (from KBS to Clients) could be performed upon the tunnel.

We could have a basic design for the underlying tunnel and then a flexible RPC definition way to integrate into KBS for outer callers to call from KBS to the client side.

[jialez0]

I support this proposal and appreciate the direction it’s taking. However, I would like to emphasize the need for caution regarding variables that require awareness across multiple plugins, such as the current session state or client authentication status. Properly managing these variables will be crucial for maintaining consistency and security throughout the plugin execution process.

[fitzthum]

I think the resource plugins are the simplest and most important in the short term. Claudio has been on vacation but I think he will be back to workin on his PR next weekish.

One thing that might be cool to add in the future is an admin plugin that creates a basic web interface that lists out the policies that are enabled, the guests that are connected, the logs, etc. We'd need to come up with a good way to surface all that info.

[1570005763]

The support for hot-swappable plugins is something worth considering. It offers a couple of advantages:

• It creates a separation between the KBS and the plugins' security domains, so if a plugin crashes, it won't impact the KBS's operation.
• It allows for the ability to upgrade or switch out plugins while everything is running.

To make hot-swapping work smoothly, the KBS could provide at least two API endpoints for managing plugins:

• /kbs/v0/plugin/enable/<plugin-name>: This would be used to run the initialization routine for the plugin and register its API interfaces.
• /kbs/v0/plugin/disable/<plugin-name>: This would handle calling the exit routine for the plugin and deregistering its API interfaces.

I think it would make sense for /kbs/v0/plugin to be part of the admin-only API group and perhaps include some observable features as well, like /kbs/v0/plugin/list, for easy monitoring.

[Xynnn007]

Close as #514 finished