DEV Community: Matsuoka Seiji

Introducing Security Profiles for Container Permission Management

Matsuoka Seiji — Tue, 16 Jun 2026 10:38:19 +0000

Introduction

In this article, I want to introduce Security Profiles, a feature I added to Raind, a container runtime I have been developing.

In a previous article, I introduced Raind as a runtime that aims to handle Docker-like standalone container execution and Kubernetes-style resources such as Pod, Deployment, Service, and Ingress as part of a single runtime stack.

GitHub repository: https://github.com/shizuku198411/Raind

This time, I would like to talk about one of the main features in the recent release: Security Profile.

A Security Profile is a reusable profile that manages security-related container settings such as Linux capabilities, seccomp, and AppArmor.

In Docker, capability management is usually done through command-line options such as --cap-add and --cap-drop.

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

This is flexible, but when the same security configuration needs to be maintained across multiple containers or environments, it can gradually become harder to manage.

For example:

It becomes difficult to see which container has which capabilities
Development and production environments may end up with different settings
Unexpected capabilities may remain enabled without being noticed
Capabilities, seccomp, and AppArmor settings are not easy to view as one security policy

To solve this, Raind introduces Security Profiles as a way to visualize, reuse, and manage these settings as a single unit.

What is a Security Profile?

A Security Profile is a named configuration that groups container security settings together.

Currently, a profile mainly manages the following settings:

Security Profile
  ├── Linux capabilities
  ├── seccomp deny filter
  └── AppArmor profile name

When creating or running a container, you can specify a profile with --security-profile.

raind container run --security-profile deploy nginx:latest

Instead of directly listing fine-grained capabilities for every container, you can express the intent like this:

Run this container with the deploy profile

Raind aims to handle containers, Pods, traffic policies, and network observability inside the runtime itself.

Security Profile follows the same direction: instead of treating security settings as scattered command-line options, Raind treats them as something closer to a runtime-managed resource.

Built-in Profiles

Raind provides several built-in profiles.

Here is the current list of built-in profiles:

Profile	Use case	Summary
`default`	Standard execution	Raind's default capability set + seccomp + AppArmor
`dev`	Development	Currently similar to `default`, intended as a development baseline
`deploy`	Application deployment	Drops `CAP_NET_RAW` and `CAP_MKNOD` from `default`
`restricted`	Stronger restriction	Uses an empty base capability set
`privileged`	Workloads that require broad privileges	Enables a wide set of known capabilities and disables seccomp / AppArmor
`unconfined`	Keep default capabilities but remove confinement	Keeps default capabilities while disabling seccomp / AppArmor

If no profile is specified, default is used.

The profiles I personally consider especially important are deploy and restricted.

The deploy profile is intended for typical application workloads. It removes CAP_NET_RAW and CAP_MKNOD from the default capability set.

CAP_NET_RAW is related to raw sockets, which are often unnecessary for typical web applications.

CAP_MKNOD is related to creating device files, which is also not usually required for general application containers.

So the intended usage is to start with deploy as a baseline for application workloads, and only add extra capabilities when they are actually needed.

Listing Profiles

Security Profiles can be listed from the CLI.

raind security profile ls

list is also available as an alias.

raind security profile list

The output looks like this:

NAME          TYPE      CAPABILITIES  SECCOMP   APPARMOR
default       built-in  14 caps       enabled   raind-default
dev           built-in  14 caps       enabled   raind-default
deploy        built-in  12 caps       enabled   raind-default
restricted    built-in  0 caps        enabled   raind-default
privileged    built-in  41 caps       disabled  -
unconfined    built-in  14 caps       disabled  -

This makes it possible to check the number of capabilities, whether seccomp is enabled, and which AppArmor profile is used.

Instead of having to inspect each container's launch command to understand its security settings, Raind exposes them as profiles.

Inspecting a Profile

You can inspect the details of a profile with show.

raind security profile show deploy

This shows the actual capabilities, seccomp configuration, and AppArmor profile used by the profile.

name: deploy
type: built-in
capabilities:
    base:
        - CAP_CHOWN
        - CAP_DAC_OVERRIDE
        - CAP_FSETID
        - CAP_FOWNER
        - CAP_SETGID
        - CAP_SETUID
        - CAP_SETFCAP
        - CAP_SETPCAP
        - CAP_NET_BIND_SERVICE
        - CAP_SYS_CHROOT
        - CAP_KILL
        - CAP_AUDIT_WRITE
