What is a container?

Objective: understand what is a container

#all the contents come from here


Containers are just normal Linux Processes. Let’s start Redis container.

docker run -d --name=taka redis:alpine

The Docker container launches a process called redis-server

We can check the process with this command.

ps aux | grep redis-server

Check docker top command to check its PID.

docker top <name>

Check who is the PPID with this command

ps aux | grep <ppid>

The command pstree will list all of the sub-processes. As you can see, they are just standard processes.

pstree -c -p -A $(pgrep dockerd)

Process Directory

The configuration for each process is defined within the /proc directory. This command lists all the contents under the proc and store the Redis PID for future use.

DBPID=$(pgrep redis-server) echo Redis is $DBPID ls /proc

Each process has it’s own configuration and security settings defined within different files.

ls /proc/$DBPID

You can see the environment variables settings

cat /proc/$DBPID/environ
docker exec -it taka env


The concept of namespaces is to limit what processes can see and access certain parts of the system, such as other network interfaces or processes.

When a container is started, the container runtime, such as Docker, will create new namespaces to sandbox the process. By running a process in it’s own Pid namespace, it will look like it’s the only process on the system.

The available namespaces are:

Mount (mnt)

Process ID (pid)

Network (net)

Interprocess Communication (ipc)

UTS (hostnames)

User ID (user)

Control group (cgroup)

What happens when we share a namespace?

Namespaces are inode locations on disk.

You can see all the namespaces with this command

ls -lha /proc/<PID>/ns/

NSEnter is used to attach processes to existing Namespaces. Useful for debugging purposes.

nsenter --target <PID> --mount --uts --ipc --net --pid ps aux

namespaces can be shared using the syntax container:<container-name>

If you want to connect nginx to the existing namespace(taka),

docker run -d --name=medium-test --net=container:taka nginx:alpine

check with this command

docker ps -a 

Check Nginx PID

pgrep nginx | tail -n1

It is listed as a namespace after the net has been shared.

ls -lha /proc/<PID>/ns

But, both of the net namespace points to the same place


An important part of a container process is the ability to have different files that are independent of the host. This is how we can have different Docker Images based on different operating systems running on our system.

Chroot provides the ability for a process to start with a different root directory to the parent OS. This allows different files to appear in the root.

Cgroups (Control Groups)

CGroups limit the number of resources a process can consume. The cgroups are values defined in particular files within the /proc directory.

You can check cgroups with this command

 cat /proc/<PID>/cgroup

To check other cgroup directories on disk

ls /sys/fs/cgroup/

What are the CPU stats for a process?

You can check the CPU stats and usage

cat /sys/fs/cgroup/cpu,cpuacct/docker/<container ID>/cpuacct.stat

you can check your container ID with

docker ps -a

The CPU shares limit is also defined here

cat /sys/fs/cgroup/cpu,cpuacct/docker/<container ID>/cpu.shares

All the Docker cgroups for the container’s memory configuration are stored

ls /sys/fs/cgroup/memory/docker/

Each of the directory is grouped based on the container ID assigned by Docker.

ls /sys/fs/cgroup/memory/docker/<container ID>

How to configure cgroups?

One of the properties of Docker is the ability to control memory limits. This is done via a cgroup setting. By default, containers have no limit on the memory.

docker stats <name> --no-stream

The memory quotes are stored in a file called memory.limit_in_bytes.

By writing to the file, we can change the limit limits of a process.

echo 800000 > /sys/fs/cgroup/memory/docker/<container ID>/memory.limit_in_bytes

You can see it has changed

Seccomp / AppArmor

All actions with Linux is done via syscalls. All applications use a combination of these system calls to perform the required operations.

AppArmor is a application defined profile that describes which parts of the system a process can access.

to check the current AppArmor profile

cat /proc/<PID>/attr/current

Seccomp provides the ability to limit which system calls can be made, blocking aspects such as installing Kernel Modules or changing the file permissions.

When assigned to a process it means the process will be limited to a subset of the ability system calls. If it attempts to call a blocked system call is will recieve the error “Operation Not Allowed”.

The status of SecComp is also defined within a file.

cat /proc/<PID>/status |grep Seccomp

The flag meaning are: 0: disabled 1: strict 2: filtering


Capabilities are groupings about what a process or user has permission to do. These Capabilities might cover multiple system calls or actions, such as changing the system time or hostname.

A process can drop as many Capabilities as possible to ensure it’s secure.

cat /proc/<PID>/status |grep ^Cap



Cloud security engineer https://www.linkedin.com/in/takahiro-oda-881423197/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store