Linux Containers 심화

Linux 컨테이너 기술 스택을 커널 관점에서 종합적으로 다룹니다. OCI 런타임(runc, containerd, Podman), seccomp/capabilities 보안, OverlayFS 스토리지, CNI 네트워킹, rootless 컨테이너, Kata Containers까지 컨테이너의 전체 아키텍처를 설명합니다.

컨테이너 개요

컨테이너는 운영체제 수준 가상화(OS-level virtualization) 기술로, 하나의 커널 위에서 프로세스를 격리된 환경에서 실행합니다. VM이 하이퍼바이저 위에 게스트 커널을 통째로 올리는 것과 달리, 컨테이너는 호스트 커널을 공유하면서 네임스페이스와 cgroups로 격리와 리소스 제한을 구현합니다.

핵심 커널 프리미티브

컨테이너 기술은 다음 4가지 커널 프리미티브의 조합으로 구현됩니다:

VM vs Container 아키텍처

컨테이너 기술의 역사

커널 프리미티브 조합

컨테이너 런타임은 단일 프리미티브가 아닌, 여러 커널 기능을 특정 순서로 조합하여 격리 환경을 구성합니다. 아래 다이어그램은 컨테이너 생성 시 커널 프리미티브가 적용되는 흐름을 보여줍니다.

seccomp-bpf: 시스템 콜 필터링

seccomp(Secure Computing Mode)은 프로세스가 호출할 수 있는 시스템 콜을 제한하는 커널 기능입니다. 컨테이너 런타임은 seccomp-bpf 필터를 사용하여 위험한 시스템 콜을 차단합니다.

/* 커널의 seccomp 필터 데이터 구조 (include/uapi/linux/seccomp.h) */
struct seccomp_data {
    int   nr;                    /* 시스템 콜 번호 */
    __u32 arch;                  /* AUDIT_ARCH_* 값 */
    __u64 instruction_pointer;   /* 호출 위치 */
    __u64 args[6];              /* 시스템 콜 인자 */
};

/* seccomp 필터 설치 */
struct sock_fprog prog = {
    .len    = ARRAY_SIZE(filter),
    .filter = filter,           /* BPF 필터 배열 */
};
prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog);

/* 또는 seccomp() 시스템 콜 사용 (Linux 3.17+) */
seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog);

Linux Capabilities

전통적 Unix는 root(UID 0)와 non-root만 구분했습니다. Linux capabilities는 root 권한을 약 40개 이상의 세분화된 권한으로 분리하여, 컨테이너에 필요한 최소 권한만 부여할 수 있게 합니다.

/* 컨테이너 런타임의 기본 capability 목록 (Docker/runc 기준) */
/* 유지되는 capabilities */
CAP_CHOWN              /* 파일 소유자 변경 */
CAP_DAC_OVERRIDE       /* 파일 접근 권한 우회 */
CAP_FSETID             /* setuid/setgid 비트 보존 */
CAP_FOWNER             /* 파일 소유자 검사 우회 */
CAP_MKNOD              /* 특수 파일 생성 */
CAP_NET_RAW            /* RAW/PACKET 소켓 */
CAP_SETGID             /* GID 조작 */
CAP_SETUID             /* UID 조작 */
CAP_SETFCAP            /* 파일 capability 설정 */
CAP_SETPCAP            /* 프로세스 capability 전달 */
CAP_NET_BIND_SERVICE   /* 1024 미만 포트 바인딩 */
CAP_SYS_CHROOT         /* chroot() 호출 */
CAP_KILL               /* 프로세스에 시그널 전송 */
CAP_AUDIT_WRITE        /* 감사 로그 작성 */

/* 주요 DROP 대상 capabilities */
CAP_SYS_ADMIN          /* mount, namespace 생성 등 — 가장 위험 */
CAP_SYS_PTRACE         /* ptrace, /proc 접근 */
CAP_SYS_MODULE         /* 커널 모듈 로드/언로드 */
CAP_SYS_RAWIO          /* iopl, ioperm */
CAP_SYS_BOOT           /* reboot() */
CAP_NET_ADMIN          /* 네트워크 구성 변경 */

# capability 확인 도구
$ capsh --print               # 현재 프로세스의 capabilities 출력
$ getpcaps <PID>              # 특정 프로세스의 capabilities 확인
$ cat /proc/<PID>/status | grep Cap   # 커널이 보고하는 capability 비트마스크

# 출력 예시 (Docker 컨테이너 내부)
CapInh: 0000000000000000
CapPrm: 00000000a80425fb      # 허용된 capability 비트마스크
CapEff: 00000000a80425fb      # 유효 capability 비트마스크
CapBnd: 00000000a80425fb      # bounding set
CapAmb: 0000000000000000      # ambient capabilities

OCI (Open Container Initiative)

OCI는 컨테이너 포맷과 런타임의 개방 표준을 정의하는 Linux Foundation 프로젝트입니다. Docker가 2015년에 기증한 libcontainer를 기반으로, 모든 컨테이너 런타임이 따르는 표준 인터페이스를 제공합니다.

OCI Runtime Specification

런타임 스펙은 컨테이너의 설정, 실행 환경, 라이프사이클을 정의합니다. config.json이 핵심 설정 파일입니다.

