Roadmap to a stable release - Known issues / TODOs

[s4ke]

General:

• Security issues around Service creation - we might end up with volumes, configs,... we did not create. Possible solution: make the proxy multitenant and manage locking in a database? - proper solution: namespacing
• Filter configs when using them (do we own them)
• Filter secrets when using them (do we own them)
• Filter networks when using them (do we own them) - but allowlist some (traefik-public, Monitoring?)
• Set Labels also on container spec
• configurable: disallow bind mounts?
• docker api version handshake does not work at the moment
• Security issue for tenants - what if an image was downloaded onto the swarm by a different tenant and therefore available to the swarm by accident? - this can be verified in the service create/update command by checking whether with the specified registry auth we can resolve the image/tag/sha hash. If not, we abort the operation with 403.
• See the image security issue - do we need to check for similar issues with the distribution endpoint? - probably fine as it requires the user to send in the authentication headers anyways, but we should check this
• Prepare tutorial on how to use this, What should users expect with this, what is the workflow?
• Unit test coverage for all relevant methods that are not just forwarding operations (all security relevant ones)
• docker Service logs errors out without -f. Solution?: Hand this off to an external nginx as dockerode adds more complexities. But this would introduce all sorts of complexities around SSL handling
• Add support for Certificate Revocation Lists (CRL) for CA authentication - no tutorial, yet though: https://jamielinux.com/docs/openssl-certificate-authority/certificate-revocation-lists.html
• Add support for allowlisting/blocklisting users to support an 'offboarding employees' workflow (handled via CRL)
• Should we be able to configure a default Registry Auth so that users don't have to send docker registry auth themselves. This would not leak user credentials that run docker commands into the cluster. Add support for overriding registry auth and enforcing registry credentials to be the ones we set up and not user credentials.

Namespacing:

• Add support for prefixing of resources to have "namespaces" in the swarm.
• First solution that allows flexibility around tenancy merging and is easier to get right: enforce prefixed names. Don't forget to add the prefixes also to stack labels so docker stack commands work
• Potential V2 with more consideration required: toggleable support for completely separating tenants - i.e. remove prefixes. Probably easier to solve in the organization, but would make the underlying swarm completely transparent to the user transparently

Nice to Haves:

• configurable: disallow features like privileged, cap_add etc?
• Implement cert auth (use field on cert for tenancy? But actual multi tenancy might make things quite complicated, maybe just deploy the proxy multiple times)
• Add support for multitenancy in the proxy itself so that a user can be part of multiple tenants/namespaces - essentially adding RBAC features.
• add default CPU limits / default memory limits
• service creation and update requests should probably be validated against their actual type more. This way, if the docker api changes, we could prevent issues (?)
• Headers are currently dropped due to reliance on dockerode. Not clear if this is a problem as long as the ping endpoint works properly
• What should happen if the user sets the label? Should we send a HTTP 403?
• Should we remove the label in responses?
• Potential: allow docker commands. Make use of this proxy internally to a cluster as well
• Potential: allow execing into arbitrary nodes. But better would be having this as a separate solution or as a contribution to moby/moby?

Really far on the horizon (?)

• Simple UI to interact with the API (only the Swarm parts)
• Full proxy capabilities so that even tools like portainer would work (would probably require full implementation of container api) - probably would even make sense to expose the container API as one single API. To find the relevant container to execute into for example we would have to traverse all nodes and see if the container exists there and then execute against that.