Understanding AppArmor behavior

Why AppArmor? (DAC vs MAC)

• Discretionary Access Control (DAC)
• Definition: Linux’s basic security model that grants file permissions (rwxrwxrwx) based on user/group identity.
• Limits: The process inherits all privileges of the user that runs it.
• Vulnerability Example: When a simple log cleanup program (cleanup.sh) is running with root privileges, even if it is contaminated by an attacker and attempts to leak important data to the external Internet or execute a binary such as ping, there is no way to restrict this in the DAC environment because the user is root.
• Mandatory Access Control (MAC)
• Definition: Forcibly constrains the behavior of a process based on a central, predefined security policy (profile).
• Effect: Even if the process runs with root privileges, any actions not specified in the profile (e.g. connecting to the Internet, accessing unauthorized files, etc.) are blocked.
• Alternative solutions: Representative examples include SELinux (RedHat family, complex configuration) and AppArmor (Ubuntu/Debian family, intuitive and relatively easy configuration).

AppArmor’s core mode and profile controls

AppArmor can operate in three modes on your system:

1. AppArmor 3 modes

1. Enforce (enforcement mode): Immediately blocks unauthorized activity by enforcing the defined security profile.
2. Complain (report mode): Does not block policy violations, but only records them in the logs (syslog, audit.log). (Mainly used in the testing phase before application to the operating environment)
3. Unconfined: Runs like a normal process without any restrictions.

# 특정 프로파일을 'Enforce (실제 차단하는 모드)'로 변경
sudo aa-enforce /etc/apparmor.d/$profile

# 특정 프로파일을 'Complain (로그만 남기는 모드)'로 변경
sudo aa-complain /etc/apparmor.d/$profile

# 프로필 제거 = 'Unconfined (프로필이 적용되지 않은 상태)'로 변경
sudo apparmor_parser -R /etc/apparmor.d/$profile

2. Hands-on: Automatic profile creation process

Instead of writing rules manually, you can easily build profiles using AppArmor’s monitoring tools.

1. Utility Installation

   # auditd 설치 (syslog에 App활동 기록, profile 자동생성시 필요)
   sudo apt install -y auditd
   # auditd 서비스 시작 및 부팅 시 자동 실행 설정
   sudo systemctl start auditd
   sudo systemctl enable auditd

   sudo apt-get install -y apparmor-utils

2. Write target script (/root/apparmor/app.sh)

   mkdir -p /root/apparmor/

   cat <<EOF > /root/apparmor/app.sh
   #!/bin/bash
   touch /tmp/file.txt       # 임시 파일 생성
   echo "File Created"
   rm /tmp/file.txt          # 임시 파일 삭제
   echo "File Removed"
   EOF

3. Run automatic profile creation

   sudo aa-genprof /root/apparmor/app.sh

• After execution, actually run the script (./app.sh) in another terminal to create the file access pattern you normally need.
• Return to the aa-genprof screen, enter S to scan the log, and select Inherit or Allow for access requests.
• Once the profile is saved, a file is created in the /etc/apparmor.d/root.apparmor.app.sh path.

