Filter dangerous tools and add an unsafe keyword to enable them

[acmenezes]

No description provided.

[williamcaban]

"dangerous tools" <-- should it be about specific type of system calls and not the tool itself?

[acmenezes]

Yes and no. So yes we should filter system calls that are considered dangerous. But we can't allow somebody to just run unshare for example using podtracer. That would be a disaster. It's an easy way to become root on any namespace. And we need to actually list the tools we support and test. And possibly let a --unsafe flag to allow experimental stuff with a policy to disable the flag on production environments.

[williamcaban]

1. Creating a list filtering commands/tools it is not a scalable model and very easy to circumvent. For example, I can create 'mybadtool' and it will not be in the list, so it will just bypass the filter. Another way, if 'mybadtool' is already in the list, by renaming it to 'ping' it will still be executed. So, filtering tools by name does not address the concern. It would need to focus on systems call and have awareness (a very complex problem) on when/how those are been invoked.

2. If the assumption for podtracer is as a tool for a cluster-admin persona, is this really needed?

[acmenezes]

Those two points are crucial for this issue. Thanks for bringing it here. This way we can have it documented. So to address them here is somehow what we discussed last meeting:

1. The tools that can be used/run by podtracer must necessarily be available in podtracer's image. Which splits our problem in two different venues: a) what are we going to provide within that image by default? and b) from that: what are we going to list as tested and safe?

a) We need to come up with a list of tools that we want to provide on podtracer's image. Initially only networking tools but extensible to other disciplines in the future.

b) Tested and safe means we know it's going to work (because it's been tested) and there is a very specific troubleshooting purpose for that tool in the sense that it's not generic like the unshare command for example that can be run with -r and create a new container running as root based on podtracer's container in that case. So we don't want certain tools to be available because snoopy-operator's ability to run safely relies on this and we would like non-admin users to be able to troubleshoot their applications without super privileges. And that's another point that still needs careful consideration. That said we may have tools available for experimental use that we can enable using a --unsafe keyword. But those will be compiled with podtracer image.

c) On another note: another issue may come up to allow the user to provide his own image with his own tooling. But that is another step and certainly not the scope here.

2. So based on 1b I suspect that no. Podtracer can't be a tool for a cluster-admin persona. Because it's the heart of snoopy-operator. The question is if snoopy-operator should be allowed to non cluster admin personas. For that we don't a clear answer yet. But it will certainly be behind RBAC specific configurations.