Systemd, Capabilities, and Kubernetes

Systemd, Capabilities, and Kubernetes

90% of DevOps roadmaps are inaccurate, focusing only on the tools

You can't separate Linux from Kubernetes.

In fact, you can't separate Linux from DevOps.

Today's use case is a demonstration of how Linux Systemd and capabilities are related to Kubernetes in a security context.

What is Systemd?

Systemd is an init system and service manager for Linux, handling everything from the boot process to managing services and system resources in userspace (where programs run outside the Linux kernel).

It doesn’t just start and stop services—it can do so much more!

Systemd typically runs as the first process on boot (PID 1), and includes a command-line tool called systemd-analyze security, which checks if services are using security options and assigns each an “exposure” score.

Here’s a sample result:

Based on analyzing your services, you need to tune up the security settings.

What are Capabilities?

Capabilities in Linux are a way to split up the traditionally all-powerful root privileges into smaller, more specific permissions.

This means a process can have just the permissions it needs without full root access, enhancing security.

Currently, there are 40 capabilities available, ranging from very specific to broader permissions.

To manage capabilities, the Linux kernel defines several "sets":

typedef struct cap_data {
    uint32_t effective;
    uint32_t permitted;
    uint32_t inheritable;
} cap_data_t;

These sets include:

Effective: capabilities currently in use by the process.

Permitted: capabilities the process is allowed to use.

Inheritable: capabilities that can be passed on to child processes.

In addition to these, there’s the bounding set (the maximum capabilities a process can hold) and the ambient set (capabilities actively in effect for the process).

How Systemd, Capabilities, and Kubernetes Come Together

Let’s look at a real-world example of securing a PostgreSQL container in Kubernetes.

Systemd Security Check: We analyze PostgreSQL’s Systemd service with systemd-analyze security to review any security gaps and address them by limiting capabilities.

systemd-analyze security postgresql

Capabilities Restriction in Systemd: We update the PostgreSQL Systemd unit service files to modify the capabilities it can use, improving host-level security

…

[Service]

ExecStart=/usr/lib/postgresql/15/bin/postgres -D /var/lib/postgresql/data

CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE

AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE

…

Capabilities in Kubernetes: Finally, we configure a Kubernetes Pod for PostgreSQL, specifying only the necessary capabilities at the container level.

apiVersion: v1

kind: Pod

metadata:

name: postgresql

labels:

app: postgresql

spec:

containers:

- name: postgres

image: postgres:15

ports:

- containerPort: 5432

securityContext:

capabilities:

add:

- NET_BIND_SERVICE

- DAC_OVERRIDE

readOnlyRootFilesystem: true

allowPrivilegeEscalation: false

runAsNonRoot: true

restartPolicy: Always

This gives you the ability to deploy containers in Kubernetes with precise, fine-grained permissions and broad access controls.

Remember,

DevOps is 20% building, 80% optimizing and operating.

Get the 'Day 0' basics right (especially Linux) before jumping into tools.