-
Notifications
You must be signed in to change notification settings - Fork 408
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
What user does the container run as? Also is the filesystem read only? #176
Comments
This should be inherited from the base image. We're planning to switch over to a non-root user by default in the future, but haven't done so yet because it may be a breaking change: #160 |
I'm sorry what is inherited? A read only file system? |
Apologies for not responding for so long, this got buried under a lot of other github spam. The base image's config file is used for everything except for static kodata and the compiled binary. By default, we (now) use gcr.io/distroless/static:nonroot as the base, which has a non-root user:
The filesystem is largely timezone info, but this is the rest:
I'm fairly certain that container runtimes are responsible for enforcing the read-only nature of this filesystem, e.g. see here: https://docs.docker.com/engine/reference/commandline/run/#mount-volume--v---read-only Otherwise, that's all that's in the image, so there's not really anything useful for privilege escalation, unless your go binary allows for it. |
This issue is stale because it has been open for 90 days with no |
One other question what capabilities are allowed?
https://man7.org/linux/man-pages/man7/capabilities.7.html
https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privilege-escalation
The text was updated successfully, but these errors were encountered: