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:

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.

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.