seccomp:
    defaultAction: SCMP_ACT_ALLOW
    defaultErrnoRet: 1
    architectures:
        - SCMP_ARCH_AARCH64
    syscalls:
        - names:
            - bpf
            - perf_event_open
            - kexec_load
            - open_by_handle_at
            - ptrace
            - process_vm_readv
            - process_vm_writev
            - userfaultfd
            - reboot
            - swapon
            - swapoff
            - open_by_handle_at
            - name_to_handle_at
            - init_module
            - finit_module
            - delete_module
            - kcmp
            - mount
            - unshare
            - setns
          action: SCMP_ACT_ERRNO
          errnoRet: 1
apparmorProfile: raind-default

This profile-based approach is important from a security perspective.

If you only keep stacking --cap-add and --cap-drop options, the final permission set becomes harder to understand. As the number of added or dropped capabilities grows, it becomes easier to accidentally end up with a capability set that was not intended.

By managing these settings as a profile, it becomes easier to explain:

This workload runs with this permission baseline

That makes the configuration more readable and easier to audit.

Applying a Profile to a Container

A Security Profile can be specified when creating or running a container.

raind container run --security-profile deploy nginx:latest

It can also be used with container create.

raind container create \
  --name web \
  --security-profile restricted \
  nginx:latest

raind container start web

When a Security Profile is specified, the profile is used as the base capability set.

You can also apply container-specific differences with --cap-add and --cap-drop.

raind container run \
  --security-profile deploy \
  --cap-add CAP_NET_BIND_SERVICE \
  --cap-drop CAP_NET_RAW \
  nginx:latest

In this case, Raind first resolves the deploy profile, then applies the container-specific capability changes on top of it.

In other words:

Profile = baseline policy
cap-add / cap-drop = per-container difference

This separation makes it easier to keep shared security policies in profiles, while still allowing small per-container adjustments when necessary.

Creating a Custom Profile

If you frequently need to combine --security-profile, --cap-add, and --cap-drop, it usually means that the built-in profiles are not enough for that use case.

For that reason, Raind also supports custom profiles.

A custom profile can extend an existing built-in profile or another custom profile, then adjust the capability set with add-cap and drop-cap.

For example, here is a custom development profile that extends dev, adds CAP_SYS_PTRACE, and drops CAP_NET_RAW.

apiVersion: raind.io/v1
kind: SecurityProfile
metadata:
  name: custom-dev
spec:
  extends: dev
  add-cap:
    - CAP_SYS_PTRACE
  drop-cap:
    - CAP_NET_RAW

You can register it with:

raind security profile register -f custom-dev.yaml

After registration, it can be used in the same way as built-in profiles.

raind container run --security-profile custom-dev alpine:latest sh

Currently, custom profiles mainly handle capability differences.

seccomp and AppArmor settings are inherited from the parent profile. In the future, I would like to make seccomp and AppArmor more configurable from custom profiles as well.

Why Manage This as a Profile?

Container security settings may look like small launch options when viewed individually.

However, in practice, they are strongly related to the nature of the workload and the security policy of the environment.

For example, the profiles can represent different baselines:

dev
  Baseline that prioritizes development convenience

deploy
  Baseline for typical application workloads

restricted
  Strongly restricted baseline

privileged
  Explicitly privileged workload baseline

If these are expressed only through repeated --cap-add and --cap-drop options, the command becomes longer and the meaning of the configuration becomes harder to understand.

A profile gives a name to the security intent, not just to the list of capabilities.

raind container run --security-profile deploy nginx:latest

From this command, you can immediately tell that the container is intended to run with the deploy baseline.

Then, by running raind security profile show deploy, you can inspect the actual capability set, seccomp settings, and AppArmor profile.

The main purpose of Security Profile is to bring the security intent and the actual runtime configuration closer together.

How This Differs from Docker

Docker already supports security-related mechanisms such as Linux capabilities, seccomp profiles, and AppArmor profiles.

For example, capabilities can be adjusted with --cap-add and --cap-drop, and seccomp or AppArmor can be configured with security options.

However, these are usually specified as individual container launch options.

Raind's Security Profile is different in that it groups capabilities, seccomp, and AppArmor into a named runtime-level profile.

The difference is not that Docker lacks security features. Docker already has many of them.

The difference is that Raind tries to manage these settings as a reusable profile that represents the security baseline of a workload.

Docker:
  container run options
    ├── --cap-add
    ├── --cap-drop
    ├── seccomp option
    └── AppArmor option

Raind:
  security profile
    ├── capabilities
    ├── seccomp
    └── AppArmor

This makes it easier to ask questions such as:

Which security baseline is this workload using?
What capabilities does this profile allow?
Is seccomp enabled for this profile?
Which AppArmor profile is applied?

The Raind Direction

As mentioned in the previous article, Raind already handles traffic policies and netflow logs inside the runtime.

Security Profile is another step in the same direction.

Raind
  ├── Container / Pod execution
  ├── Service / Ingress
  ├── Traffic Policy
  ├── Netflow Observability
  └── Security Profile

Raind is not only trying to run containers.

The goal is to let the runtime manage:

Which communication is allowed
Which communication actually happened
Which permissions a container has
Which seccomp / AppArmor settings are applied

This is still experimental, but Raind is gradually becoming more like a workload runtime rather than just a docker run alternative.

Conclusion

In this article, I introduced Security Profile in Raind.

With Security Profile, container security settings such as capabilities, seccomp, and AppArmor can be managed as named profiles instead of being scattered across command-line options.

This makes it easier to:

List and inspect security settings
Define workload-specific baselines
Reduce configuration differences between environments
Notice unexpected capability grants
Understand the execution intent from the container command

In the future, I would like to improve custom profiles so that they can manage seccomp and AppArmor in a more flexible way. I also want to integrate Security Profiles more deeply with Kubernetes-style resources such as Pod and Deployment.

Raind is still under development, but I will continue building it toward a runtime that can manage workload execution, networking, observability, and security together.

What if Docker-like local containers and Kubernetes-like workload resources shared the same runtime path?

Matsuoka Seiji — Tue, 16 Jun 2026 09:41:33 +0000

Github Repository: https://github.com/shizuku198411/Raind

Docker-like containers, Kubernetes-inspired resources, and runtime-level observability in one local runtime

Container tooling is usually split across several layers.

Docker-style tools are great when you want to build an image, run a single container, publish a port, mount a directory, or quickly inspect logs.

Kubernetes-style systems are great when you want to describe workloads as Pods, Services, Deployments, and network-oriented resources.

But in local development and runtime experimentation, these layers often feel disconnected. A single container, a multi-container application, and a Kubernetes-style workload are usually treated as separate worlds, even though they eventually depend on the same Linux primitives: namespaces, cgroups, mounts, networking, process execution, and runtime state.

Raind is an experimental project that tries to connect these layers.

Raind is a local container runtime and lightweight workload orchestrator for Linux. It provides Docker-like container commands, Kubernetes-inspired workload resources, runtime-managed networking, traffic visibility, security policy, and rootless container support through one runtime stack.

The project is still early and under active development, but the goal is clear:

Make container-level and workload-level execution testable, controllable, and observable through one consistent runtime path.

Why I Built Raind

Modern container workflows are powerful, but they can also become fragmented.

When using Docker-like tools, the experience is simple and direct:

docker run nginx
docker exec ...
docker logs ...

But once the workload grows beyond a single container, the user often moves to another layer: Compose, Kubernetes, service meshes, network policy engines, observability tools, and runtime-specific debugging tools.

Each tool solves a real problem, but the overall development experience can become harder to reason about:

Where is the workload state managed?
Which component owns networking?
Which layer applies policy?
Where can I see container-to-container traffic?
Can I test Kubernetes-like resources locally without leaving the runtime model?
Can single containers and Pod-style workloads share the same execution foundation?

Raind was started as an experiment to answer these questions from the runtime side.

Instead of treating container execution, workload resources, network policy, and traffic logs as unrelated systems, Raind tries to make them part of the same runtime architecture.

The Runtime Stack

Raind is split into three main layers:

raind CLI
  -> condenser
    -> droplet

`raind` CLI

raind is the user-facing command-line tool.

It exposes workflows for containers, images, networks, resources, Bottles, policies, and logs:

raind image ...
raind container ...
raind network ...
raind resource ...
raind bottle ...
raind security policy ...
raind logs ...

Condenser

Condenser is the high-level runtime service.

It owns image handling, container state, networking state, Kubernetes-style resource stores, controllers, policy state, DNS handling, netflow logs, Service and Ingress behavior, and the generation of low-level runtime specs.

Condenser does not directly become a container process. Instead, it manages workload intent and delegates low-level container execution to Droplet.

Droplet

Droplet is the low-level OCI-style runtime layer.

It is responsible for Linux container mechanics such as namespace setup, mount setup, pivot_root, cgroups, capabilities, seccomp, AppArmor on-exec handling, runtime state, attach, and exec.

This split allows Raind to keep high-level workload management and low-level container execution separate, while still making them part of one runtime path.

Docker-Like Container Workflows

At the container level, Raind supports a familiar Docker-like workflow.

For example:

raind container run --name web -p 8080:80 nginx:latest
raind container exec web /bin/sh
raind container logs web
raind container stop web
raind container rm web

A Raind container can use image references, published ports, bind mounts, environment variables, commands, logs, lifecycle operations, and exec.

Under the hood, the container is executed through Droplet. That means container lifecycle operations eventually pass through the same low-level runtime path used by higher-level workload resources.

The container unit is useful for:

testing a single image
debugging runtime behavior
checking lifecycle behavior
running local services
validating namespace, mount, networking, and exec behavior

Bottles: Local Multi-Container Application Units

Raind also includes a concept called a Bottle.

A Bottle is a local multi-container application unit. It is intended for workloads that are larger than one container but do not necessarily need a full Kubernetes-style manifest.

A Bottle can describe multiple services, ports, mounts, dependencies, environment variables, and policy behavior in one YAML file.

Typical commands look like this:

raind bottle create -f bottle.yaml
raind bottle start wordpress
raind bottle show wordpress
raind bottle stop wordpress

The idea is similar in spirit to local multi-service application definitions, but Raind keeps the Bottle inside its runtime model. That means Bottle workloads can share the same container lifecycle, networking, policy, and observability mechanisms as other Raind workloads.

This is especially useful when testing communication between containers.

For example, instead of only asking “did the containers start?”, Raind can also help answer:

Which container is talking to which other container?
Is that communication expected?
Should this east-west traffic be allowed?
Can I observe the traffic from the runtime?

Kubernetes-Inspired Resources

Raind also supports Kubernetes-style resource workflows.

The goal is not to replace Kubernetes. Instead, Raind provides a local runtime path for experimenting with Kubernetes-inspired workload concepts.

Raind currently supports resources such as:

Namespace
Pod
ReplicaSet
Deployment
Service
Ingress

Example workflow:

raind resource apply -f app.yaml
raind resource pod ls
raind resource replicaset ls
raind resource deployment ls
raind resource service ls
raind resource rm -f app.yaml

A Pod groups one or more containers into a shared runtime unit. ReplicaSet and Deployment add reconciliation behavior. Service provides stable traffic handling for matching Pods. Ingress provides external routing through Raind’s local runtime layer.

The important part is that these resources are not managed by a completely separate execution path. They eventually map back to the same low-level container runtime foundation.

This makes Raind useful for testing transitions between:

a single local container
a multi-container local application
a Pod-like workload
a Deployment-like reconciled workload
a Service-routed workload

Runtime-Level Policy and Netflow

One of the most important goals of Raind is to make workload communication visible and controllable from the runtime.

Raind includes runtime-managed policy and netflow logging.

Policy types include:

east-west container-to-container policy
namespace egress observation
namespace egress enforcement

Example policy command:

raind security policy add --type ew \
  --source frontend \
  --destination backend \
  --protocol tcp \
  --dport 8080 \
  --comment 'allow frontend to backend'

raind security policy commit

Raind also records network flow logs:

raind logs netflow --line 50
raind logs netflow --json
raind logs netflow -t web

The runtime can enrich traffic logs with metadata such as container ID, container name, IP address, interface, and identity information when available.

This is one of the areas where Raind’s workload-centric model becomes useful.

In many local environments, a workload may start correctly, but traffic visibility is still difficult. You might know that a frontend cannot reach a backend, but you may not immediately know whether the traffic was sent, where it went, whether it matched a policy, or how it maps back to runtime entities.

