SSH not working due to container capability constraints. #161
Labels
No Label
has
backport
in progress
invalid
kind
breaking
kind
bug
kind
build
kind
dependency
kind
deployment
kind
docs
kind
enhancement
kind
feature
kind
lint
kind
proposal
kind
question
kind
refactor
kind
security
kind
testing
kind
translation
kind
ui
need
backport
priority
critical
priority
low
priority
maybe
priority
medium
reviewed
duplicate
reviewed
invalid
reviewed
wontfix
skip-changelog
status
blocked
status
needs-feedback
status
needs-reviews
status
wip
upstream
gitea
upstream
other
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/helm-chart#161
Loading…
Reference in New Issue
Block a user
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?
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
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.
I've added the capability
SYS_CHROOT
and SSH work than fine.volker.raschek referenced this issue2021-06-12 14:34:30 +00:00
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,
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.
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 referenced this issue2021-06-30 18:13:13 +00:00
Ghost referenced this issue2022-08-31 06:59:58 +00:00
alinalex1392 referenced this issue2024-04-16 09:19:08 +00:00