SSH not working due to container capability constraints. #161

Closed
opened 1 year ago by krist · 6 comments
krist commented 1 year ago

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.

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.
@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.

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

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)?

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.

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.
Collaborator

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.

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.

@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.
justusbunsi added the
kind/docs
label 1 year ago
justusbunsi added this to the Release 4.0.0 milestone 1 year ago
luhahn closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#161
Loading…
There is no content yet.