You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. After a little dig into the Workflow I discovered that every application container that is running on deis/slugrunner has an object store credentials volume attached to it. I know that a slugrunner need an access to S3 storage to download a slug tarball, but shouldn't this be considered as a security issue that every user on this container (including application itself) has a read access to those files?
We thought that we could use a defaultMode option in Kubernetes that restrict permissions for mounted volumes to a root user, but it seems that both the init and execution processes of the slugrunner are running as user slug.
Hi. After a little dig into the Workflow I discovered that every application container that is running on deis/slugrunner has an object store credentials volume attached to it. I know that a slugrunner need an access to S3 storage to download a slug tarball, but shouldn't this be considered as a security issue that every user on this container (including application itself) has a read access to those files?
We thought that we could use a defaultMode option in Kubernetes that restrict permissions for mounted volumes to a root user, but it seems that both the init and execution processes of the slugrunner are running as user slug.
Related to: deis/slugrunner#58
The text was updated successfully, but these errors were encountered: