Closed pf0 closed 2 years ago
Hi @pf0, thanks for your suggestion. I see this approach is aligned with https://community.torproject.org/onion-services/advanced/client-auth/ - I'll start preparing a draft for the OnionService part and think on also implementing the client-side configs in the Tor object spec. Keep you posted
Hi @pf0, authorized clients feature has been implemented and published in version 0.7.0 (helm chart version 0.1.7). You have an example at hack/sample/onionservice-authorizedclients.yaml
and a guide at https://github.com/bugfest/tor-controller/blob/master/README.md#enable-onion-service-protection-with-authorization-clients
Currently, the tor-controller does not support the client authorization functionality that onion services provide, resulting that authorization configuration needs to be handled via the god old-fashioned way, so separately from manifest-based onion service configuration. This makes it tedious when you want to use authorization for multiple onion services. For example, let's say you want to grant certain clients access to both an onion services pointing to a Gitea instance and a second onion service pointing to a Wiki.
I would propose using secrets for storing client authorization public keys, and mount all linked secrets within an onion service's manifest to it's corresponding '/authorized_clients' directory. So, the structure could look similar to the one shown in the following image:
Using this structure would also allow restriction or enhancement of client access to specific services with a quite administrator-friendly approach.
This is just a draft, so if you have a more suitable approach or an enhancement idea, please comment your ideas and thoughts below.
Greetz pf0