// OCI config.json 핵심 구조 (간략화)
{
  "ociVersion": "1.0.2",
  "process": {
    "terminal": true,
    "user": { "uid": 0, "gid": 0 },
    "args": ["/bin/sh"],
    "env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],
    "cwd": "/",
    "capabilities": {
      "bounding": ["CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_BIND_SERVICE"],
      "effective": ["CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_BIND_SERVICE"]
    },
    "rlimits": [{ "type": "RLIMIT_NOFILE", "hard": 1024, "soft": 1024 }]
  },
  "root": { "path": "rootfs", "readonly": true },
  "mounts": [
    { "destination": "/proc", "type": "proc", "source": "proc" },
    { "destination": "/dev", "type": "tmpfs", "source": "tmpfs" }
  ],
  "linux": {
    "namespaces": [
      { "type": "pid" }, { "type": "network" },
      { "type": "ipc" }, { "type": "uts" },
      { "type": "mount" }, { "type": "cgroup" }
    ],
    "seccomp": { "defaultAction": "SCMP_ACT_ERRNO", "architectures": ["SCMP_ARCH_X86_64"] },
    "resources": {
      "memory": { "limit": 536870912 },
      "cpu": { "shares": 1024, "quota": 100000, "period": 100000 }
    }
  }
}

OCI 컨테이너 라이프사이클

OCI Image Specification

OCI 이미지는 content-addressable 스토리지 모델을 사용합니다. 각 레이어는 SHA256 다이제스트로 식별됩니다.

• Image Manifest — 이미지의 레이어 목록과 config를 가리키는 디스크립터
• Image Config — 실행 파라미터, 환경변수, 레이어 히스토리
• Filesystem Layers — tar+gzip으로 압축된 파일시스템 변경분 (diff)
• Image Index — 멀티 아키텍처(amd64, arm64) 이미지의 매니페스트 목록

컨테이너 런타임

컨테이너 런타임은 3계층으로 분류됩니다:

runc (OCI 참조 구현)

runc은 Docker가 기증한 libcontainer를 기반으로 한 Go 언어 구현의 OCI 참조 런타임입니다. 컨테이너 생성의 핵심 코드 흐름:

/* runc의 컨테이너 생성 흐름 (Go → 커널 호출) */

// 1. config.json 파싱 → Container 구조체 생성
container := libcontainer.Create(id, config)

// 2. 부모 프로세스에서 clone() + CLONE_NEW* 플래그로 자식 생성
//    (실제로는 /proc/self/exe를 재실행하는 "init" 방식)
cmd := &exec.Cmd{
    Path: "/proc/self/exe",   // runc 바이너리 자체를 다시 실행
    Args: []string{"runc", "init"},
}
cmd.SysProcAttr = &syscall.SysProcAttr{
    Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID |
                syscall.CLONE_NEWNS  | syscall.CLONE_NEWNET |
                syscall.CLONE_NEWIPC | syscall.CLONE_NEWUSER,
}

// 3. 자식 프로세스(runc init)에서:
pivot_root(rootfs, put_old)     // rootfs 전환
mount("proc", "/proc", "proc", 0, "")  // /proc 마운트
prctl(PR_SET_NO_NEW_PRIVS, 1)   // 권한 상승 차단
seccomp(SET_MODE_FILTER, &prog)  // seccomp 필터 적용
execve(entrypoint, args, envp)   // 컨테이너 프로세스 실행

# runc 직접 사용 예시
$ mkdir -p bundle/rootfs
$ docker export $(docker create alpine) | tar -C bundle/rootfs -xf -
$ cd bundle
$ runc spec                     # 기본 config.json 생성
$ runc create mycontainer       # 컨테이너 생성 (created 상태)
$ runc start mycontainer        # 프로세스 시작 (running 상태)
$ runc list                     # 컨테이너 목록 확인
$ runc state mycontainer        # 상태 JSON 출력
$ runc delete mycontainer       # 정리

crun (C 구현)

crun은 runc의 C 언어 대안 구현으로, Red Hat이 개발합니다.

containerd

containerd는 CNCF 졸업 프로젝트로, Docker와 Kubernetes의 핵심 컨테이너 런타임입니다.

• gRPC API — 클라이언트(Docker/kubelet)가 API로 컨테이너 라이프사이클 관리
• Snapshotter — 이미지 레이어를 파일시스템 스냅샷으로 관리 (overlayfs, native, devmapper 등)
• Content Store — content-addressable 스토리지로 이미지 블롭 저장
• Shim 프로세스 — containerd-shim-runc-v2가 각 컨테이너와 1:1로 존재하여, containerd 재시작과 컨테이너를 분리
• CRI 플러그인 — Kubernetes CRI(Container Runtime Interface) 네이티브 구현

# containerd 디버깅 도구
$ ctr images pull docker.io/library/alpine:latest    # 이미지 pull
$ ctr run --rm docker.io/library/alpine:latest test /bin/sh  # 실행
$ ctr containers list                                # 컨테이너 목록
$ ctr tasks list                                     # 실행 중인 태스크

# nerdctl (containerd용 Docker-호환 CLI)
$ nerdctl run --rm -it alpine sh                     # Docker와 동일한 UX

Podman

Podman은 Red Hat이 개발한 데몬리스(daemonless) 컨테이너 엔진입니다. Docker와 달리 중앙 데몬이 없어 각 컨테이너가 독립적인 프로세스 트리를 가집니다.

