zenoh

zenoh copied to clipboard

Hi, Is it possible to have access control to keys? An ability to control the visibility and write access may be useful in some scenarios.

Regards, Sojan

Hi @sjames , This feature is indeed on our roadmap, but not yet implemented.

Hi @JEnoch!

Thought I would check in to see if there is any update on this (i.e. in which months it might be tackled)?

Hi @luca-della-vedova,

This is still on our roadmap, but not for short term (i.e. at least not for the next 3 months). We are still thinking about the options we may have for this. But they also depend on use cases:

• on which authentication mechanism do we base access control ? (X.509 certificates? user/pass? other?)
• do we need access control in also in peer-to-peer, or only made by the zenoh routers ?
• can we assume that the zenoh routers are trusted, or shall we take (more complex) measures to prevent a "rogue router" that would not apply access control correctly ?
• or shall we have a totally different approach as suggested in #97 ?

What would be your use case and your desired deadline for this feature ?

Hi @JEnoch

I think you should start discussing the security concepts while the protocol is evolving rather than having to change something later on due to security. If there is one issue that may prevent me from deploying Zenoh on a product today, it is security. This may not be an issue when working on a private network, but still the implementation and more importantly, the spec seems incomplete without security.

If I may, I'll try to write my thoughts on the points you raised.

1. Authentication mechanism: Since this is a distributed, no broker mechanism, asymmetric keys would be a natural fit. This is already well defined and would make sense to stick to standard protocols and algorithms. JWT does this without having to store anything on the router.
2. I expect that there will be different levels of mechanisms needed simultaneously. I can think of a use-case where peers must authenticate each other. I read that the clients authenticate the routers in the current implementation. The reverse must also be possible - routers must only allow authentic clients.

Regards, Sojan

I believe this is related to issue https://github.com/eclipse-zenoh/roadmap/issues/8 on the Roadmap. Posted here for tracking.

I noticed https://github.com/eclipse-zenoh/roadmap/issues/8 was closed as completed but there is no referenced diff and I'm guessing perhaps it has been pushed back?

Assuming that it isn't implemented already, does anyone know if the plugin system would be capable of allowing implementation of some simple ACL for subtrees in routers, based perhaps on authenticated username?