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.
Top comments (0)