Raind tries to make those questions part of the runtime experience.

Rootless Containers

Raind also supports rootless execution for standalone containers.

Rootless support is currently focused on containers created through raind container run and raind container create. Pod-managed rootless containers are not supported yet.

Raind currently provides two rootless mapping modes.

`shifted-root`

This is the default rootless mode.

In this mode, container UID/GID ranges are shifted into a subordinate host ID range.

Conceptually:

container 0..65535 -> host 100000..165535

This isolates container root from the login user, but files written to bind mounts by container root may appear as subordinate host IDs.

`login-root`

The login-root mode is designed for a more Docker-rootless-like local development experience.

In this mode, container root maps to the invoking login user:

container 0        -> host login UID/GID
container 1..65535 -> host subordinate UID/GID range

This is useful when a development container writes into a bind-mounted project directory and the host user should be able to edit or remove the files without manual chown.

Example:

mkdir -p /tmp/raind-login-root

raind container run --name login-root-demo \
  --rootless-mode login-root \
  -v /tmp/raind-login-root:/data \
  alpine:latest /bin/sh -c 'id; echo hello > /data/hello.txt; sleep 60'

ls -lan /tmp/raind-login-root

Raind also separates rootless image layer caches by mapping policy, so shifted-root and login-root do not overwrite each other.

Rootless support is still evolving, but it is already an important part of the project direction.

Container Exec and Namespace Handling

raind container exec is also implemented as part of the runtime model.

Exec must enter the target container’s namespaces, adopt the target root filesystem, use the correct working directory, and resolve commands against the container environment rather than the host environment.

This sounds simple, but it is one of the areas where runtime details matter.

For example, a bare command such as:

raind container exec web nginx -v

should resolve nginx inside the container root filesystem, not on the host. It also has to work consistently for rootful and rootless containers.

Raind’s exec path uses namespace entry and container rootfs handling so that exec behavior matches the container’s runtime context.

This is one of the reasons Raind is interesting as a runtime experiment: features that look like simple CLI commands often force the runtime to make precise decisions about namespaces, rootfs, UID/GID mappings, environment variables, and process execution.

Current Status

Raind is experimental.

It is not intended to be a production container runtime today.

The current focus is:

container runtime stability
rootless execution
image handling
Dockerfile build support
Kubernetes-style resource compatibility
local workload networking
policy and netflow visibility
runtime security profiles
developer documentation and project maturity

The project already includes documentation for architecture, containers, rootless modes, networking, resources, manifests, runtime layout, testing, and security profiles.

But many areas are still evolving. Dockerfile parsing, image manifest handling, Kubernetes manifest compatibility, rootless networking, and production-grade hardening are all active areas of development.

Why This Project Matters

Raind is not trying to be “another Docker” or “a replacement for Kubernetes.”

It is a runtime experiment around a specific idea:

What if container execution, local workload orchestration, network policy, and runtime observability were designed as one connected system?

That idea matters because local container workflows often sit between two worlds.

On one side, Docker-like tools are easy to use but mostly container-centric.

On the other side, Kubernetes-like systems are powerful but often too large when the goal is local runtime experimentation.

Raind explores the space between them.

It provides:

Docker-like container ergonomics
Kubernetes-inspired workload resources
Bottle-based local multi-container application units
runtime-managed network policy
netflow-based communication visibility
rootless container execution modes
a low-level OCI-style runtime layer implemented in Go

For developers interested in containers, Linux namespaces, cgroups, networking, policy, or local Kubernetes-style testing, Raind is a project worth exploring.

Getting Started

The repository is available on GitHub:

https://github.com/shizuku198411/Raind

A typical local flow looks like this:

raind image pull nginx:latest
raind network create devnet
raind container run --name web -p 8080:80 nginx:latest
raind container logs web
raind container exec web nginx -v

For Kubernetes-style resources:

raind resource apply -f app.yaml
raind resource pod ls
raind resource service ls

For runtime traffic visibility:

raind logs netflow --line 50

Raind is still young, but the project is moving quickly. Feedback, issues, ideas, and contributions are welcome.

If you are interested in container runtimes, Linux workload isolation, local Kubernetes-style workflows, or runtime-level traffic visibility, I would be happy if you tried Raind or followed the project.