• Fork/exec 모델 — podman 명령이 직접 conmon(container monitor)을 생성하고, conmon이 runc/crun을 호출
• Rootless 네이티브 — User namespace 기반으로 일반 사용자가 컨테이너 실행 가능
• systemd 통합 — podman generate systemd로 컨테이너를 systemd 서비스로 관리
• Pod 지원 — Kubernetes Pod 개념을 로컬에서 구현 (infra 컨테이너로 네임스페이스 공유)

# Podman rootless 사용 예
$ podman run --rm -it alpine sh                      # root 권한 불필요
$ podman pod create --name mypod -p 8080:80          # Pod 생성
$ podman run --pod mypod nginx                       # Pod에 컨테이너 추가

# systemd 서비스로 관리
$ podman generate systemd --name mycontainer --new > mycontainer.service
$ systemctl --user enable --now mycontainer.service

컨테이너 스토리지 (OverlayFS)

OverlayFS는 컨테이너의 기본 스토리지 드라이버로, 읽기 전용 이미지 레이어 위에 쓰기 가능한 컨테이너 레이어를 오버레이합니다. 커널 3.18에서 mainline에 통합되었습니다.

OverlayFS 레이어 구조

Copy-up 메커니즘

lower 레이어의 파일을 수정할 때, OverlayFS는 해당 파일을 upper 레이어로 복사한 뒤 수정합니다. 이를 copy-up이라 합니다.

/* OverlayFS copy-up 핵심 (fs/overlayfs/copy_up.c) */
static int ovl_copy_up_one(struct dentry *parent,
                           struct dentry *dentry,
                           struct path *lowerpath,
                           struct kstat *stat)
{
    /* 1. upper에 임시 파일 생성 (workdir에서) */
    temp = ovl_create_temp(workdir, ...);

    /* 2. lower에서 데이터 복사 */
    ovl_copy_up_data(lowerpath, temp, stat->size);

    /* 3. xattr, 권한, 타임스탬프 복사 */
    ovl_copy_xattr(lowerpath->dentry, temp);
    ovl_set_attr(temp, stat);

    /* 4. atomic rename으로 upper에 배치 */
    vfs_rename(workdir, temp, upperdir, dentry);
    return 0;
}

대안 스토리지 드라이버

Whiteout / Opaque 디렉토리

OverlayFS에서 lower 레이어는 읽기 전용이므로, 파일을 "삭제"할 때 실제 lower의 파일을 제거하는 것이 아니라 upper 레이어에 whiteout 파일을 생성하여 해당 파일을 가립니다. Whiteout은 character device(major=0, minor=0)로 표현됩니다.

/* fs/overlayfs/overlayfs.h — whiteout 관련 상수 */
#define OVL_WHITEOUT_DEV    MKDEV(0, 0)

/* whiteout 생성 (fs/overlayfs/dir.c) */
static int ovl_whiteout(struct ovl_fs *ofs,
                        struct dentry *upperdir,
                        struct dentry *dentry)
{
    struct dentry *whiteout;
    /* workdir에서 whiteout 장치 파일(0,0) 생성 */
    whiteout = ovl_lookup_temp(ofs, ofs->workdir);
    ovl_do_whiteout(ofs, whiteout);  /* mknod(S_IFCHR, 0/0) */

    /* atomic rename으로 upper에 배치 */
    return ovl_do_rename(ofs, ofs->workdir, whiteout,
                         upperdir, dentry, 0);
}

디렉토리 전체를 삭제한 뒤 같은 이름으로 재생성하는 경우, OverlayFS는 opaque 디렉토리를 사용합니다. upper에 새 디렉토리를 만들고 trusted.overlay.opaque="y" xattr을 설정하면, 이 디렉토리 하위에서는 lower의 동명 디렉토리를 참조하지 않습니다.

# Whiteout 확인 예시
$ ls -la upper/
c--------- 1 root root 0, 0 ... config.txt   # whiteout: char device 0/0

# Opaque 디렉토리 확인
$ getfattr -n trusted.overlay.opaque upper/data/
trusted.overlay.opaque="y"

# merged에서 확인
$ ls merged/
data/  README   # config.txt는 whiteout에 의해 숨겨짐

Redirect Dir (디렉토리 Rename)

OverlayFS에서 디렉토리를 rename하면 upper에만 새 디렉토리가 생기고, lower의 원본 디렉토리는 여전히 존재합니다. 이를 올바르게 처리하기 위해 커널 4.10+에서 redirect dir 기능이 도입되었습니다. 새 디렉토리의 trusted.overlay.redirect xattr에 원본 경로를 저장하여, lower의 원본 디렉토리 내용을 새 위치에서 투명하게 참조합니다.

/* 디렉토리 rename 시 redirect lookup 의사코드 */
static int ovl_rename(struct inode *olddir, struct dentry *old,
                     struct inode *newdir, struct dentry *new)
{
    /* 1. old가 디렉토리이고 lower에 존재하면 redirect 설정 필요 */
    if (ovl_type_merge_or_lower(old)) {
        /* 2. new 디렉토리에 redirect xattr 설정 */
        ovl_set_redirect(old, ovl_dentry_get_redirect(old));
        /* trusted.overlay.redirect="/original/path" */
    }
    /* 3. 이후 lookup 시 redirect xattr을 읽어 lower 검색에 사용 */
    return ovl_do_rename(...);
}

