Comment 55 for bug 1878234

Kubernetes defaults are not really secure by default__ One can pretty much bring the cluster down or gain elevated privileges by using hostpath as seen in the example posted by devimc.
The responsibility to secure the cluster lies with the cluster admin using admission controller or Pod Security Policies to limit what an user can do with the pod. Pod Security policies allow for a fine grained control where pods that use hostpath or hostpid or run as privileged are rejected.

We have taken a similar approach so far by allowing annotations with Kata and placing the responsibility of validating fields on the service provider by having proper admission controls in place.
That being said, I do see the value of kata annotations being used by the end-users and not just the service provider, such as being able to use different kernel or boot options for a particular workload.
So it makes sense to have validation for the annotations in Kata.
I am leaning towards Tao's suggestion, add an ability to completely disable/enable annotations and extend this with a whitelist, with us identifying annotations that are safe for a user to configure.
We would need to systematically go through the list of annotations and identify those that can be whitelisted or need additional validations. (We can potentially identify those that can be removed altogether in 2.0)
Specifically for the the exec binaries, instead of having regular expressions, we can have a list of system paths such as ["/usr/bin", "/usr/local/bin", "/opt/kata/bin"].
That way it is ok to use an executable as long as the base directory of the executable belongs to these paths. Would like to see what others think.