Let’s move on to "Read Only" Containers. This exercise will examine read-only containers and how to manage them.
Overview
Imagine a scenario where an application gets compromised. The first thing the bad guy wants to do is to patch a backdoor into the application, so that the next time the application starts up, it starts up with the backdoor in place. If the container was read-only it would prevent leaving a backdoor in place and be forced to start the cycle from the beginning.
A readonly feature was added to container technology but it presents challenges since many
applications need to write to temporary directories like /run
or /tmp
and
when these directories are readonly, the apps fail. Red Hat’s approach
leverages tmpfs
.
From Wikipedia:
tmpfs is a common name for a temporary file storage facility on many Unix-like operating systems. It is intended to appear as a mounted file system, but stored in volatile memory instead of a persistent storage device.
It’s a nice solution to this problem because it eliminates data exposure on the host.
Bottom line: As a best practice, run all applications in production with this mode.
Run a read-only container and specify a few writable file systems using the
tmpfs
option.
sudo podman run --rm -it --name readonly --read-only --tmpfs=/run --tmpfs=/tmp rhel7.6 bash
Now, try the following. What fails and what succeeds? Why?
mkdir /newdir
mkdir /run/newdir
mkdir /tmp/newdir
exit
Domain | ||
Workshop | ||
Student ID |