Metacopy 최적화

커널 4.19+에서 도입된 metacopy 기능은 copy-up 시 파일 데이터 대신 메타데이터(소유권, 권한, xattr)만 upper에 복사합니다. 실제 데이터 읽기/쓰기가 발생할 때까지 데이터 복사를 지연(lazy copy-up)하여 성능을 대폭 개선합니다.

/* metacopy 분기 로직 (fs/overlayfs/copy_up.c) */
static int ovl_copy_up_meta_inode_data(struct ovl_copy_up_ctx *c)
{
    /* metacopy 상태 확인: 메타데이터만 복사된 파일인지 */
    if (ovl_is_metacopy_dentry(c->dentry)) {
        /* 데이터 접근 발생 → 이제 실제 데이터 복사 */
        err = ovl_copy_up_data(&c->lowerpath, &datapath,
                                c->stat.size);
        if (err)
            return err;
        /* metacopy xattr 제거 (이제 전체 복사 완료) */
        ovl_do_removexattr(ofs, upperpath.dentry,
                           OVL_XATTR_METACOPY);
    }
    return 0;
}

# metacopy 활성화 마운트
$ mount -t overlay overlay \
  -o lowerdir=/lower,upperdir=/upper,workdir=/work,metacopy=on \
  /merged

# chmod 후 metacopy xattr 확인
$ chmod 644 /merged/large_file.dat
$ getfattr -n trusted.overlay.metacopy /upper/large_file.dat
trusted.overlay.metacopy   # 값 존재 = 데이터 미복사

# 파일 내용을 수정하면 데이터 copy-up 발생
$ echo "data" >> /merged/large_file.dat
$ getfattr -n trusted.overlay.metacopy /upper/large_file.dat
# xattr 없음 = 전체 데이터 복사 완료

OverlayFS 커널 내부 구조

OverlayFS의 커널 구현은 fs/overlayfs/ 디렉토리에 위치하며, VFS 레이어와 통합되어 upper/lower 레이어를 투명하게 합성합니다.

/* 핵심 자료구조: OverlayFS 파일시스템 인스턴스 (fs/overlayfs/ovl_entry.h) */
struct ovl_fs {
    unsigned int        numlayer;       /* 전체 레이어 수 */
    struct ovl_layer    *layers;        /* 레이어 배열 (upper + lowers) */
    struct ovl_sb       *fs;            /* 레이어별 superblock 정보 */
    struct dentry       *workdir;       /* workdir dentry */
    long                namelen;        /* 파일명 최대 길이 */
    struct ovl_config   config;         /* 마운트 옵션 구조체 */
    const struct cred  *creator_cred;  /* 마운트 수행자 credential */
};

/* OverlayFS inode 확장 */
struct ovl_inode {
    struct ovl_dir_cache *cache;     /* readdir 캐시 */
    const char          *redirect;   /* redirect 경로 */
    struct inode        *upper;      /* upper inode (있으면) */
    struct ovl_path     lowerpath;   /* lower 경로 */
    struct inode        vfs_inode;   /* VFS inode (임베딩) */
    unsigned long       flags;       /* OVL_UPPERDATA, OVL_METACOPY 등 */
};

/* dentry 개인 데이터: upper/lower 매핑 */
struct ovl_entry {
    unsigned            numlower;    /* lower 경로 수 */
    struct ovl_path     lowerstack[];  /* flexible array: lower dentry 배열 */
};

/* 파일 수정 시 VFS → OverlayFS 함수 호출 흐름 */

vfs_open(merged_dentry)
  └─ ovl_open()
       ├─ ovl_maybe_copy_up(dentry, O_WRONLY)
       │    └─ ovl_copy_up_flags()
       │         └─ ovl_copy_up_one()           /* copy-up 수행 */
       │              ├─ ovl_create_temp()       /* workdir에 임시파일 */
       │              ├─ ovl_copy_up_data()      /* 데이터 복사 (또는 metacopy 스킵) */
       │              ├─ ovl_copy_xattr()        /* xattr 복사 */
       │              └─ vfs_rename()            /* atomic으로 upper에 배치 */
       └─ ovl_open_realfile()                    /* upper의 실제 파일 open */
            └─ open_with_fake_path(upper_file)   /* 실제 파일시스템에 위임 */

xattr 기반 메타데이터

OverlayFS는 확장 속성(xattr)을 통해 레이어 간 관계와 파일 상태를 관리합니다. 모든 xattr은 trusted.overlay.* 네임스페이스에 저장됩니다.

trusted.* 네임스페이스는 root만 읽기/쓰기 가능하여 일반 사용자의 조작을 방지합니다. 커널 5.11+ rootless 환경에서는 userxattr 마운트 옵션을 사용하여 user.overlay.* 네임스페이스로 매핑합니다.

# xattr 전체 조회
$ getfattr -d -m "trusted.overlay.*" upper/mydir/
# file: upper/mydir/
trusted.overlay.impure="y"
trusted.overlay.opaque="y"

# origin file handle 확인 (바이너리)
$ getfattr -n trusted.overlay.origin -e hex upper/copied_file
trusted.overlay.origin=0x00fb010020...

