Difference between --cap-add=NET_ADMIN and add capabilities in .yml

Question

i have a question and a problem about capabilities.

Why my program work when i run docker run --cap-add=NET_ADMIN ... ?

And it's doesn't work if i run my program with file .yml which is:

      containers:
      - name: snake
        image: docker.io/kelysa/snake:lastest
        imagePullPolicy: Always
        securityContext:
          privileged: true
          capabilities:
            add: ["NET_ADMIN","NET_RAW"]

What is the difference between run docker with --cap-add and run a pod with the same capabilities ?

Solution

As described by David Maze and According to the docker docs:Runtime privilege and Linux capabilities

By default, Docker containers are “unprivileged” and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a “privileged” container is given access to all devices (see the documentation on cgroups devices).

--cap-add: Add Linux capabilities,
--cap-drop: Drop Linux capabilities,
--privileged=false: Give extended privileges to this container
--device=[]: Allows you to run devices inside the container without the --privileged flag.

When the operator executes docker run --privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host.

In addition to --privileged, the operator can have fine grain control over the capabilities using --cap-add and --cap-drop.

You can find there two kinds of capabilities:

• Docker with default list of capabilities that are kept.
• capabilities which are not granted by default and may be added.

This command docker run --cap-add=NET_ADMIN will apply additional linux capibilities.

As per docs:

For interacting with the network stack, instead of using --privileged they should use --cap-add=NET_ADMIN to modify the network interfaces.

Note:

To reduce syscall attacks it's good practice to give the container only required privileges. Please refer also to Enabling Pod Security Policies.

From container it can be achieved by using:

securityContext:
  capabilities:
    drop: ["all"]
    add: ["NET_BIND"]

To see applied capibilities inside your container you can use: getpcaps process_id or $(pgrep your-proces_name) to list and explore linux capibilities you an use capsh --print

Resources:

• Linux capibilities,
• docker labs,
• capsh
• Configuring Container Capabilities with Kubernetes
• What is a Pod Security Policy

Hope this help.