SSH not working due to container capability constraints.
Gitea 1.31.2, Kubernets 1.21.1
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 email@example.com: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.
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)?
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
I will adjust the commit again.
Deleting a branch is permanent. It CANNOT be undone. Continue?