[FEAT] Increase granularity of lockdown options

[HazardousBackup]

Is this a new feature request?

• I have searched the existing issues

Wanted change

As it stands there is pretty good granularity with which to add or subtract permissions, however, it'd be nice to be able to go into further detail possibly restricting or allowing individual API calls.

Reason for change

One example of why this would be beneficial is the "containers" permission.
For something like Diun, as far as I can tell it only really needs /containers/json access to be able to get the information it needs.
However, with the containers permission, it also has access to /containers/{id}/json which lets it see a large number of details about a running containers including ENV variables that might include sensitive information depending on the setup.
The containers permission also gives access to /containers/{id}/archive which allows for getting tar archives of files inside another container. The ability to grab arbitrary files from another running container is another permission that should be more heavily restricted.

Proposed code change

In the most extreme case, I'd suggest breaking all the different API calls into their own separate permission. Based on my very basic grasp of how this works, that might require just putting a ton more entries into the templates with checks for their env variables.
This might be made easier by using the OpenAPI yaml available from Docker to generate the necessary options procedurally.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[HazardousBackup]

Related: Tecnativa/docker-socket-proxy/issues/15

netdata/netdata#14806 (comment)

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[HazardousBackup]

I'm replying to prevent this issue from being closed. I've put in a possible pull request and am waiting for further comments or information on how to progress this.

[thespad]

We've discussed this internally and decided not to implement it; if users need the level of granular filtering suggested they would be better off with a tool designed for that purpose such as CetusGuard. The nature of this image means implementing detailed filtering of API endpoints would commit us to monitoring and updating every API change made by Docker to ensure it remained functional and it's not something we have the resources to practically do.