SSH not working due to container capability constraints. #161

Gitea 1.31.2, Kubernets 1.21.1

TLDR;

I setup gitea 1.14.2 on a kubernetes 1.21.1 cluster, using the helm charts. Everything worked except for pushing to the repository using ssh.

I investigated this and found out that this was due to the default capabilities of the container runtime I use (cri-o) not permitting a container to execute a chroot.

The solution is to add the SYS_CHROOT capability to the pod. You can do this in the helm chart

securityContext:
  capabilities:
    add: ["SYS_CHROOT"]

Suggest adding this to the docs.

@krist, I have also a problem with SSH on kubernetes in verion 1.14.2. Are the error messages equal? Otherwise I would create an additional issue.

$ LC_ALL=C git clone git@k8s-demo.internal:admin/test.git
Cloning into 'test'...
Connection reset by 192.168.179.217 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I've added the capability SYS_CHROOT and SSH work than fine.

That's odd. I remember being able to push via SSH using 1.14.2. Will revalidate this.
Are you using root based or rootless image and how do you use SSH (built-in or passthrough)?

Hi @justusbunsi,

Are you using root based or rootless image and how do you use SSH (built-in or passthrough)?

I use a gitea root based and the build-in ssh server.

Oh. I missed the part regarding cri-o container runtime in the issue description. That's definitely a difference in my cluster (I am using containerd). @volker.raschek Do you use cri-o in your cluster, too? Or do you have this problem with another container runtime?

Usually, that's what the securitycontext is designed for. In case there is an issue with the cluster configuration in use, one can fix it by configuring the necessary options for the container in a pod.
If it "only" occurs with cri-o, the SYS_CHROOT capability shouldn't be set as default in the template because it is a security related change granting more permissions than needed for clusters without cri-o runtime. Instead it would be great to mention it in the README and/or in values file to give this caveat knowledge to the users.

@justusbunsi Yes I use the cri-o runtime on all of my cluster nodes.

the SYS_CHROOT capability shouldn't be set as default in the template because it is a security related change granting more permissions than needed for clusters without cri-o runtime

This would be great. Maybe it make sense to add this lines into the values.yaml but only commented and described. This allows cio-o users to comment the line accordingly.

Additionally it make sense to describe it in the README.md.

I will adjust the commit again.