> ## Content Index
> Fetch the complete content index at: https://devopscube.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Linux Capabilities In Containers & Kubernetes
- URL: https://devopscube.com/linux-capabilities/
- Published: 2025-04-10T03:59:37.000Z
- Updated: 2025-07-28T04:53:25.000Z
- Author: Bibin Wilson
- Tags: #blog, LINUX

In this blog, we will look a little deeper into Linux Capabilities to understand how they relate to containers and Kubernetes using practical examples.

By the end of the guide, you will understand

1. What Are Linux Capabilities?
2. Linux Capabilities in Containers
3. Adding Linux Capabilities in Kubernetes pods
4. Analyzing Capabilities using systemd

In our container non-root blog, I mentioned the concepts of Linux Capabilities.

It is an overlooked security feature that plays a key role in container security and Kubernetes configurations.

## What Are Linux Capabilities?

In traditional Linux, a process is either **root** (superuser) or **non-root** (restricted). A concept you all know.

Linux Capabilities was introduced in kernel 2.2\. Before that,

- Processes either had root privileges (**Privileged processes (UID=0)**: Full root access.)
- Regular user privileges (**Non-privileged processes (UID≠0)**: Limited permissions.

The problem with this approach was if a non-root user program needed to run one privileged operation, it had to run with full root access. For example, binding to a ports below 1024 that require root privileges.

What if there is a way to give a non-root user privileged access to just that one operation?

That is what Linux Capabilities solve.

Linux capabilities solve this by segregating root privileges into separate units that can be given access individually.

For example,

1. **CAP\_NET\_BIND\_SERVICE:** To grant the permission to bind to privileged ports.
2. **CAP\_NET\_ADMIN**: Allows modifying network interfaces, routing tables, and other network configurations.
3. **CAP\_SYS\_TIME**: To modify the system clock.
4. **CAP\_DAC\_OVERRIDE:** Bypasses discretionary access control (DAC), allowing a process to ignore file permission checks.
5. **CAP\_CHOWN:** Allows changing the ownership of files, bypassing normal user restrictions.
6. **CAP\_NET\_RAW:** Allows sending and receiving raw packets (e.g., crafting custom network packets). Used in tools like `ping` and `tcpdump`.

![](https://blog.techiescamp.com/content/images/2025/01/image-98.png)

With this, a non-root user can be granted only **CAP\_NET\_BIND\_SERVICE** to bind to a privileged port while blocking all the other root related access.

Just run the following command to list all the supported capabilities in Linux.

```bash
man capabilities
```

There are 50 different capabilities in today's Linux kernel (I tested this on an Ubuntu server).

![](https://blog.techiescamp.com/content/images/2025/01/image-99.png)

Now that we have an understanding of Linux capabilities, let's understand how containers and Kubernetes use them.

## Linux Capabilities & Containers

By default, containers run as root (unless you run as non-root).

But this doesn’t mean they have full root privileges on the host.

Docker and other container runtimes **use Linux Capabilities to restrict container permissions** for enhanced security. This make the container environment more secure, even though the user ID (UID 0) remains the same inside the container and on the host.

Docker, for instance, drops many Capabilities by default and uses only the required Capabilities.

Containerd code shows these default allowed capabilities.the 

CRIO has the following defaults. [Refer doc here.](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md??ref=devopscube.com)

![](https://blog.techiescamp.com/content/images/2025/01/image-100.png)

Let's look at an example using Docker.

Let's try to create a BusyBox container to create a dummy network interface.

```bash
$ docker run --rm -it \
    --name test_no_cap busybox sh

/ # ip link add dummy0 type dummy
ip: RTNETLINK answers: Operation not permitted
```

As you can see, the container lacks `CAP_NET_ADMIN`, so it cannot modify network interfaces.

The `--cap-add` is used to grant additional Linux capabilities to a container.

Now, run the same container but with the required capability using `--cap-add=NET_ADMIN` flag.

```bash
$ docker run --rm -it --cap-add=NET_ADMIN \
    --name test_with_cap busybox sh

/ # ip link add dummy0 type dummy
/ # ip link show dummy0
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop qlen 1000
    link/ether 0a:0c:31:af:1e:0b brd ff:ff:ff:ff:ff:ff
```

Since the container has `CAP_NET_ADMIN`, it **can** create network interfaces.

## Kubernetes and Linux Capabilities

When it comes to kubernetes, You can **add** or **drop** Linux capabilities in your `SecurityContext` to reduce attack surfaces.

Let's understand this with an example.

When you run a pod with a `BusyBox` image, by default, you will be able to use `ping`.

For example:

```bash
$ kubectl run ping-pod \
      --image=busybox --restart=Never \
      -it -- sh -c "ping 8.8.8.8"

64 bytes from 8.8.8.8: seq=1 ttl=61 time=13.500 ms
64 bytes from 8.8.8.8: seq=2 ttl=61 time=16.598 ms
64 bytes from 8.8.8.8: seq=3 ttl=61 time=16.262 ms
```

Now, let's say you don't want to allow the BusyBox pod to perform `ping`.

In this case, we **drop** the `NET_RAW` capability using the **Security Context**.

> The NET\_RAW capability allows a container to create and use raw network sockets. This is required for commands like ping and some network debugging tools.  
>  
> By dropping NET\_RAW, we prevent the container from sending raw packets

For example, 

```YAML
apiVersion: v1
kind: Pod
metadata:
  name: busybox-ping
spec:
  containers:
  - name: busybox
    image: busybox:latest
    command: ["sleep", "3600"]
    securityContext:
      capabilities:
        drop:
          - NET_RAW
```

If you deploy this pod and try ping, you will get the following error.

```bash
$ kubectl exec -it busybox-secure -- ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: permission denied (are you root?)
command terminated with exit code 1
```

## Analyze Capabilities With Systemd

In Linux systems, the command **`systemd-analyze security`** is used to **evaluate the security of systemd services** by analyzing their sandboxing and security features.

It inspects how a service is configured in terms of Capability restrictions (e.g., `CAP_NET_ADMIN`, `CAP_DAC_OVERRIDE`) and more.

Here is an example output of `systemd-analyze security`command.

![](https://blog.techiescamp.com/content/images/2025/02/image-2.png)

 c

You can further analyse a specific service using the unit name.

For example,

```bash
systemd-analyze security apache2.service
```

![](https://blog.techiescamp.com/content/images/2025/02/image-3.png)

## Conclusion

Linux capabilities play an important role in enforcing the **principle of least privilege** by allowing fine-grained control over what processes can do.

For **DevOps engineers**, being **proactive** about these best practices is important.

Security should not be an afterthought.

I’ve seen teams rushing to fix clusters after a security audit when issues could have been prevented earlier.

By taking **small but smart security steps** wherever necessary**,** you can avoid last-minute surprises and keep your infrastructure safe from the start.

If you have any doubts about this blog, drop it on the comment!

Want to Stay Ahead in DevOps & Cloud? Join the Free Newsletter Below.