Describe the bug I'm installing this package via Helm (and also directly) onto a cluster of Raspberry Pi 4's that use the arm64 architecture, but the manager pod is failing to start with a CrashLoopBackOff error. This normal indicates that the package that is being installed is built for the wrong architecture (i.e. amd64).

To Reproduce Install the package via Helm.

Expected behavior The pods should start successfully and I should be able to view the .onion address for the service.

Additional information

As per the conversation on #3, I have uninstalled, updated the repo and reinstalled the package, but the issue still persists.

Here is the failing pod description:

Name:         tor-controller-6977fc959f-hvb48
Namespace:    tor-controller
Priority:     0
Node:        ---
Start Time:   Tue, 01 Mar 2022 15:06:39 +0000
Labels:       app.kubernetes.io/instance=tor-controller
              app.kubernetes.io/name=tor-controller
              pod-template-hash=6977fc959f
Annotations:  <none>
Status:       Running
IP:           10.42.0.15
IPs:
  IP:           10.42.0.15
Controlled By:  ReplicaSet/tor-controller-6977fc959f
Containers:
  manager:
    Container ID:  containerd://c63144efa6f93831c4217b145f9a8669ff3b691f8af16a972dd81bfa4f47d0ee
    Image:         quay.io/bugfest/tor-controller:0.5.0
    Image ID:      quay.io/bugfest/tor-controller@sha256:0f142060bba60d422c6c536de766ace73a0a00535fcffaba354260e54e59c1e6
    Port:          <none>
    Host Port:     <none>
    Command:
      /manager
    Args:
      --config=controller_manager_config.yaml
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 01 Mar 2022 15:10:06 +0000
      Finished:     Tue, 01 Mar 2022 15:10:06 +0000
    Ready:          False
    Restart Count:  5
    Liveness:       http-get http://:8081/healthz delay=15s timeout=1s period=20s #success=1 #failure=3
    Readiness:      http-get http://:8081/readyz delay=5s timeout=1s period=10s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /controller_manager_config.yaml from manager-config (rw,path="controller_manager_config.yaml")
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-5gzzm (ro)
  kube-rbac-proxy:
    Container ID:  containerd://5eab9e63e587140e040ef3b804ac9bea7f1bdbf8c4d4cb89f09cde93e0811ccb
    Image:         gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
    Image ID:      gcr.io/kubebuilder/kube-rbac-proxy@sha256:db06cc4c084dd0253134f156dddaaf53ef1c3fb3cc809e5d81711baa4029ea4c
    Port:          8443/TCP
    Host Port:     0/TCP
    Args:
      --secure-listen-address=0.0.0.0:8443
      --upstream=http://127.0.0.1:8080/
      --logtostderr=true
      --v=10
    State:          Running
      Started:      Tue, 01 Mar 2022 15:06:48 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-5gzzm (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  manager-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      tor-controller-manager-config
    Optional:  false
  kube-api-access-5gzzm:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason       Age                    From               Message
  ----     ------       ----                   ----               -------
  Normal   Scheduled    4m58s                  default-scheduler  Successfully assigned tor-controller/tor-controller-6977fc959f-hvb48 to ---
  Warning  FailedMount  4m58s                  kubelet            MountVolume.SetUp failed for volume "manager-config" : failed to sync configmap cache: timed out waiting for the condition
  Normal   Pulled       4m53s                  kubelet            Successfully pulled image "quay.io/bugfest/tor-controller:0.5.0" in 748.656901ms
  Normal   Pulled       4m52s                  kubelet            Container image "gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0" already present on machine
  Normal   Created      4m51s                  kubelet            Created container kube-rbac-proxy
  Normal   Started      4m50s                  kubelet            Started container kube-rbac-proxy
  Normal   Pulled       4m48s                  kubelet            Successfully pulled image "quay.io/bugfest/tor-controller:0.5.0" in 2.019106168s
  Normal   Pulled       4m25s                  kubelet            Successfully pulled image "quay.io/bugfest/tor-controller:0.5.0" in 700.418473ms
  Normal   Created      4m25s (x3 over 4m52s)  kubelet            Created container manager
  Normal   Started      4m25s (x3 over 4m52s)  kubelet            Started container manager
  Warning  BackOff      4m7s (x8 over 4m45s)   kubelet            Back-off restarting failed container
  Normal   Pulling      3m54s (x4 over 4m54s)  kubelet            Pulling image "quay.io/bugfest/tor-controller:0.5.0"

System (please complete the following information):

• Platform: Raspberry Pi 4 Kubernetes cluster - arm64
• Version: Latest

Please default to making multi-arch containers when ever you create a Docker project. More so when creating an Kubernetes one.

$ k logs -n tor example-onion-service-tor-daemon-f8f94c688-mgwp4

standard_init_linux.go:228: exec user process caused: exec format error

Is your feature request related to a problem? Please describe. Traffic to the internet from the onions leak though the normal internet connection

Describe the solution you'd like I would like all traffic in that namespace to route though the Tor network

Describe alternatives you've considered N/A

Additional context It would probably be an value that one could set.

Is your feature request related to a problem? Please describe. I need to be able to control some spec properties on the onion service pods. My immediate pain is that I want to ensure the service continues to run even when the cluster comes under memory or CPU pressure, which means I need to be able to specify a higher priorityClassName for the pods.

It would also be nice to be able to:

1. add tolerations
2. set resource requests/limits
3. specify affinity rules

Additionally, I currently don't have any specific use-cases in mind, but I could envision other users wanting to set other pod properties (ex: labels, annotations, hostNetwork, topologySpreadConstraints, etc). See https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec for a full list of PodSpec properties.

Describe the solution you'd like Add a "template" property to the OnionService spec:

apiVersion: tor.k8s.torproject.org/v1alpha2
kind: OnionService
metadata:
  name: example-onion-service
spec:
  version: 3
  template:
    spec:
      priorityClassName: high-priority
      tolerations: []
      resources: {}
      affinity: {}
  rules: [...]

Rather than manually creating this template spec for this project, it may be best to leverage the existing "PodTemplateSpec" (although this may introduce complications/confusion if users try to define the containers in the spec?).

Describe alternatives you've considered I considered changing the default priorityClass to something higher, and setting all less-crucial workloads to a lower class. This does not work for me, because there are several other 3rd party projects that don't support controlling their workloads' priority, and the OnionService is the only one I would want to be considered a high-priority class.

Additional context I would love to make Onion Services the primary ingress channel into my cluster (potentially even for access to the control-plane), so I am very interested in trying to make it more robust and reliable.

I would be happy to start on a PR to support this, if you are happy with the strategy.

Using a tor v3 private key, created via:

kubectl create secret generic test-onion-key --from-file=hs_ed25519_secret_key

and then referenced in the YAML:

privateKeySecret:
    name: test-onion-key
    key: private_key

as per documentation. the pod fails to create with:

Warning FailedMount 6s (x5 over 14s) kubelet MountVolume.SetUp failed for volume "private-key" : references non-existent secret key: privateKeyFile

I predict its just a configuration error, but I can't seem to debug it and am sure its just missing documentation. Please advise.

FULL YAML:

apiVersion: tor.k8s.torproject.org/v1alpha2
kind: OnionService
metadata:
  name: test-site-deployment-tor
spec:
  version: 3
  rules:
    - port:
        number: 80
      backend:
        service:
          name: test-site-deployment
          port:
            number: 80
  privateKeySecret:
    name: test-onion-key
    key: private_key

Hello, i not understand how work with ingress,

Setup Ingress with 2 paths:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: http-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  defaultBackend:
    service:
      name: service1
      port:
        number: 80
  rules:
  - host: '*.onion'
    http:
      paths:
      - path: /foo/
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 80
      - path: /bar/
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 80

And try setup OnionService:

apiVersion: tor.k8s.torproject.org/v1alpha2
kind: OnionService
metadata:
  name: example-onion-service
spec:
  ... (secrets and other) ...
  rules:
    - port:
        number: 80
      backend:
        service:
          # name: service1  # working
          name: http-app-ingress  # not working. What am I doing wrong?
          port:
            number: 80

I try get onion address from CLI, but no result

kubectl get onion
NAME                    HOSTNAME   AGE
example-onion-service              10m

After 10 min tor pod not available (and not working)

Hello can you please make a x25519 generation feature? For example Tim has a ebook that only a select group of people can access. Rather than needing to contact Tim for auth credentials they can pay a fee and upon payment confirmation be give. There x25519 key.

Service must restart for clients upon revoking but not when being created so I'd imagine it's possible.

Thanks, Kuberwear

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

Describe the bug The 0.1.6 release successfully published the images to the image registry (quay.io) under the latest tag, but does not appear to have published the version pegged tags (0.6.1).

See: https://quay.io/repository/bugfest/tor-controller?tab=tags&tag=latest https://quay.io/repository/bugfest/tor-onionbalance-manager?tab=tags&tag=latest

To Reproduce Install the latest version via helm (0.1.6). Observe images fail to be pulled.

Check https://quay.io/repository/bugfest/tor-controller?tab=tags&tag=latest, and see that 0.6.1 is missing.

Expected behavior Both latest and 0.6.1 image tags should be available on the image repository.

Additional information

Error during pod startup:

Failed to pull image "quay.io/bugfest/tor-controller:0.6.1": rpc error: code = NotFound

System (please complete the following information):

• Platform: amd64
• Version v1.23.8+k3s2

Additional context Installed via helm.

Dear, I would like to use tor-controller as a http proxy to make http request on the web.

Can't see (reading your documentation) how to create a kube service (internal/external) to be bind to the Tor POD (tor launched with the option HTTPTunnelPort:XXX)

Could you help me ?

Describe the bug echoserver container used in the examples is not multiarch. E.g. fails in arm64

To Reproduce

$ uname -m
aarch64

$ kubectl apply -f https://raw.githubusercontent.com/bugfest/tor-controller/master/hack/sample/echoserver.yaml
kubectl get po
NAME                                                READY   STATUS             RESTARTS       AGE
http-app-688bc87b88-t67dm                           0/1     CrashLoopBackOff   10   1h
http-app-688bc87b88-ljn9l                           0/1     CrashLoopBackOff   10   1h

$ kubectl logs po/http-app-688bc87b88-ljn9l
standard_init_linux.go:228: exec user process caused: exec format error

Expected behavior echoserver pod is up

Additional information n/a

System (please complete the following information):

• Platform: arm64
• Version chart 0.1.3 / app version 0.5.0

Additional context n/a

Describe the bug After running an OnionBalancedService for a period of time, eventually the onion address is no longer resolvable.

Attempting to reach my onion service via the tor browser returns:

Onionsite Not Found

An error occurred during a connection to [redacted].onion. 

Details: 0xF0 — The requested onion service descriptor can't be found on the hashring and therefore the service is not reachable by the client.

All "obb" pods appear to be working as expected, but the "daemon" pod potentially has deadlocked after a restart (see below for details). Deleting the daemon pod, and allowing it to be recreated/restarted resolves the issue.

To Reproduce I have not figured out specific steps to reproduce this yet, other than waiting long enough. Although, I have a suspicion it happens when the pod restarts itself (I will continue to try and narrow down more specific repro steps).

Expected behavior The onion service should always be available as long as the daemon and obb pods are running.

Additional information

Logs from the onionbalance container of the daemon pod:

time="2023-01-06T23:08:33Z" level=info msg="Listening for events"
time="2023-01-06T23:08:33Z" level=info msg="Running event controller"
time="2023-01-06T23:08:33Z" level=info msg="Starting controller"
W0106 23:08:33.805173       1 shared_informer.go:372] The sharedIndexInformer has started, run more than once is not allowed
time="2023-01-06T23:08:33Z" level=info msg="Added onionBalancedService: ingress/tor-service"
time="2023-01-06T23:08:35Z" level=info msg="Getting key ingress/tor-service"

NOTE: the actual time is now 8 hours later, so onionbalance has not logged any additional activity for quite some time (deadlock?).

On a successful launch, I see something along the lines of:

[...]
time="2023-01-07T10:50:04Z" level=info msg="Getting key ingress/tor-service"
time="2023-01-07T10:50:04Z" level=info msg="Updating onionbalance config for ingress/tor-service"
reloading onionbalance...
starting onionbalance...
2023-01-07 10:50:15,789 [WARNING]: Initializing onionbalance (version: 0.2.2)...
[...]

System (please complete the following information):

• Platform: amd64
• Version: v1.25.5-k3s1

Additional context This does not happen often, but it has occurred 4 or 5 times over the past ~3 months. Anecdotally, I believe the last few times this has happened was after/around performing system upgrades on my cluster (ex: upgrading Kubernetes, or restarting nodes), where lots of pods are bouncing around.

The remedy is simple (manually restart the daemon pod), but an automated fix would be preferred. If actually resolving the deadlock (if that's truly the issue...) is overly complex to diagnose at this time, I wonder if an easier fix might be to simply add a probe that can properly detect this condition? Any thoughts on how I could do this?