Krisztian Litkey

/cc @haircommander

> Right now with mount or devices adjustments you can escape to the host, I understand people wanting something more fine grained than NRI on/off, but right now adding seccomp...

> as in: an admin probably expects every hook installed works as expected, but may want only some containers to be affected. I'm not sure of a platform agnostic way...

> for CRI-O's purposes, kubernetes namespaces would be sufficient. runtime class could also work. we just need some way it's exposed in the kubernetes API so we can connect policy...

> [@klihub](https://github.com/klihub) I fail to understand why some people push back on namespace / seccomp when everything is already fully open. Securing NRI can be done in // instead of...

@champtar And sorry for my misleading previous 'in multiple steps' comment. What I was trying to say, is that if this is OK as a starting point and it is...

> [@klihub](https://github.com/klihub) My apologies for the delay here. > > > Restrictions are communicated to an NRI plugin during registration. The plugin can then report and choose not to start...

> Where order is not important we are probably already there on the container side with the post create/start container calls with error response. For run pod we probably need...

> One of the desires and use cases expressed in [#142 (comment)](https://github.com/containerd/nri/issues/142#issuecomment-2661405662) is to "block pod creation until something is ready", `RunPodSandbox` is a hook that people that operates at...

@lengrongfu Do you mean that you would like to see an example plugin (maybe the sample `template` plugin) showing how the plugin can reconnect when the runtime is shut down...