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

Answer 1

Ok, sorry i know all of this and you don't answer correctly to my question.

When i run with docker my program use TC NETWORK ( RTNETLINK) and it's work.

But when i use with kubernetes, it's doesn't work and tell me RTNETLINK answers: No such file or directory

or modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.15.0/modules.dep.bin' modprobe: FATAL: Module sch_netem not found in directory /lib/modules/4.15.0

Answer 2

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.