Allow Guide (S – I – I – A – A – A – A – S – F)

   [(S)can system log for AppArmor events] / (F)inish
   Reading log entries from /var/log/audit/audit.log.

   Profile:  /root/apparmor/app.sh
   Execute:  /usr/bin/touch
   Severity: 3

   (I)nherit / (C)hild / (N)amed / (X) ix On / (D)eny / Abo(r)t / (F)inish

   Profile:  /root/apparmor/app.sh
   Execute:  /usr/bin/rm
   Severity: unknown

   (I)nherit / (C)hild / (N)amed / (X) ix On / (D)eny / Abo(r)t / (F)inish
   Complain-mode changes:

   Profile:  /root/apparmor/app.sh
   Path:     /dev/tty
   New Mode: owner rw
   Severity: 9

    [1 - include <abstractions/consoles>]
     2 - owner /dev/tty rw,
   (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish
   Adding include <abstractions/consoles> to profile.

   Profile:  /root/apparmor/app.sh
   Path:     /etc/ld.so.cache
   New Mode: owner r
   Severity: 1

    [1 - owner /etc/ld.so.cache r,]
   (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish
   Adding owner /etc/ld.so.cache r, to profile.

   Profile:  /root/apparmor/app.sh
   Path:     /etc/locale.alias
   New Mode: owner r
   Severity: unknown

    [1 - owner /etc/locale.alias r,]
   (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish
   Adding owner /etc/locale.alias r, to profile.

   Profile:  /root/apparmor/app.sh
   Path:     /tmp/file.txt
   New Mode: owner w
   Severity: unknown

    [1 - include <abstractions/user-tmp>]
     2 - owner /tmp/file.txt w,
   (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish
   Adding include <abstractions/user-tmp> to profile.

   = Changed Local Profiles =

   The following local profiles were changed. Would you like to save them?

    [1 - /root/apparmor/app.sh]
   (S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t
   Writing updated profile for /root/apparmor/app.sh.

   Profiling: /root/apparmor/app.sh

   Please start the application to be profiled in
   another window and exercise its functionality now.

   Once completed, select the "Scan" option below in
   order to scan the system logs for AppArmor events.

   For each AppArmor event, you will be given the
   opportunity to choose whether the access should be
   allowed or denied.

   [(S)can system log for AppArmor events] / (F)inish
   Setting /root/apparmor/app.sh to enforce mode.

   Reloaded AppArmor profiles in enforce mode.

   Please consider contributing your new profile!
   See the following wiki page for more information:
   https://gitlab.com/apparmor/apparmor/wikis/Profiles

   Finished generating profile for /root/apparmor/app.sh.

4. Testing unauthorized behavior
– If you secretly add an unauthorized binary call such as ping localhost to the script and then run it, operation will be severely restricted with a Permission Denied error even if the executor is root.
5. How to deactivate (remove) a profile

   sudo apparmor_parser -R /etc/apparmor.d/root.apparmor.app.sh

AppArmor integration in Kubernetes (K8s) environments

Kubernetes can load and apply a node-level AppArmor profile to improve the security of containers inside a Pod.

1. Prerequisites

• AppArmor must be enabled in the Node kernel.
• The AppArmor profile to be applied to the container must be preloaded on the file system of all nodes on which the pod will run.

2. Example AppArmor profile for K8s (deny all writes)

How to parse after registering in /etc/apparmor.d/k8s-deny-write file:

cat <<EOF > /etc/apparmor.d/k8s-deny-write
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
	file,
	# 모든 쓰기 동작 차단 (여기서의 #은 실제 주석입니다)
	deny /** w,
}
EOF

# 로드
sudo apparmor_parser -r -W /etc/apparmor.d/k8s-deny-write

# 프로필 로드 상태 확인
aa-status | grep k8s-apparmor-example-deny-write

3. Pod manifest settings (apply securityContext)

Declare the profile via securityContext according to the V1.30+ specification or the general Pod specification.

cat <<EOF | kubectl apply -f - 
apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write # 노드에 로드된 프로필 이름
  containers:
  - name: busybox
    image: busybox:1.36
    command: ["sh", "-c", "echo 'Hello AppArmor' && sleep 3600"]
EOF

k get pods hello-apparmor

[!IMPORTANT]
Troubleshooting

• If the profile with the name specified by localhostProfile is not actually loaded on the node, the Pod will not run and will remain in the ContainerCreating state.
• When you run kubectl describe pod , you will see the error message Failed to create container... AppArmor profile not found. Therefore, you must deploy security profiles to all nodes in batches using DaemonSet or a provisioning tool.
  

4. Profile application test

kubectl exec -it hello-apparmor -- sh
# in container

touch /tmp/test.txt
```prompt
touch: /tmp/test.txt: Permission denied
`

echo "test" > /var/log/test.log
```prompt
sh: can't create /var/log/test.log: nonexistent directory
`

5. Clean up test resources

# 프로필 제거
sudo apparmor_parser -R /etc/apparmor.d/k8s-deny-write

# 프로필 파일 제거
rm /etc/apparmor.d/k8s-deny-write

# 제거
k delete pods hello-apparmor --force

Key summary

• AppArmor is a powerful Linux security module that complements DAC’s ‘excessive root privilege inheritance’ problem.
• Production application strategy: If you apply Enforce mode right from the beginning, a disaster may occur where actual service functions are interrupted. Therefore, it is standard to start with Complain mode, analyze logs, and then change to Enforce when it is stabilized.
• K8s Security Fundamentals: The pattern of combining AppArmor settings with Pod-level securityContext is essential to solidify the security perimeter in CKS testing and enterprise environments.

References

• AppArmor | Killer Shell CKS | Killercoda
• Restrict a Container’s Access to Resources with AppArmor
• Configure a Security Context for a Pod or Container
• Certified Kubernetes Security Specialist 2026

Summary of Kubernetes usage

1. Overview & Concepts

AppArmor (Application Armor) is a Mandatory Access Control (MAC) system implemented in the Linux kernel. Complements traditional Unix-style discretionary access control (DAC, based on file owner and permissions) to restrict processes from accessing system resources (files, networks, functions, etc.).

Key concepts

• Path-based restrictions: While SELinux operates based on the ‘Label’ of the file system, AppArmor applies security rules based on the absolute path of the file, making it intuitive and easy to manage.
• Profile: A text file that defines a list of tasks that a particular application or executable can perform. It is mainly located in the /etc/apparmor.d/ directory.
• Execution Modes:
• Enforce (Enforce mode): Do not allow, block, and log actions not defined in the profile.
• Complain: Does not block if rules are violated, just logs what actions are not allowed. (Mainly used during development and profile learning stages)

Flow in Kubernetes environment

– Applies to: Executable files (binaries) or processes in a specific path
– Operates in: not inside the container, in the Linux kernel (LSM: Linux Security Module) on the host device
– Restricting actions: * Read, write, and execute permissions for specific files/directories (r, w, x)
– Network socket creation and communication
– Use special functions (Capabilities) such as RAW capture

If you look at the flow of applying AppArmor in Kubernetes, it becomes clear why the process is subject to control.

1. Load profile to host node: First, register the profile with AppArmor on the Kubernetes worker node (host OS). (Example: k8s-apparmor-deny-write)
2. Declared in Pod YAML: Assigns that profile to a specific container through Pod settings.
3. Applied when running the container: When the container runs, the container’s main process (PID 1) and its child processes are subject to profile restrictions by the host kernel.

Cluster Requirements

• Kubernetes version: 1.4\~
• AppArmor kernel module must be available. — In order to force the AppArmor profile to the Linux kernel, the AppArmor kernel module must be installed and available. For example, distributions such as Ubuntu and SUSE support the module by default, while many others support it optionally.

  # 모듈이 사용 가능한지 확인하려면 다음이 `Y`인지 확인
  cat /sys/module/apparmor/parameters/enabled

• Container runtime supports AppArmor. — Container runtimes such as Docker (original, Docker), CRI-O or containerd that currently support all common Kubernetes use AppArmor. Must support. You should refer to this runtime documentation to ensure that your cluster meets the requirements to use AppArmor.
• The profile is loaded. — AppArmor applies to pods by specifying the AppArmor profile that should run with each container. If the profile specified in the kernel is not loaded, Kubelet (>= v1.4) rejects the pod.

  # 해당 노드에 어떤 프로파일이 적재되었는지는 다음을 통해 확인
  ssh nodename "sudo cat /sys/kernel/security/apparmor/profiles | sort"

About scope of application and profile designation

• AppArmor profiles can be specified at the pod level or container level. Container AppArmor profiles have higher priority than pod profiles.
• pod.spec.containers.securityContext.appArmorProfile
• pod.spec.securityContext.appArmorProfile
• appArmorProfile

  securityContext:
    appArmorProfile:
      type: <profile_type>

• is one of the following:
  • RuntimeDefault: Use the runtime’s default profile
  • Localhost: Use profile loaded on host (see below)
  • Unconfined: Run without AppArmor

• Description
  “`yaml
  k explain pod.spec.securityContext.appArmorProfile
  —
  KIND: Pod
  VERSION: v1

  FIELD: appArmorProfile

  DESCRIPTION:
  appArmorProfile is the AppArmor options to use by the containers in this
  pod. Note that this field cannot be set when spec.os.name is windows.
  AppArmorProfile defines a pod or container’s AppArmor settings.

  FIELDS:
  localhostProfile
  localhostProfile indicates a profile loaded on the node that should be used.
  The profile must be preconfigured on the node to work. Must match the loaded
  name of the profile. Must be set if and only if type is “Localhost”.

  type -required-
  enum: Localhost, RuntimeDefault, Unconfined
  type indicates which kind of AppArmor profile will be applied. Valid options
  are:
  Localhost – a profile pre-loaded on the node.
  RuntimeDefault – the container runtime’s default profile.
  Unconfined – no AppArmor enforcement.

  Possible enum values:
   - `"Localhost"` indicates that a profile pre-loaded on the node should be
  used.
   - `"RuntimeDefault"` indicates that the container runtime's default
  AppArmor profile should be used.
   - `"Unconfined"` indicates that no AppArmor profile should be enforced.
  

  “`

2. System Architecture

AppArmor operates in close connection with management tools in user space and the LSM (Linux Security Module) framework within the Linux kernel.

Architecture & System Flow Diagram

SVG

100%

Pan & Zoom

3. Sequence Diagram

This is a runtime flow in which the AppArmor kernel module checks and processes when a container or general process attempts to access a file.

Architecture & System Flow Diagram

SVG

100%

Pan & Zoom

4. System binary

AppArmor provides a variety of userspace tools and binaries for interacting with the kernel and managing profiles.

As it is a kernel security tool, it must be run separately on each node.

Core Management Binary

Binaries other than apparmor_parser and aa-status are confirmed to be outside the scope of the CKS exam.

• apparmor_parser: The core binary of AppArmor. The human-readable text profile is parsed, compiled into a binary format that the kernel can understand, and then loaded into the kernel.

  # -r 플래그와 함께 사용하면 create/update 모두 대응가능
  sudo apparmor_parser -r /etc/apparmor.d/$profile
  # 프로파일 적용
  sudo apparmor_parser $profile

• aa-status (or apparmor_status): Checks the AppArmor status of the current system. Shows the number of loaded profiles, the mode (Enforce/Complain) for each profile, and a list of processes being quarantined by the profile being applied.

  # 실행된 노드의 로드된 프로필 목록 조회
  sudo aa-status

  # 프로파일 활성화여부 조회
  sudo aa-status | grep $profile

System diagnosis and verification

• aa-enabled This is a binary that simply answers whether AppArmor is enabled in the current system kernel with Yes or No. Mainly used in script branch statements.

  aa-enabled

Direct process isolation execution (outside the scope of the question)

• aa-exec Used when executing a program while forcing a specific AppArmor profile.

  aa-exec -p <프로필이름> <실행할명령어>

System management and initialization (mainly used during booting/shutdown) (outside the scope of the exam)

• aa-teardown Removes and unloads all AppArmor profiles loaded in the current kernel at once. In other words, it is used to temporarily completely disable all of AppArmor’s defenses. (Must be used with caution.)

  sudo aa-teardown

• aa-remove-unknown Among the profiles loaded in the kernel, ‘Unknown’ profiles that do not exist as actual files in the current /etc/apparmor.d/ directory are identified and automatically removed cleanly from the kernel.

  sudo aa-remove-unknown

• aa-load This is an internal script used to reload policy files in /etc/apparmor.d/ into the kernel all at once. (Similar to running apparmor_parser -r over the entire directory we learned earlier.)

  sudo aa-load

For developer and internal verification (outside the scope of the exam)

• aa-features-abi Outputs the AppArmor feature interface version supported by the current Linux kernel. It is rarely used directly in general operations or testing.

  aa-features-abi

5. Utility binary

Profile creation and change management binary (outside the scope of the exam)

• aa-genprof: Used when creating a profile for a new application from scratch. It automatically builds a rudimentary profile by running the program and monitoring its behavior.

  sudo aa-genprof /usr/bin/custom-app
  # 명령어를 실행하면 대기 상태가 됩니다. 
  # 다른 터미널에서 custom-app을 실행해 정삭적인 작업을 수행한 뒤, 
  # 다시 돌아와 'S'를 눌러 로그를 스캔하고 프로필을 저장합니다.

• aa-logprof: Scans system logs (/var/log/audit/audit.log or syslog) generated by Complain mode, etc., and interactively asks and updates the behavior of newly discovered applications to add to existing profiles.

  sudo aa-logprof
  # 시스템 로그를 읽어와 허용 여부를 묻는 인터랙티브 창(Y/N/A/D 등)이 뜹니다.

• aa-autodep: Analyzes the shared libraries and dependencies used by the target binary and automatically creates a very basic skeleton profile.

  sudo aa-autodep /usr/bin/custom-app

Mode switching and utility binary (outside the scope of the exam)

• aa-enforce: Immediately puts the target profile or binary into Enforce mode.

  # 프로필 파일 경로를 지정하거나, 등록된 바이너리 경로를 지정할 수 있습니다.
  sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
  sudo aa-enforce /usr/sbin/nginx

• aa-complain: Immediately switches the target profile or binary to Complain mode.

  sudo aa-complain /usr/sbin/nginx

• aa-disable: Unloads a specific profile from the kernel and permanently disables it.

  sudo aa-disable /usr/sbin/nginx

• aa-audit: Force audit log recording for a specific profile.

  # 1. 특정 바이너리에 적용된 프로필에 audit 모드 강제 적용
  sudo aa-audit /usr/sbin/nginx

  # 2. 프로필 파일 경로를 직접 지정하여 적용
  sudo aa-audit /etc/apparmor.d/usr.sbin.nginx

  # 3. (원상 복구) 감사 모드를 해제하고 일반 모드로 복귀
  sudo aa-audit --remove /usr/sbin/nginx

• aa-unconfined: Identifies a list of binaries that are not protected (restricted) by the AppArmor profile among processes currently running and opening a network socket.

  # 1. 현재 네트워크 소켓을 열고 실행 중인 프로세스 중 보호받지 않는 목록 출력
  sudo aa-unconfined

  # 출력 예시:
  # 1234 /usr/sbin/sshd not confined
  # 5678 /usr/bin/python3 (정상 보호 중인 건 아예 안 뜨거나 다르게 표시됨)

  # 2. 네트워크 사용 여부와 상관없이, 시스템에서 실행 중인 모든 프로세스를 샅샅이 검사
  sudo aa-unconfined --paranoid

• aa-notify: A utility that sends a notification to the desktop or a designated channel when an AppArmor blocking log (DENIED) occurs.

  aa-notify -p -s 5 &
  # -p: 데스크톱 알림(Notification) 창으로 표시
  # -s 5: 최근 5초 이내의 밀린 로그는 요약해서 보여줌

Tips for taking and using the Certified Kubernetes Security Specialist (CKS)

AppArmor is one of the frequently asked, high-scoring security topics on the CKS exam. Here are some practical tips for solving problems quickly and without panicking at the test site.

CKS Test Center Practice Code of Conduct

1. Check all worker nodes: The AppArmor profile must be loaded into the kernel of the worker node where the container will run directly, not the Kubernetes master. Connect ssh to the node specified in the problem and perform the operation.
2. Profile validity check: When connecting to a node, type aa-status to check whether the profile name requested in the problem is already loaded.
3. Memorize the new profile load command: If the profile file provided in the problem is specified, it must be loaded into the kernel using a parser. Bash

   # 프로필 추가/새로고침 (-r 옵션 사용)
   sudo apparmor_parser -r /etc/apparmor.d/제공된_프로필_파일명

4. Debugging when container startup fails: If a Pod that has completed AppArmor configuration goes into CreateContainerConfigError or CrashLoopBackOff status, immediately suspect the following two things.
   – Does the profile name written in localhostProfile match the name that appears in aa-status of the worker node, including lowercase and lowercase letters?
   – Are there any grammatical errors in the internal structure of the profile file? (Check the node’s /var/log/syslog or journalctl -u kubelet)

Differences from seccomp (CKS frequent concept)

seccomp, which is required along with AppArmor in the CKS exam, also limits the process, but there is a difference in the ‘layer’ that controls it.

Problem solving tips

1. Find and record whether a specific profile is activated on a specific node

   ### 원격으로 기록하기
   cat <<EOF > /root/profiles.txt
   $(ssh node01 bash -c 'aa-status' | grep -E 'docker-default|snap.lxd.lxc|ftpd|tcpdump' | awk '{print $1}')
   EOF

   ### or 직접 조회 후 기록
   ssh node01
   aa-status | grep -E 'docker-default|snap.lxd.lxc|ftpd|tcpdump'

2. Rename the prepared profile and activate it on all nodes

   ### Change in File
   vi $profile
   ```profile
   profile <profile_name> flags=(attach_disconnected,mediate_deleted) {
   `

   ### 모든 노드에 파일 전송
   scp $profile node01:

   ### 모든 노드에 적용
   apparmor_parser $profile
   ssh node01
   apparmor_parser $profile

3. An error occurred due to an incorrect profile name. Modify deployment to succeed

   # 프로파일명 확인
   ssh node01 bash -c 'aa-status'

   # 수정 적용
   kubectl edit deployment -n $ns $deploy_name
   ```yaml
   # pod.spec or pod.spec.containers
   securityContext:
     appArmorProfile:
       type: Localhost
       localhostProfile: <profile_name>
   `

3. Specific container (Multi-Container) unit targeting type 1. Check the specified container name and move pod.spec.securityContext to pod.spec.containers.securityContext