lunny/helm-chart
1
0
Fork 1
Code Issues36 Pull Requests14 Actions Packages Projects Releases93 Wiki Activity

SSH not working due to container capability constraints. #161

New Issue
Closed
opened 2021-05-18 12:01:48 +00:00 by krist · 6 comments
krist commented 2021-05-18 12:01:48 +00:00 (Migrated from gitea.com)

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.
👍 1
volker.raschek commented 2021-06-12 14:15:00 +00:00 (Migrated from gitea.com)

@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. ```
volker.raschek commented 2021-06-12 14:22:12 +00:00 (Migrated from gitea.com)

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

I've added the capability `SYS_CHROOT` and SSH work than fine.
justusbunsi commented 2021-06-12 16:37:06 +00:00 (Migrated from gitea.com)

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)?
volker.raschek commented 2021-06-12 16:48:41 +00:00 (Migrated from gitea.com)

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.
justusbunsi commented 2021-06-13 08:20:58 +00:00 (Migrated from gitea.com)

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.
volker.raschek commented 2021-06-13 08:29:53 +00:00 (Migrated from gitea.com)

@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.
Sign in to join this conversation.
No Label
kind/docs
No Milestone Release 4.0.0
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#161
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?