# userxattr 환경 (rootless, 커널 5.11+)
$ getfattr -d -m "user.overlay.*" upper/mydir/
user.overlay.opaque="y"

마운트 옵션 상세

# 기본 마운트
$ mount -t overlay overlay \
  -o lowerdir=/lower,upperdir=/upper,workdir=/work \
  /merged

# 다중 lower 레이어 (왼쪽이 최상위)
$ mount -t overlay overlay \
  -o lowerdir=/app:/runtime:/base,upperdir=/upper,workdir=/work \
  /merged

# read-only 마운트 (upperdir/workdir 생략)
$ mount -t overlay overlay \
  -o lowerdir=/layer3:/layer2:/layer1 \
  /merged

# CI/CD 최적화: volatile + metacopy
$ mount -t overlay overlay \
  -o lowerdir=/lower,upperdir=/upper,workdir=/work,volatile,metacopy=on \
  /merged

# xino 활성화 (크로스-레이어 inode 번호 일관성)
$ mount -t overlay overlay \
  -o lowerdir=/lower,upperdir=/upper,workdir=/work,xino=on \
  /merged

주요 옵션 상세 설명:

• volatile — sync(2), syncfs(2), fsync(2)를 upper 파일시스템에 전파하지 않습니다. 비정상 종료 시 upper 레이어가 손상될 수 있으나, CI/CD 빌드 캐시처럼 일시적 데이터에 사용하면 쓰기 성능이 크게 향상됩니다. Docker BuildKit에서 --mount=type=tmpfs 대신 활용할 수 있습니다.
• xino — 각 레이어의 inode 번호 상위 비트에 레이어 인덱스를 인코딩합니다. 이를 통해 서로 다른 레이어에서 동일한 inode 번호를 가진 파일들이 merged 마운트에서 고유한 st_ino를 갖습니다. find, rsync 등 inode 번호 기반 도구가 정상 동작하려면 활성화가 권장됩니다.
• index — upper 레이어의 work/index/ 디렉토리에 lower 파일의 file handle을 저장합니다. 이를 통해 hardlink가 copy-up 후에도 올바르게 유지되고, NFS export 시 reboot 후에도 file handle이 유효합니다.

성능 튜닝 및 모범 사례

OverlayFS 성능의 핵심은 copy-up 최소화입니다. 컨테이너 이미지 빌드와 런타임 양쪽에서 최적화할 수 있습니다.

# Bad: 불필요한 copy-up 유발 Dockerfile
FROM ubuntu:22.04
COPY large_dataset.tar.gz /data/           # 레이어 1: 5GB
RUN tar xzf /data/large_dataset.tar.gz     # 레이어 2: 5GB 풀림 + 5GB tar 잔존
RUN rm /data/large_dataset.tar.gz          # 레이어 3: whiteout만 (5GB는 여전히 레이어 1에)
RUN chmod -R 755 /data/extracted/          # 레이어 4: 전체 copy-up 발생!

# Good: copy-up 최소화 Dockerfile
FROM ubuntu:22.04
COPY large_dataset.tar.gz /tmp/
RUN tar xzf /tmp/large_dataset.tar.gz -C /data/ \
    && rm /tmp/large_dataset.tar.gz \
    && chmod -R 755 /data/extracted/          # 단일 레이어에서 모두 처리

Copy-up 최소화 전략:

• Dockerfile 레이어 병합 — 권한 변경, 파일 삭제를 같은 RUN 명령에서 처리
• 볼륨 마운트 — 빈번히 수정되는 데이터(DB, 로그)는 -v로 OverlayFS 우회
• tmpfs 활용 — 임시 파일은 --tmpfs /tmp으로 메모리에 배치
• multi-stage 빌드 — 빌드 도구/중간 산물을 최종 이미지에서 제외

# ftrace로 copy-up 이벤트 실시간 추적
$ echo 1 > /sys/kernel/debug/tracing/events/overlayfs/ovl_copy_up/enable
$ cat /sys/kernel/debug/tracing/trace_pipe
#           TASK-PID   CPU#  TIMESTAMP  FUNCTION
#              |  |      |       |         |
            bash-1234  [002]  1234.567: ovl_copy_up: path=/etc/config.conf size=4096
            node-5678  [001]  1235.890: ovl_copy_up: path=/app/node_modules/.cache size=52428800

# 추적 중지
$ echo 0 > /sys/kernel/debug/tracing/events/overlayfs/ovl_copy_up/enable

컨테이너 네트워킹

컨테이너 네트워킹은 network namespace로 격리된 네트워크 스택을 veth 페어와 브릿지로 연결하는 구조가 기본입니다.

veth + bridge 모델 (Docker 기본)

# Docker 브릿지 네트워크 확인
$ ip link show type bridge                    # docker0 확인
$ bridge link show                            # bridge에 연결된 veth 목록
$ ip netns list                               # 네트워크 네임스페이스 목록

# 수동으로 veth + bridge 구성 (교육 목적)
$ ip link add veth0 type veth peer name veth1
$ ip link set veth0 master docker0            # 호스트 측을 bridge에 연결
$ ip link set veth1 netns <container_pid>     # 컨테이너 측을 NS로 이동
$ nsenter -t <pid> -n ip addr add 172.17.0.10/16 dev veth1
$ nsenter -t <pid> -n ip link set veth1 up

CNI (Container Network Interface)

CNI는 CNCF 표준으로, 컨테이너 네트워크 설정을 플러그인 체인으로 구성합니다. Kubernetes, Podman, CRI-O가 CNI를 사용합니다.

// CNI 네트워크 설정 예시 (/etc/cni/net.d/10-bridge.conflist)
{
  "cniVersion": "1.0.0",
  "name": "mynet",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipam": {
        "type": "host-local",
        "subnet": "10.22.0.0/16",
        "routes": [{ "dst": "0.0.0.0/0" }]
      }
    },
    { "type": "loopback" },
    {
      "type": "portmap",
      "capabilities": { "portMappings": true }
    }
  ]
}

macvlan / ipvlan 모드

Rootless 컨테이너

Rootless 컨테이너는 User namespace를 활용하여 일반 사용자(non-root)가 컨테이너를 실행하는 기술입니다. 호스트의 root 권한 없이 컨테이너 내부에서 "가짜 root"로 동작합니다.

UID/GID 매핑

# /etc/subuid — 사용자별 subordinate UID 범위
user1:100000:65536       # user1에게 UID 100000-165535 할당

# /etc/subgid — 사용자별 subordinate GID 범위
user1:100000:65536       # user1에게 GID 100000-165535 할당

# 매핑: 컨테이너 내 root(UID 0) → 호스트 user1의 subuid(100000)
# 컨테이너 내 UID 1 → 호스트 100001
# ...
# 컨테이너 내 UID 65535 → 호스트 165535

/* 커널 User namespace UID 매핑 (/proc//uid_map 형식) */
/*   container_uid  host_uid  count */
         0       100000      65536

/* newuidmap/newgidmap 명령으로 설정 */
$ newuidmap <pid> 0 100000 65536
$ newgidmap <pid> 0 100000 65536

Rootless 네트워킹

rootless 환경에서는 veth 페어를 생성할 수 없으므로(CAP_NET_ADMIN 부재), 유저스페이스 네트워크 스택을 사용합니다:

Rootless OverlayFS

Linux 5.11 이전에는 OverlayFS 마운트에 CAP_SYS_ADMIN이 필요했습니다. 커널 5.11부터 User namespace 내부에서 OverlayFS 마운트가 가능해져, FUSE 기반 fuse-overlayfs 없이도 rootless 컨테이너의 이미지 레이어를 직접 사용할 수 있습니다.

네이티브 rootless OverlayFS는 userxattr 마운트 옵션을 자동으로 사용합니다. 이 옵션은 trusted.overlay.* 대신 user.overlay.* 네임스페이스에 메타데이터를 저장하여, 권한 없는 사용자도 xattr을 관리할 수 있게 합니다.

# unshare로 User namespace + Mount namespace 생성 후 OverlayFS 마운트
$ unshare -Urm
# (이제 User NS 내부에서 root 권한)
$ mkdir -p /tmp/lower /tmp/upper /tmp/work /tmp/merged
$ mount -t overlay overlay \
  -o lowerdir=/tmp/lower,upperdir=/tmp/upper,workdir=/tmp/work,userxattr \
  /tmp/merged

# 커널 5.11+ 확인
$ uname -r
5.11.0-generic
$ cat /proc/mounts | grep overlay
overlay /tmp/merged overlay rw,lowerdir=/tmp/lower,upperdir=/tmp/upper,workdir=/tmp/work,userxattr 0 0

커널 5.11 미만이거나 특수한 파일시스템(NFS, FUSE 자체)에서는 fuse-overlayfs가 폴백으로 사용됩니다:

Podman과 Buildah는 런타임에 커널 버전을 감지하여 자동으로 적합한 드라이버를 선택합니다:

# Podman 스토리지 드라이버 확인
$ podman info --format '{{.Store.GraphDriverName}}'
overlay     # 커널 5.11+ → native overlay

# 설정 파일에서 직접 제어 (~/.config/containers/storage.conf)
[storage]
driver = "overlay"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"   # 강제 FUSE 사용 시

Rootless 제한사항

• 특권 포트 — 1024 미만 포트 바인딩 불가 (sysctl net.ipv4.ip_unprivileged_port_start로 조정 가능)
• ping — CAP_NET_RAW 부재로 ICMP 소켓 생성 불가 (sysctl net.ipv4.ping_group_range로 허용 가능)
• cgroup — cgroup v2 + systemd 기반 위임(delegation)이 필요
• NFS — NFS 위의 rootless overlayfs 미지원 (대부분의 환경)

컨테이너 보안 심화

보안 계층 종합

AppArmor 컨테이너 프로파일

# Docker 기본 AppArmor 프로파일 (docker-default) 핵심 규칙
profile docker-default flags=(attach_disconnected,mediate_deleted) {
  # 기본적으로 대부분의 파일 접근 허용
  file,
  network,
  capability,

  # 명시적 deny 규칙
  deny mount,                           # 마운트 차단
  deny /sys/firmware/** rwklx,          # 펌웨어 접근 차단
  deny /sys/kernel/security/** rwklx,   # LSM 인터페이스 접근 차단
  deny /proc/sys/** wklx,               # 커널 파라미터 쓰기 차단
  deny /proc/sysrq-trigger rwklx,       # SysRq 차단
  deny /proc/kcore rwklx,               # 커널 메모리 접근 차단
}

SELinux 컨테이너 정책

# SELinux 컨테이너 컨텍스트 확인
$ ps -eZ | grep container
system_u:system_r:container_t:s0:c123,c456  ... nginx

# 볼륨 마운트 시 레이블 지정
$ podman run -v /data:/data:Z alpine      # :Z = private 레이블 재지정
$ podman run -v /data:/data:z alpine      # :z = shared 레이블 재지정

컨테이너 탈출 공격 벡터와 방어

컨테이너 보안 주요 CVE 사례

컨테이너 탈출과 권한 상승 취약점의 실제 사례를 분석합니다. 컨테이너 런타임, OverlayFS, cgroup 등 다양한 계층에서 발견된 취약점들이 컨테이너 보안 아키텍처의 발전을 이끌어왔습니다.

/* CVE-2019-5736: runc /proc/self/exe 악용 흐름 */

/*
 * 공격 조건: 컨테이너 내부에서 코드 실행 가능 (이미지 포이즌 또는 RCE)
 *
 * 1. 컨테이너 entrypoint를 악성 바이너리로 교체
 * 2. 관리자가 "docker exec  /bin/sh" 실행
 * 3. runc가 컨테이너의 네임스페이스에 진입
 *    → /proc/self/exe가 호스트의 runc 바이너리를 가리킴
 * 4. 악성 프로세스가 /proc/self/exe를 O_WRONLY로 열기 시도
 *    → runc 바이너리가 실행 중이므로 ETXTBSY 반환
 * 5. runc가 execve()로 /bin/sh를 실행한 후,
 *    /proc//exe → 호스트 runc 바이너리
 *    → 이제 ETXTBSY 없이 쓰기 가능
 * 6. 호스트의 runc 바이너리가 악성 코드로 덮어써짐
 *
 * 수정: runc가 자신의 바이너리를 memfd_create()로
 *       메모리에 복사 후 실행 (호스트 파일 직접 참조 방지)
 */

/* CVE-2022-0492 공격 흐름 (CAP_SYS_ADMIN 필요) */

# 1. 컨테이너 내부에서 cgroup v1 마운트
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp

# 2. release_agent에 호스트에서 실행할 명령 지정
echo /path/on/host/exploit.sh > /tmp/cgrp/release_agent

# 3. notify_on_release 활성화
mkdir /tmp/cgrp/x && echo 1 > /tmp/cgrp/x/notify_on_release

# 4. cgroup을 비우면 release_agent가 호스트에서 실행됨
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs" && sleep 1

/*
 * 방어:
 * 1. --cap-drop=ALL (CAP_SYS_ADMIN 제거)
 * 2. seccomp 프로파일에서 mount, unshare 시스콜 차단
 * 3. AppArmor/SELinux로 cgroupfs 마운트 거부
 * 4. cgroup v2 사용 (release_agent 메커니즘 없음)
 * 5. 커널 5.17+에서 cgroup namespace 내 release_agent 쓰기 차단
 */

/* CVE-2024-21626: 파일 디스크립터 누수를 통한 탈출 */

/*
 * runc가 컨테이너 초기화 중 일부 fd를 닫지 않아
 * 호스트 파일시스템의 fd가 컨테이너 내부로 누수
 *
 * 공격: WORKDIR=/proc/self/fd/7 (호스트 / 를 가리키는 fd)
 * → 컨테이너 내부에서 호스트 루트 파일시스템 접근 가능
 *
 * 수정: runc 초기화 시 불필요한 fd를 O_CLOEXEC으로 닫고,
 *       /proc/self/fd 순회하여 예상치 못한 fd 정리
 */

/* 컨테이너 보안 점검 체크리스트 */
# 1. 런타임 버전 확인
$ runc --version   # 1.1.12+ 필수
$ containerd --version

# 2. 컨테이너 capability 확인
$ docker inspect --format '{{.HostConfig.CapAdd}}' <container>
# SYS_ADMIN, SYS_PTRACE, NET_ADMIN 등 불필요 cap 제거

# 3. seccomp 프로파일 확인
$ docker inspect --format '{{.HostConfig.SecurityOpt}}' <container>

# 4. AppArmor/SELinux 상태 확인
$ aa-status   # AppArmor
$ getenforce  # SELinux

gVisor / Kata Containers: 강화 격리

기본 컨테이너는 호스트 커널을 공유하므로 커널 취약점에 노출됩니다. 이를 해결하는 두 가지 접근법이 있습니다:

Kata Containers 심화

Kata Containers는 경량 가상 머신(VM) 내부에서 컨테이너 워크로드를 실행하여, VM 수준의 격리와 컨테이너 수준의 사용자 경험을 결합합니다.

containerd shimv2 연동

Kata는 containerd의 shimv2 인터페이스를 구현하여, 기존 containerd 워크플로에 투명하게 통합됩니다.

# containerd 설정에서 Kata 런타임 등록
# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
  runtime_type = "io.containerd.kata.v2"

# Kubernetes에서 RuntimeClass로 사용
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata

# Pod에서 Kata 런타임 지정
apiVersion: v1
kind: Pod
spec:
  runtimeClassName: kata
  containers:
  - name: app
    image: nginx

주요 설정 옵션 (configuration.toml)

최소 컨테이너 직접 구현

컨테이너의 내부 동작을 이해하기 위해, 셸 스크립트와 커널 API만으로 최소 컨테이너를 직접 구현해 봅니다.

셸 스크립트로 컨테이너 구현 (교육 목적)

#!/bin/bash
# mini-container.sh — 교육용 최소 컨테이너
# root 권한 필요 (rootless는 unshare --user 추가)

set -e
ROOTFS="./rootfs"   # alpine rootfs 등 준비 필요
HOSTNAME="mini-container"

## 1단계: 네임스페이스 생성 + 새 프로세스 시작
unshare --mount --uts --ipc --pid --net --fork \
        --mount-proc=$ROOTFS/proc \
  /bin/bash -c "
    # 2단계: 호스트명 설정 (UTS namespace)
    hostname $HOSTNAME

    # 3단계: 루트 파일시스템 전환 (pivot_root)
    mount --bind $ROOTFS $ROOTFS
    cd $ROOTFS
    mkdir -p .put_old
    pivot_root . .put_old
    umount -l /.put_old
    rmdir /.put_old

    # 4단계: 필수 파일시스템 마운트
    mount -t proc proc /proc
    mount -t sysfs sysfs /sys
    mount -t tmpfs tmpfs /dev

    # 5단계: cgroup 리소스 제한 (v2)
    # (호스트에서 미리 cgroup 디렉토리를 생성해야 함)
    # echo 50000 100000 > /sys/fs/cgroup/mini/cpu.max
    # echo 67108864 > /sys/fs/cgroup/mini/memory.max  # 64MB
    # echo \$\$ > /sys/fs/cgroup/mini/cgroup.procs

    # 6단계: 컨테이너 셸 실행
    exec /bin/sh
  "

runc bundle 생성 및 실행 예제

# OCI Bundle 생성 (rootfs + config.json)
$ mkdir -p mycontainer/rootfs

# Alpine rootfs 준비
$ docker export $(docker create alpine:latest) | \
    tar -C mycontainer/rootfs -xf -

# OCI 기본 config.json 생성
$ cd mycontainer
$ runc spec

# config.json 수정 (예: 메모리 256MB 제한 추가)
# "resources": { "memory": { "limit": 268435456 } }

# 컨테이너 실행
$ runc run my-test-container

# 다른 터미널에서 상태 확인
$ runc list
ID                  PID     STATUS      BUNDLE                CREATED
my-test-container   12345   running     /home/user/mycontainer 2024-...

# 컨테이너 내부에서 격리 확인
/ # hostname
runc
/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 sh
    7 root      0:00 ps aux
/ # cat /proc/1/cgroup
0::/

디버깅과 모니터링

네임스페이스 진입 및 확인

# nsenter — 실행 중인 컨테이너의 네임스페이스에 진입
$ nsenter -t <PID> --mount --uts --ipc --net --pid -- /bin/sh
#   -t: 대상 프로세스 PID
#   각 플래그로 원하는 네임스페이스만 선택적으로 진입 가능

# lsns — 시스템의 모든 네임스페이스 나열
$ lsns
        NS TYPE   NPROCS   PID USER   COMMAND
4026531836 pid         1  1234 root   nginx: master process
4026531840 mnt         1  1234 root   nginx: master process
4026531992 net         1  1234 root   nginx: master process

# 특정 프로세스의 네임스페이스 ID 확인
$ ls -la /proc/<PID>/ns/
lrwxrwxrwx 1 root root 0  ... cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0  ... mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0  ... net -> 'net:[4026531992]'
lrwxrwxrwx 1 root root 0  ... pid -> 'pid:[4026531836]'

프로세스 네임스페이스 정보

# /proc//status에서 네임스페이스별 PID 확인
$ grep NS /proc/<PID>/status
NSpid:  1234    1              # 호스트 PID 1234, 컨테이너 내 PID 1
NStgid: 1234    1
NSsid:  1234    1
NSpgid: 1234    1

# 컨테이너 프로세스의 cgroup 경로
$ cat /proc/<PID>/cgroup
0::/system.slice/docker-abc123.scope

cgroup 모니터링

# systemd-cgtop — cgroup별 리소스 사용량 실시간 모니터링
$ systemd-cgtop
Control Group            Tasks   %CPU  Memory  Input/s  Output/s
/                           85   12.3   1.2G        -        -
/system.slice/docker-abc..   3    5.1  128.0M    4.0K    12.0K

# cgroup v2 직접 확인
$ cat /sys/fs/cgroup/system.slice/docker-abc123.scope/memory.current
134217728      # 128MB 사용 중
$ cat /sys/fs/cgroup/system.slice/docker-abc123.scope/cpu.stat
usage_usec 5234567
user_usec 3123456
system_usec 2111111
$ cat /sys/fs/cgroup/system.slice/docker-abc123.scope/pids.current
3              # 3개 프로세스

디버깅 도구 비교

# crictl — Kubernetes 노드 디버깅
$ crictl pods                                # 파드 목록
$ crictl ps                                  # 컨테이너 목록
$ crictl inspect <container-id>              # 컨테이너 상세
$ crictl logs <container-id>                 # 로그 확인
$ crictl exec -it <container-id> /bin/sh     # 컨테이너 내부 셸

일반적인 문제