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
Is your feature request related to a problem? Please describe.
I get frustrated when I know a node operator or Flux administrator can snoop on my files in a container, easily.
This feature is useful to temporarily store sensitive files that you don't want to persist in either the host or the container writable layer. - (Taken directly from the Docker tmpfs mounts page)
Describe the solution you'd like
Their are two options that you can choose from to implement.
The solution I provided above would allow a user to create their app in a way that only would use the temporary RAMDISK directory that would be constructed as a result of starting the Docker container with either of those flags specified in the link I gave you.
Another option that I tested today that eliminates the ability to access any of the docker containers from a disk and only store those files in RAM is to run this command: mount -t tmpfs -o size=1024m tmpfs /var/lib/docker
The size parameter would need to specified accordingly. Though not sure how it would be able to be implemented in Flux
EDIT: This seems to be very interesting and would (I think) accomplish the same type of behavior.
Is your feature request related to a problem? Please describe.
I get frustrated when I know a node operator or Flux administrator can snoop on my files in a container, easily.
This feature is useful to temporarily store sensitive files that you don't want to persist in either the host or the container writable layer. - (Taken directly from the Docker tmpfs mounts page)
Describe the solution you'd like
Their are two options that you can choose from to implement.
You can find them here: https://docs.docker.com/storage/tmpfs/#use-a-tmpfs-mount-in-a-container
Describe alternatives you've considered
Their aren't really any viable alternatives being that FluxOS control how a container is started.
The text was updated successfully, but these errors were encountered: