-
Notifications
You must be signed in to change notification settings - Fork 612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: k8sgpt fails to start with "mkdir /.config: permission denied" #440
Comments
hey @jkleinlercher , thanks for the detailed description of the issue. the Openshift draws attention to the following use case
|
Thanks for your help! I just wonder what needs to be done that k8sgpt can run with restricted-v2 SCC, since it seems to be the most restricted and secured SCC. Also, each serviceaccount gets automatically assigned to restricted-v2 but not to anyuid SCC so serviceaccount k8sgpt would need a special treatment on Openshift. I am not a total expert in this field but eager to learn what is the best way to get this working on Openshift. Either we change the behavior in the dockerfile or we add some special documentation that k8sgpt SA needs a binding to the anyuid clusterrole/SCC and then we probably also need to set the runAsUser in the securityContext so that the anyuid SCC is assigned to this pod… Also looking into https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids Where they say:
|
Also found https://sysdig.com/blog/dockerfile-best-practices/
|
I guess I was able to fix the problem by creating a seperate emptyDir volume and point the env vars XDG_CONFIG_HOME and XDG_CACHE_HOME to this emptyDir volume mountPath. With this the container doesn't need to run with uid 65532. |
that's great @jkleinlercher. The are three potential solutions apart from workarounds that we have to investigate but I am really glad you adjusted it your environment. a) create in Dockerfile the config path, including the file and give permissions to any UID for the time being I suggest to include your workaround in the docs if anyone has bumped into the same issue. |
I don't believe dropping the UID in the container is ideal but what you are describing @jkleinlercher is a valid alternative to me. @AlexsJones any thoughts on that subject? |
dropping the UID in the dockerfile is not needed. Dockerfile can be used without modification. The only thing is the container can be started also with different UID because writing files is now done in an emptyDir volume with the approach in #440 (comment) which is nevertheless a good practice because then you can enable readOnlyRootFilesystem. |
However, because the K8sgpt operator is responsible for creating the deployment ressource, the operator needs to get extended to create an emptyDir volume and set the XDG_ path env variables. |
Yes agreed, |
Joining this conversation a little late but as I understand it the tasks are
|
yes, I think that's a better approach than |
I created #454 to show you the things I changed in the deployment. this PR has only the changes in the helm chart in this repo. If you are fine with this changes I would be happy to create also a PR in the operator repo. |
Sounds good to me, thanks! |
Checklist
Affected Components
K8sGPT Version
v0.3.0
Kubernetes Version
v1.24.0
Host OS and its Version
No response
Steps to reproduce
Environment: OpenShift 4.11 with SCC enabled
Steps to reproduce:
The pod runs by default with "restricted-v2" SCC (https://docs.openshift.com/container-platform/4.11/authentication/managing-security-context-constraints.html). I guess this could be the reason.
securityContext of k8sgpt pod:
and securityContext of the container:
Expected behaviour
K8sGPT should run also on OpenShift with SCC enabled.
Actual behaviour
K8sGPT fails to start on OpenShift 4.11 with SCC enabled.
Additional Information
No response
The text was updated successfully, but these errors were encountered: