[1주차] Sysbox Container Runtime : Storage/Security

CloudNet@ 가시다님이 진행하는 쿠버네티스 네트워크 스터디 3기

✅ 시스템 컨테이너 간 스토리지 공유

• 공유 스토리지를 각 시스템 컨테이너에 바인드 마운트하기만 하면 여러 시스템 컨테이너 간에 스토리지를 쉽게 공유할 수 있습니다.
  
  
• 호스트에 공유 스토리지를 만듭니다. 이 예에서는 Docker 볼륨을 사용합니다

docker volume create shared-storage

• system container 를 만들고 그 안에 공유 스토리지 볼륨을 마운트합니다

docker run --runtime=sysbox-runc -it --rm --hostname syscont --mount source=shared-storage,target=/mnt/shared-storage alpine:latest

• system container 에서 공유 스토리지에 공유 파일을 추가합니다

touch /mnt/shared-storage/shared-file
ls -l /mnt/shared-storage/shared-file

• 다른 셸에서 다른 시스템 컨테이너를 만들고 공유 스토리지 볼륨을 마운트합니다

docker run --runtime=sysbox-runc -it --rm --hostname syscont2 --mount source=shared-storage,target=/mnt/shared-storage alpine:latest

• 두 번째 system container 에 공유 파일이 표시되는지 확인합니다

ls -l /mnt/shared-storage/shared-file

• 각 system container 가 사용자 ID 및 그룹 ID 매핑이 있는 Linux 사용자 네임스페이스를 사용하더라도 두 system container 모두 root:root 권한이 있는 공유 파일을 볼 수 있습니다.
  
  

---

✅ Security

🧿 Root Filesystem Jail

• system container  프로세스는 컨테이너의 루트 파일시스템과 연결된 디렉토리 계층 구조와 구성된 마운트(Docker 볼륨 또는 바인드 마운트)에 국한됩니다.
• 이를 컨테이너의 r oot filesystem jail (“ rootfs jail”)이라고 합니다.

🧿 Linux Namespaces

• Sysbox와 함께 배포된 system container 는 항상 모든 Linux 네임스페이스를 사용합니다.
• Sysbox를 사용하여 system container 를 배포할 때(docker run --runtime=sysbox-runc -it alpine:latest), Sysbox는 항상 모든 Linux 네임스페이스를 사용하여 컨테이너를 생성합니다. 컨테이너 격리를 강화하기 위해 수행됩니다.
• 컨테이너에 사용해야 하는 네임스페이스를 선택하는 것은 상위 계층(Docker + containerd)에 맡기는 OCI 사양에서 Sysbox가 벗어나는 한 가지 영역입니다.
• 아래 표는 system container   와 일반 Docker 컨테이너 간의 네임스페이스 비교한 것입니다.

Namespace	Docker + Sysbox	Docker + OCI runc
mount	Yes	Yes
pid	Yes	Yes
uts	Yes	Yes
net	Yes	Yes
ipc	Yes	Yes
cgroup	Yes	Yes
user	Yes	No by default; 도커 엔진이 userns-remap mode 로 구성된 경우 예입니다.

🧿 User Namespace

• Linux 사용자 네임스페이스를 사용함으로써 시스템 컨테이너는 다음과 같은 이점을 얻습니다:
• 더 강력한 컨테이너 격리 (컨테이너의 루트가 호스트의 권한 없는 사용자에게 매핑됨).
• 컨테이너 내부의 루트 사용자는 컨테이너 내에서 모든 권한(즉, 모든 기능)을 가집니다.

🧿 Cgroup Namespace

• Linux cgroup 네임스페이스는 /proc를 통해 시스템 컨테이너 내부에 노출된 cgroup 정보에서 호스트 경로를 숨겨 격리하는 데 도움이 됩니다.

🧿 Common vs Exclusive Userns ID Mappings

• Linux 사용자 네임스페이스는 컨테이너와 호스트 간에 사용자 ID와 그룹 ID를 매핑하는 방식으로 작동합니다.
• Sysbox는 다음과 같이 매핑을 수행합니다:
  
  • 컨테이너 관리자(Docker 또는 CRI-O)가 사용자 네임스페이스를 활성화한 상태로 컨테이너를 실행하도록 Sysbox에 지시하면 Sysbox는 컨테이너 관리자가 제공한 사용자-ID 매핑을 따릅니다.
  • 그렇지 않으면 Sysbox는 컨테이너에서 사용자 네임스페이스를 자동으로 사용하도록 설정하고 이에 대한 사용자 ID 매핑을 할당합니다.
• 두 경우 모두 Sysbox는 커널의 ID 매핑 마운트 기능 또는 shiftfs 커널 모듈(사용 가능한 기능에 따라 다름)을 사용하여 컨테이너에 마운트된 호스트 파일이 컨테이너의 사용자 네임스페이스 내에 적절한 사용자 ID 및 그룹 ID로 표시되도록 합니다.

---

✅ 시스템 컨테이너 격리 기능

• system container  를 배포합니다.

• Nestybox  system container   는 system container   와 호스트 간에 강력한 격리를 제공하기 위해 항상 Linux 사용자 네임스페이스를 사용합니다(실제로는 모든 Linux 네임스페이스를 사용).
• system container  내부의 프로세스와 호스트의 프로세스 간의 네임스페이스를 비교하여 이를 확인해 보겠습니다.
• system container  에서 확인합니다.

• 이제 호스트에서 확인합니다.

• system container 는 사용자 네임스페이스와 cgroup 네임스페이스를 포함한 전용 네임스페이스를 사용하는 것을 볼 수 있습니다.
• 호스트와 공통 네임스페이스가 없으므로 일반 Docker 컨테이너에 비해 더 강력한 격리 기능을 제공합니다.
• system container   는 Linux 사용자 네임스페이스를 사용하기 때문에 컨테이너의 루트 사용자는 컨테이너에 할당된 리소스에 대한 권한만 가지며 그 외에는 아무 권한도 갖지 않습니다.
• system container  에 다음을 입력하면 이를 확인할 수 있습니다

 cat /proc/self/uid_map
 cat /proc/self/gid_map

• 즉, 컨테이너 내부의 [0:65536] 범위의 사용자 ID는 호스트의 권한이 없는 사용자 ID 범위(Sysbox에서 선택)에 매핑됩니다. 이 예에서는 호스트 사용자 ID 범위[165536: 165536+65535]에 매핑됩니다.
• Sysbox는 모든 컨테이너에 동일한 사용자 ID 매핑을 할당합니다. 
• system container 내에서 루트 사용자가 만든 프로세스의 기능을 확인합니다

• 표시된 것처럼 system container  내부의 루트 프로세스에는 모든 기능이 활성화되어 있지만 이러한 기능은 system container   에 할당된 호스트 리소스에 대해서만 적용됩니다.

---

• CapInh (Inherited):
  
  • 프로세스가 상속받은 권한 비트맵입니다.
  • 설명: 부모 프로세스나 초기 상태에서 상속받은 권한입니다. 이 비트맵은 프로세스가 다른 프로세스에서 상속받은 능력 집합을 보여줍니다.
• CapPrm (Permitted):
  
  • 프로세스가 요청할 수 있는 권한 비트맵입니다.
  • 프로세스가 요청할 수 있는 권한의 집합으로, 이 비트맵에 설정된 권한만을 사용하여 특정 작업을 수행할 수 있습니다. 즉, 이 비트맵에 설정되지 않은 권한은 요청할 수 없습니다.
• CapEff (Effective):
  
  • 현재 프로세스가 실제로 가진 권한 비트맵입니다.
  • 현재 프로세스에서 실제로 적용되는 권한입니다. 이 권한 집합에 따라 프로세스가 시스템 리소스에 접근하거나 특정 작업을 수행할 수 있습니다.
• CapBnd (Bounding):
  
  • 권한의 범위를 설정하는 비트맵입니다.
  • 프로세스가 이 범위를 넘어서 권한을 사용할 수 없도록 제한합니다. 이는 프로세스의 권한이 이 범위 안에 있도록 강제합니다.
• CapAmb (Ambient):
  
  • 현재 프로세스의 권한에 추가적으로 영향을 미치는 비트맵입니다.
  • 특정 권한이 활성화될 수 있도록 설정합니다. 일반적으로, 프로세스의 권한을 더 세밀하게 조정하는 데 사용됩니다.
• 비트맵 값
  모든 필드가 000001ffffffffff로 설정된 것은 모든 권한 비트가 활성화되어 있음을 의미합니다. 이 비트맵은 CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_NET_ADMIN 등 다양한 시스템 권한을 포함하는 64비트 정수 값으로, 이 값이 모든 비트가 설정된 상태를 의미합니다.
• 요약
  이 정보는 현재 프로세스가 모든 권한을 가지며, 권한에 대한 제한이 없다는 것을 나타냅니다. 이는 일반적으로 매우 높은 권한을 가진 프로세스 (예: root 사용자)에서 나타날 수 있습니다.
  이러한 권한 설정을 이해하는 것은 시스템 보안과 권한 관리를 위해 중요합니다. 비트맵이 모든 비트가 설정된 상태인 경우, 프로세스가 거의 모든 시스템 작업을 수행할 수 있다는 것을 의미합니다.