plugins: expose init-data to plugins

[fitzthum]

The init-data contains measured guest configuration. Exposing this to the plugin backend can allow for plugins to implement sophisticated logic based on measured guest data.

For example, a plugin could parse the guest policy and issue a certificate based on the properties of the guest (i.e. which container images are allowed to run).

Some of this logic can already be implemented today via a KBS policy, but exposing the init-data to the plugin itself allows for more flexibility.

The init-data is not always present. If a guest does not set the init-data or if the attestation agent does not validate the init-data and put the init_data_claims into the token, then this feature can't be used. Thus, the init-data argument is an Option.

[mythi]

since it's just a subset of the token claims, any reason why we shouldn't make the full token available instead?

[fitzthum]

Yeah good point. There's a little bit of a tradeoff here. Giving plugin authors the full plugin could make the interface more powerful but it makes things more complicated for plugin authors. I couldn't think of a use case for a plugin using the whole token so I thought this would be a little more convenient. wdyt?

[Xynnn007]

I think bring semantics related to KBS/kbs-protocol from token to KBS is a good point. But if we bring all initdata from the token it would be somehow coupled between AS and KBS. My suggestion is to define a good spec that records fields/data that KBS protocol / KBS uses. The fields can be set by runtime data and/or initdata. And the Attestation Service plugin of KBS can extract them and deliver to upper layer handlers, like plugins. This will help to cover the gap of different AS backend and abstraction of AS and KBS. For example, a client_id can be set via initdata. Thus then we can extract exactly client_id from the initdata. In this way what delivered to KBS logic from token is exactly a struct with field client_id and other defined fields.

The point two of #863 (comment)

[fitzthum]

@Xynnn007 I feel like this is best left to the plugins themselves. We might be able to standardize some parts of the init-data, but we don't really know what plugins will need and it's likely that different plugins will have different requirements. It's probably simplest to have the plugins parse the init-data themselves.

It's true that this does create some sort of requirement for the init-data to exist and for the AS to return it in the token, but note that we are passing Option<Value> here so really all we're saying is that some plugins might require init-data, which seems reasonable. Not every plugin will necessarily be compatible with every deployment.

[Xynnn007]

I feel like this is best left to the plugins themselves. We might be able to standardize some parts of the init-data, but we don't really know what plugins will need and it's likely that different plugins will have different requirements. It's probably simplest to have the plugins parse the init-data themselves.

Initdata represents metadata for the entire instance, while the portion used by KBS is defined only within the KBS remote attestation protocol. Consider that the policy.rego and cdh configuration files are not relevant to KBS, as they are workload-independent and only concern the specific PodVM instance.

Therefore, we need to define the content required by an extensible plug-in within the scope of the KBS protocol, such as extending the AA configuration file and e.g. cc_kbc related parts, allowing it to accept formatted configuration items such as [[plugin.XXX]] type than define it in the whole initdata scope.

It's true that this does create some sort of requirement for the init-data to exist and for the AS to return it in the token, but note that we are passing Option<Value> here so really all we're saying is that some plugins might require init-data, which seems reasonable. Not every plugin will necessarily be compatible with every deployment.

Yes, Option<Value> makes sense and I am in favor of it.