Comment 23 for bug 1878234

First of all, IMO the idea of exposing config-via-annotation functionality to end users is dangerous itself.

Other than the binary paths, there are a lot of other config options that also need to be filtered if they come from a random end user. For example, the default vcpu and memory size, the ability to preallocate guest memory, the ability to disable swap for guest memory, they can also cause serious problems for the infrastructure. And there are less-dangerous options like whether 9pfs or virtiofs is used, or which networking model is used, or if any experimental features are enabled, -- they can also cause unexpected chaos for the system.

So the white-list solution proposed by Christophe cannot be a complete solution until every option is properly reviewed and white-listed. And it throws another question, how do you white-list a boolean option?

So instead of jumping to a solution, I'd like to ask get a consensus on what want to provide first.

1. We *do not* want end users to customize kata containers via annotations.
2. We *want* to allow infrastructure to customize kata containers via annotations.

Can we agree on the above two points?