GoogleContainerTools
Proposal: read-only filesystem in images?
When creating a distroless from a build container, for security I do COPY --chmod=a-w to make all my project files read-only, and later I use a volume on /home/nonroot to have a read-write space where to store my app data, outside of the container.
To improve secury, I would like to have ALL the filesystem without write permissions. I know I can achieve it with --readonly flag when running docker, but it's an opt-in, and can easily be forgotten. Another option would be to create another distroless image, using an empty base image and copy all the files from the original generated distroless image, but it's a bit cumbersome.
My question is, does it makes sense, since distroless images promotes security, that they are already provided without write permissions on its filesystem? Only concern I have is about the /home/nonroot folder, since when creating the volume, its fully copied on the volume on first run, including the folder permissions, so the volume would become read-only too... or we would need to left the folder as read-write, so that would not prevent to use it without a volume and content would still be written in the container...
Ok, i got confused about the volumes, once it's defined, It will always create an anonimous or named one, si It will never write in the imagen. Said that, It would be just needed to remove all write permissions except for the /home/nonroot fólder, so we can write in the volume.
Would It makes sense to set nonroot home to /data to make It easier to apply the volume, and fully remove the /home directory? The same for /root fólder, i think there's no reason to have It for a nonroot imagen except for some kind of compatibility... Isn't It?
I know I can achieve it with --readonly flag when running docker, but it's an opt-in, and can easily be forgotten.
I think it would be much easier to enforce the use of a read only root fs. I know that for Kubernetes there are several linters that enforce the use of securityContext.readonlyRootFilesystem=true.
I'm not a maintainer, just a fan of distroless.
I think it would be much easier to enforce the use of a read only root fs.
Exactly, that's why I would like to have the image having no write permissions, so effectively is like having a read only root fs :-)
It's also possible with some config to have that with phisical installs, so having it with docker images should be fairly trivial, if there's already a flag for it. It's just a matter programs must be conscious about that, to don't try writting where they can't do it.
:D sorry, I meant "enforce the use of running containers with a read-only file system using the container runtime's available settings", not doing it at the image level.
They are not incompatible, in my opinión, the more security layers, the better.