docker 로 pod 따라하기

# docker 로 pod(컨테이너들이 mount,pid,network 네임스페이스 공유)따라하기

# pod 는 다음 컨테이너들로 구성한다.

pause

nginx

ghost (nginx proxy_pass 를 받아 처리할 컨테이너, 참고:https://github.com/TryGhost/Ghost)

# pause(pod 내 컨테이너들의 부모 컨테이너로, ipc(pid), network 네임스페이스를 공유할 수 있도록) 컨테이너 생성

docker run -d --name pause -p 8080:80 --ipc="shareable" k8s.gcr.io/pause:3.2

# 생성된 pause 확인

# sandboxkey 의 network 네임스페이스 들어가서

sandboxkey=$(docker inspect pause | grep -i sandboxkey | awk '{print $2}' | tr -d ,\")

nsenter --net=$sandboxkey

# network 네임스페이스 확인(호스트의 값과 같다.)후 종료

lsns -p $$ -t net

ip a

exit

# 이제 nginx

# nginx.conf 파일 생성

# / 요청은 localhost:2368(ghost)로 프록시 패스한다.

cat > nginx.conf << zzz

error_log stderr;

events { worker_connections 1024; }

http {

  access_log /dev/stdout combined;

  server {

    listen 80 default_server;

    location / {

      proxy_pass http://127.0.0.1:2368;

    }

  }

}

zzz

# nginx 컨터이너 생성

# 위에서 만든 nginx.conf 를 볼륨 마운트하고

# pause 컨테이너의 ipc, network 를 사용(공유)

docker run -d --name nginx -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf --network=container:pause --ipc=container:pause nginx

# nginx 컨테이너에 ip 명령 설치

docker exec nginx apt update

docker exec nginx apt install -y iproute2

# nginx ip 확인

docker exec nginx ip a

# ghost 컨테이너 생성

# pause 컨테이너의 ipc, network 를 사용(공유)

docker run -d --name ghost --network=container:pause --ipc=container:pause ghost

# ghost 컨테이너에 ip 명령 설치

docker exec ghost apt update

docker exec ghost apt install -y iproute2

# ghost ip 확인

docker exec ghost ip a

# 이제 nginx 에서 / 로 접속하면 ghost 결과가 나온다.

docker exec nginx curl -I localhost

runc 사용하기

# runc 는 docker, kubernetes(k8s)등에서 사용하는 OCI(Open Container Initiative) 표준을 준수하는 container 기동(spawning and running) CLI 툴이다.

# golang 설치

wget https://go.dev/dl/go1.17.5.linux-amd64.tar.gz

sudo rm -rf /usr/local/go

sudo tar -C /usr/local/ -zxf go1.17.5.linux-amd64.tar.gz

export PATH=$PATH:/usr/local/go/bin

go version

# runc 빌드 및 설치(최신 golang 버전 필요)

git clone https://github.com/opencontainers/runc

cd runc

make && sudo make install

# 일반유저(vagrant)도 docker 명령을 실행할 수 있게 vagrant 계정을 docker 그룹에 추가

# 한번 exit 하고 다시 로그인해야 한다.

sudo usermod -aG docker vagrant

# busybox 이미지의 파일시스템(파일들)을 tar 로 export

docker export $(docker create busybox) -o busybox_exported.tar

# root 계정으로 전환

sudo -Es

# container 에 압축 풀기

# runc 기동시 rootfs 이름의 디렉토리를 찾는다.

cd ~

mkdir -p ./ysoftman_container/rootfs

tar xvf busybox_exported.tar -C ./ysoftman_container/rootfs

# runc 에서 사용할 명세서 생성

# 기본 명세의 config.json 파일이 생성된다.

# spec -> create a new specification file

cd ysoftman_container

tree -L 2

runc spec

ls config.json

# runc 로 ysoftman1 이름의 컨테이너 기동

runc run ysoftman1

# ysoftman1 컨테이너에서 namespace 확인

ls -ahl /proc/$$/ns

# 호스트 터미널 하나더 열고 root 계정으로 전환

sudo -Es

# 호스트에서 runc 같와 runc 가 실행한 sh 프로세스가 확인

ps -ef | grep -E "runc| sh$"

# 호스트에서 

# runc 네임스페이스 확인

lsns -p $(ps -ef | grep -v grep | grep "runc run ysoftman1" | awk '{print $2}')

# ysoftman1컨테이너(runc)가 실행한 sh pid 로 namespace 상태 확인

lsns -p $(ps --ppid=$(ps -ef | grep -v grep | grep "runc run ysoftman1" | awk '{print $2}') -o pid | grep -v PID)

# 호스트에서 runc 로 기동된 컨테이너 리스트 보기

runc list

# 테스트 결과

# runc help

checkpoint  checkpoint a running container

create      create a container

delete      delete any resources held by the container often used with detached container

events      display container events such as OOM notifications, cpu, memory, and IO usage statistics

exec        execute new process inside the container

kill        kill sends the specified signal (default: SIGTERM) to the container's init process

list        lists containers started by runc with the given root

pause       pause suspends all processes inside the container

ps          ps displays the processes running inside a container

restore     restore a container from a previous checkpoint

resume      resumes all processes that have been previously paused

run         create and run a container

spec        create a new specification file

start       executes the user defined process in a created container

state       output the state of a container

update      update container resource constraints

features    show the enabled features

#####

# 위 golang, runc, busybox 준비되어 있는 상태에서

# rootless container 생성해 보기

# root 계정이라면 일반 계정으로 나오기

exit

# ysoftman_rootless_container 에 압축풀기

cd ~

mkdir -p ./ysoftman_rootless_container/rootfs

tar xvf busybox_exported.tar -C ./ysoftman_rootless_container/rootfs

# rootless 옵션으로 runc 에서 사용할 명세서 생성

cd ysoftman_rootless_container

runc spec --rootless

# /tmp/runc 를 루트로 하는 ysoftman_rootless_container 실행

runc --root /tmp/runc run ysoftman_rootless_container

# 컨터이너에서 user id 와 네임스페이스 확인

id

ls -l /proc/$$/ns

# 호스트에서

# 루트 경로 및 state.json 확인해보기

tree /tmp/runc

cat /tmp/runc/ysoftman_rootless_container/state.json | jq . | head -10

# 호스트에서 runc 같와 runc 가 실행한 sh 프로세스가 확인

ps -ef | grep -E "runc| sh$"

# runc 네임스페이스 확인

lsns -p $(ps -ef | grep -v grep | grep "runc run ysoftman_rootless_container" | awk '{print $2}')

# ysoftman1컨테이너(runc)가 실행한 sh pid 로 namespace 상태 확인

lsns -p $(ps --ppid=$(ps -ef | grep -v grep | grep "runc run ysoftman_rootless_container" | awk '{print $2}') -o pid | grep -v PID)

# user 네이스페이스 id 가 ysoftman_rootless_container 가 호스트와 다르다.

# ysoftman_rootless_container 의 root 로 보이지만 호스트의 root는 아니다.

# 테스트 결과

user namespace 로 kubernetes 와 container 보안 향상

user namespace 로 kubernetes 와 container 보안 향상

출처: https://kinvolk.io/blog/2020/12/improving-kubernetes-and-container-security-with-user-namespaces/

!!! Caution 잘못된 번역이나 이해로 틀릴 수 있음!!! ^^;;

[user namespace 란?]

user namespace 는 user IDs, group IDs 를 격리(isolate)한다. 리눅스에서 모든 프로세스는 특정 userid(/etc/passwd에 정의)와 groupid(/etc/group에 정의)로 소유된다. user namespace 는 container 안에서는 host의 userid,groupid 의 일부만 볼 수 있도록 한다.

예를 들어 container 안에서의 root(user id 0)는 사실 호스트의 userid=100000 이다.

[user namespace and capabilities]

container 에서 root 로 보이지만 실제는 user namespace 로 구분되는 사용자다. 이와 관련된 linux kernel 히스토리를 살펴보자.

- linux 2.2 이전에는 실제 root(user id 0)는 1개 였다.

- linux 2.2 이후부터 root 권한이 여러개의 기능 구분되는 capabilities(https://man7.org/linux/man-pages/man7/capabilities.7.html)로 나뉘어졌다. ex) CAP_NET_ADMIN : network 설정권한, CAP_SYS_ADMIN : mount 설정권한

- linux 3.8 (2013년) 에 user namespace 가 소개되고 capabilities 는 더이상 글로벌하게 사용하지 않고 user namespace 의 context 에 의해서 해석된다.

예로 sshfs(fuse 로 ssh filesystem 에 마운트) 프로그램을 실행할때 CAP_SYS_ADMIN capability 가 요구된다. 이건 host 와 container 사이를 격리시키는 목적에 맞지 않게 container 에거 너무 막강한 권한을 부여하게 된다.

(참고로 FUSE:Filesystem in Userspace 로 user 레벨에서 파일시스템을 만들 수 있도록 해준다.)

container 가 새로운 user namespace 없이 기동된 상태에서 sshfs 성공하기 위핸선 CAP_SYS_ADMIN 을 허용할 수 밖에 없어 보안 취약점을 내포하고 있다.(호슽와 같은 name space 를 쓰면 sshfs 프로세스가 CAP_SYS_ADMIN 권한을 가지고 있어 container 안에서 host 로 나쁜짓을 할 수 있음?)

하지만 container 가 새로운 user namespace 로 격리돼 실행된다면 호스트 user namespace 의 CAP_SYS_ADMIN 없이도 container 내에서의 CAP_SYS_ADMIN 를 허용할 수 있다.(host user namespace 가 아닌 container user namespace 의 CAP_SYS_ADMIN 로 container 의 mount namespace 의 filesystem 에 마운트하는것이라 호스트에는 영향이 없다.)

container 내에서의 root 는 호스트의 root 가 아니기 때문에 host 에 영향을 줘서는 안된다.

[user namespace and filesystems]

linux 는 user namespace 에서의 mounting 안전을 고려해 FS_USERNS_MOUNT flag 를 마크해 filesystems 리스트를 유지한다. 초기화되지 않은 user namespace 에 새로운 마운트를 생성하려면 FS_USERNS_MOUNT 타입이어야 한다. linux 저장소에서 다음과 검색해보면 리스트 찾아 볼 수 있다. 

git grep -nw FS_USERNS_MOUNT

초기화 되지 않은 uesr namespace 는 초기에는 profs 와 sysfs 타입의 파일 시스템으로 제한되었는데 지금은 아래와 같은 파일 시스템이 허용된다. 이런 파일 시스템은 권한이 없는 사용자도 안전하게 사용할 수 있기 때문에 허용됐다.

파일 시스템         user namespace 에서 허용됨

procfs,sysfs --> linux 3.8, 2012

tmpfs        --> linux 3.9, 2013

cgroupfs     --> linux 4.6, 2016

FUSE         --> linux 4.18, 2018

overlay      --> linux 5.11, 2020

NFS,ext4,btrfs,etc  --> 허용 안됨

[impact on container security]

user namespace 는 호스트와 container 를 격리하는 보안 레이어다.

호스트의 runc(OCI(Open Container Initiative)를 따른 컨테이너 런타임)가 container 에 의해 overwritten 될 수 있는 취약점이 있었다. 이 취약점은  runc 바이너리는 root 소유이고 container 에 매핑되지 않았는데도, 컨테이너의 프로세스가 /proc/self/exe 를 통해 호스트의 runc 를 참조를 허용한다. 

flatcar container linux 는 호스트의 runc 바이너리를 읽기전용 파일시스템을 두어 완화했다.

[enabling user namespace for FUSE filesystem]

linux 커널은 파일이 변경되었다면 읽거나 쓰기전에 IMA(integrity Measurement Architecture) 서브시스템을 사용해 감지하고 감사(audit)한다.

FUSE 와 같은 파일시스템은 커널이 remeasure, reppraise, reaudit 없이 파일을 서빙할 수 있다. 

memfs FUSE driver 의 패치를 테스트 하기 위해 다음과 같은 시나오리가 있다고 하자.

1. 첫번째 요청에 FUSE 드라이버는 파일의 초기 내용으로 서빙된다.

2. IMA 파일에 대한 측정(measurement)을 제공한다.

3. 두번째 요청에 FUSE 드라이버는 같은 파일의 변경된 내용으로 서빙된다.

4. IMA 내용을 다시 측정하지 않아 내용 변경이 측정되지 않는다.

IMA 에 'force' 옵션을 주어 항상 remeasure, reppraise, reaudit 하도록 하는 패치를 생각해보자.

커널이 아무 변경도 감지하지 못했는데 모든 요청마다 강제로 측정이 수행된다. FUSE 에서 다르게 동작하는 부분이 다른 파일스템들에서 모두 알수는 없어, 이로 인해 'force' 옵션이 잘못된 레이어에 추가될 수 있다. 이 문제를 해결하기 위해 IMA 캐싱 관련 옵션 수행하는 FS_NO_IMA_CACHE(v1,v2,v3,v4) flag 를 제공한다. IMA 는 FS_NO_IMA_CACHE flat 를 체크한 후 'force' 이 있으면 사용한다. 이런 방법으로 IMA 은 다른 파일 시스템들 모두를 알 필요가 없다.

하지만 IMA 'force' 옵션은 모든 문제를 해결하지는 못하고 아직 중요사항들은 검증되지 않았다. IMA 관리자들에 의해 linux 4.17 에는 다음과 같은 flag가 구현되어졌다.

- SB_I_IMA_UNVERIFIABLE_SIGNATURE flag : 중요 검증되지 않았음을 표시하는

- SB_I_UNTRUSTED_MOUNTER flag : 신뢰하지 않는 user namespace 에 마운트 되었을 때

[bring user namespace to kubernetes]

kubernetes(k8s)에서는 user namespace 기능을 사용할 수 없다. 2016년 관련 개선을 논의하기 시작했다.

첫번째 시도로 k8s 는 default 가 아닌 Container Runtime Interface(CRI)를 사용해 kubelet 는 CRI 의 gRPC interface 로 컨테이너와 통신하고 주요 목적으로 user namespace 를 제공한다.

kubelet 이 container runtime 와 통신하는 방법

- kubelet docker api 로 통신 (deprecated)

Kubelet --> docker --> containers

- kubelet CRI의 gRPC 로 통신, CRI shim(CRI protocol 처리)

Kubelet --(CRI)--> CRI shim --> container runtime --> containers

- CRI protocol처리하는 containerd/cri 로 컴파일된 containerd 를 사용

Kubelet --(CRI)--> containerd/cri|containerd --(OCI spec)--> runc --> containers

[CRI changes for user namespaces]

user namespace 지원을 위한 CRI 변경 아이디어

1. kubelet 이 sandbox(infrastructure container) pod 시작을 위해 RunPodSandBox()로 container runtime 에 요청하면 pod 안에 container 들의 namespace 를 공유

2. kubelet 이 sandbox 에 CreateContainer(), pod 의 각 container들은 sandbox 를 참조하고 있음.

이렇게 해서 pod 의 컨테이너들은 use namespace 를 공유한다.

IPC 와 network namespace 도 pod 레벨에서 공유된다. IPC, network 는 pod 의 user namespacce 의 의해 소유되고 이 네임스페이스에서의 capabilities 가 허용된다.

pod 의 각 container 의 mount namespace 도 user namespace 의 의해 소유된다. 

(pod 에 network, ipc, user namespace 를 두면 호스트와는 격리된체 pod 내 container 들은 자유롭게 통신할 수 있다.)

[kubernetes volumes]

container 들이 같은 volume에 접근할때 다음 시나리오를 고려해 보자.

1. container1 에서 NFS 에 파일을 쓴다. 이 파일은 uid=10000(container1 mapping 되있음)

2. container2 에서 NFS 의 파일을 읽는다. container2에 uid=10000이 mapping 되어 있지 않아 uid=65534(nobody)로 보여진다. 

이 문제를 해결하기 위해 다음과 같은 방법을 사용한다.

1. 모든 pod 에 매핑되어 있는 uid 를 사용한다. 컨테이너들간의 격리는 줄어들지만 user namespace 사용하지 않는것 보단 안전하다.

2. 각 pod 에 매핑되어 다른 uid 를 사용하고 실제 파일을 사용할때 마다 uid를 convert 할 수 있는 메커니즘(mechanism)기능을 추가한다. linux 커널에는 shiftfs, fsid mapping, new mout api 와 같은 메커니즘을 제공한다. 하지만 아직까지는 linux upstream 제품에는 없다.

오늘날 volume 사용하지 않는 작업이 많이 있고 이는 user namespace 에 있어서 이익이다. 완벽한 해결책을 찾으려고 k8s 에 구현중인 user namespace 를 막지는 말자.

[conclusion]

user namespace 는 linux 에서 container 들을 더 안전하게 사용할 수 있는 유용한 레이어를 제공한다. 이는 지난 몇몇 취약점들을 완화하는 것으로 입증됐다. volume 제공시 단점으로 어려움을 겪고 있지만 linux kernel 에서 개발중이니 앞으로 많이 개선될것으로 기대한다.

언젠가 kubernetes 가 user namespace 를 지원을 완료하면 kubernetes 는 호스트와 컨테이너들 간에 더욱 안전하게 격리 효과를 볼 것이다. 이는 좀더 많은 권한으로 운영되는 container 들에서의 새로운 상황에도 적용된다. user namespace 없이 뭔가를 한다는것 아주 위험하다.

docker user namespace remap

# 기본적으로 docker 실행시 root(uid=0, root 이름이 아니더라도 커널은 uid 로 구분하기 때문에 uid=0이면 root다) 로 실행되는데,

# 다음과 같이 docker 실행시 호스트의 root 권한의 디렉토리를 바인딩(마운트)하면

# docker container 안에서 호스트의 root 파일을 변경할 수 있어 위험하다.

docker run -v /etc:/host_etc -it ubuntu

# container 에서 사용자 id 를 보면 root 다.

id

uid=0(root) gid=0(root) groups=0(root)

# container 에서 host 파일을 수정할 수 있다.

echo "hacker ysoftman ..!" >> /host_etc/ysoftman.txt

# user namespace 를 확인해보면

# host 의 user namespace 와

ls -ahl /proc/$$/ns/user

lrwxrwxrwx 1 root root 0 Dec 15 03:33 /proc/897/ns/user -> 'user:[4026531837]'

# docker container 의 user namespace 가 같다.(공유)

ls -ahl /proc/$$/ns/user

lrwxrwxrwx 1 root root 0 Dec 15 03:36 /proc/1/ns/user -> 'user:[4026531837]'

# 이를 방지하기해 docker 실행시 생성되는 사용자 gid,uid 범위를 제한할 수 있다.

# https://docs.docker.com/engine/security/userns-remap/

# host 에서 dockremap 사용자를 추가

sudo useradd dockremap

# host 에서 dockremap 의 uid,gid 20000~30000 범위 설정

sudo vi /etc/subuid

dockremap:200000:300000

sudo vi /etc/subgid

dockremap:200000:300000

# docker.service 파일을 생성하고 다음과 같이 설정하자

sudo vi /etc/systemd/system/docker.service

[Service]

ExecStart=/usr/bin/dockerd --userns-remap=default

# docker daemon 재시작

# 참고로 stop docker 시 다음 에러 발생시 docker.socket 도 중지한다.

# sudo systemctl stop docker

# Warning: Stopping docker.service, but it can still be activated by:

#  docker.socket

sudo systemctl daemon-reload

sudo systemctl stop docker.socket

sudo systemctl stop docker

sudo systemctl start docker

sudo systemctl status docker

# 다시 docker container 를 실행

docker run -v /etc:/host_etc -it ubuntu

# 이제는 container 에서 host 파일을 수정할 수 없다.

echo "hacker ysoftmancd ..!" >> /host_etc/ysoftman.txt

bash: /host_etc/ysoftman.txt: Permission denied

# host 에서 ps 를 해보면 docker container bash 가 20000번대의 uid로 실행되는것을 알 수 있다.

ps -ef | grep bash

200000    1408  1379  0 03:26 pts/0    00:00:00 bash

# docker container 에서 id 를 보면 여전히 root 로 보이지만

# host 와 user namespace 를 다르다. 

id

uid=0(root) gid=0(root) groups=0(root)

# user namespace 를 확인해보면

# host 의 user 네임스페이스와 

ls -ahl /proc/$$/ns/user

lrwxrwxrwx 1 root root 0 Dec 15 03:33 /proc/897/ns/user -> 'user:[4026531837]'

# docker container 의 user 네임스페이스들 다르게 된걸 알 수 있다.

ls -ahl /proc/$$/ns/user

lrwxrwxrwx 1 root root 0 Dec 15 03:32 /proc/1/ns/user -> 'user:[4026532195]'

overlay network 사용하기

# 들어가기 전에

# overlay network 실제 네트워크가 위에서 동작하는 가상네트워크다.

# overlay network 로 물리적으로 떨어져 있는 네트워크들도 마치 같은 네트워크에 있는 LAN 처럼 취급할 수 있다.

# 종류로 Virtual eXtensible LAN (VXLan)가 있다.

# OSI7계층 중 L2(datalink), L3(network) 에 걸쳐 사용되고, L2 프레임을 캡슐화해 터널링한다.

# MTU(Maximum Transmission Unit)는 패킷이나 프레임단위로 전송할때 최대 크기로 일반적으로 1500byte 으로 설정되는데 VXLan 사용시 캡슐화에 50byte 가 필요하기 때문에 1450byte 로 설정한다.

# ICMP(Internet Control Message Protocol) 는 L3 동작하며 대상 IP 의 상태(이상없는지)를 확인하는 프로토콜이다.

# ARP(Address Resolution Protocol)은 L3 동작하며 IP 주소를 L2의 물리주소(MAC, Media Access Control)주소로 바인딩시키기 위한 프로토콜이다.

# FDB(Fowarding DataBase)는 L2 에서 포워딩을 위해 MAC 주소를 저장하고 있다.

#####

# 테스트 환경 : vagrant ubuntu-1804

HOST_NAME = "ubuntu1804"    # node1 192.168.104.2

HOST_NAME2 = "ubuntu1804-2" # node2 192.168.104.3

# node1,2 각각 접속시 

vagrant ssh ubuntu184

vagrant ssh ubuntu184-2

# vxlan 으로 노드간 통신하기

# node1, node2 는 다음과 같이 구성(연결)할 것이다.

[node1]

pinkns(eth0:12.12.12.2/24) <-> overns(veth1 <-> br0:arp참고 <-> vxlan1:fdb참고) <-> host(eth1:192.168.104.2) <-> 외부

[node2]

pinkns(eth0:12.12.12.3/24),skyns(eth0:12.12.12.4/24) <-> overns(veth1 <-> br0:arp참고 <-> vxlan1:fdb참고) <-> host(eth1:192.168.104.3) <-> 외부

# node1, node2 각각 overns, pinkns 이름의 network namespace(netns) 생성

ip netns add overns

ip netns add pinkns

# node1, node2 각각 network namespace 확인

ip netns

# node1, node2 각각 veth1(overns) <-> eth0(pinkns) 연결(link 생성)

ip link add dev veth1 mtu 1450 netns overns type veth peer name eth0 mtu 1450 netns pinkns

# 참고로 ip netns exec overns 대신 overns 에 조인해서 작업할 경우

# 작업후 호스트 network namespace 로 돌아오기 위해 exit 잊지 말자.

# nsenter --net=/var/run/netns/overns

# node1(overns), node2(overns) 에서 ip link 확인

ip netns exec overns ip link

# node1(pinkns) 에서 �eth0 에 mac,ip address 추가

ip netns exec pinkns ip link set dev eth0 address 02:42:c0:a8:00:02

ip netns exec pinkns ip addr add dev eth0 12.12.12.2/24

# node2(pinkns) 에서 eth0 에 mac,ip address 추가

ip netns exec pinkns ip link set dev eth0 address 02:42:c0:a8:00:03

ip netns exec pinkns ip addr add dev eth0 12.12.12.3/24

# node1(overns), node2(overns) 에서 bridge 생성

ip netns exec overns ip link add dev br0 type bridge

ip netns exec overns ip addr add dev br0 12.12.12.1/24

# node1(overns), node2(overns) 에서 ip, link 확인

ip netns exec overns ip a

ip netns exec overns ip link

# node1, node2 에서 vxlan(overns) 생성

# type vxlan : vxlan 타입 생성

# id 42 : vxlan 식별자 42

# proxy : vxlan 이 ARP 요청에 대신 응답하도록 설정

# learning : 커널이 패킷을 파악해 bridge FDB 를 자동으로 설정할 수 있도록 설정

# dstport 4789 : vxlan 터널링에 사용하는 UDP 포트로 4789 사용

ip link add dev vxlan1 netns overns type vxlan id 42 proxy learning dstport 4789

# node1(overns), node2(overns) 에서 veth1 <-> br0 연결

ip netns exec overns ip link set veth1 master br0

# node1(overns), node2(overns) 에서 vxlan1 <-> br0 연결

ip netns exec overns ip link set vxlan1 master br0

# node1, node2 각각 overns, pinkns 의 장치들 모두 power on

ip netns exec overns ip link set br0 up

ip netns exec overns ip link set vxlan1 up

ip netns exec overns ip link set veth1 up

ip netns exec pinkns ip link set eth0 up

# node1(overns) 에서

# 목적지 ip(12.12.12.3),mac(02:42:c0:a8:00:03)를 사용하는 vxlan1 정보를 ARP 테이블에 기록

ip netns exec overns ip neighbor add 12.12.12.3 lladdr 02:42:c0:a8:00:03 dev vxlan1

# node2(overns)에서

# 목적지 ip(12.12.12.2),mac(02:42:c0:a8:00:02)를 사용하는 vxlan1 정보를 ARP 테이블에 기록

ip netns exec overns ip neighbor add 12.12.12.2 lladdr 02:42:c0:a8:00:02 dev vxlan1

# node1(overns), node2(overns) 에서 neighbor 확인

ip netns exec overns ip neighbor show

# node1(overns) 에서

# bridge fdb 설정 추가

# 192.168.104.3 : 목적지 IP

# 42 : 목적지 vni(VXLAN Network Identifier) ID

# 4789 : 목적지 Port

# 다음과 같이 수동으로 설정하면 permanent 하게 유지된다.

ip netns exec overns bridge fdb add 02:42:c0:a8:00:03 dev vxlan1 self dst 192.168.104.3 vni 42 port 4789

# node1(overns) 에서 fdb 설정 확인하면 permanent 표시가 있다.

ip netns exec overns bridge fdb show | grep 02:42:c0:a8:00:03

# node1(overns) 에서 br0, vxlan 에서 패킷 확인시

ip netns exec overns tcpdump -l -i br0

ip netns exec overns tcpdump -l -i vxlan1

# 위에서 vxlan 디바이스 생성 시에 learning 옵션사용했기 때문에 fdb, ARP 정보는 커널에서 패킷 분석해서 설정해준다.

# 하지만 수동설정(permanent)와 달리 aging 으로 인해 일정 시간 지나면 설정이 제거된다.

# node2(overns)에서 다음과 같이 다시 수동으로 변경하면 permanent 하게 설정된다.

ip netns exec overns bridge fdb replace 02:42:c0:a8:00:02 dev vxlan1 self dst 192.168.104.2 vni 42 port 4789

# node2(overns)에서 다시 fdb 설정 확인하면 permanent 가 있다.

ip netns exec overns bridge fdb show | grep 02:42:c0:a8:00:02

# 참고로 overns 의 FORWARD 가 허용으로 되어 있는지 확인

ip netns exec overns iptables -t filter -L | grep -i policy

Chain INPUT (policy ACCEPT)

Chain FORWARD (policy ACCEPT)

Chain OUTPUT (policy ACCEPT)

# node1(pinkns조인 상태) -> node2(pinkns) ping 해보면 응답을 받는다.

ip netns exec pinkns ping 12.12.12.3

# node2(pinkns조인 상태) -> node1(pinkns) ping 해보면 응답을 받는다.

ip netns exec pinkns ping 12.12.12.2

#####

# node1 에 새로운 skyns network namespace 추가하고 통신하기

# node1 에서 skyns 네트워크네임스페이스 추가, mac,ip 등 추가하고 power on

ip netns add skyns

ip link add dev veth2 mtu 1450 netns overns type veth peer name eth0 mtu 1450 netns skyns

ip netns exec skyns ip link set dev eth0 address 02:42:c0:a8:00:04

ip netns exec skyns ip addr add dev eth0 12.12.12.4/24

ip netns exec overns ip link set veth2 master br0

ip netns exec overns ip link set veth2 up

ip netns exec skyns ip link set eth0 up

# node1(skyns) -> node1(pinkns) ping 테스트

ip netns exec skyns ping 12.12.12.2

# node1(pinkns) -> node1(skyns) ping 테스트

ip netns exec pinkns ping 12.12.12.4

# node2(overns) 에서 fdb 추가

ip netns exec overns ip neighbor add 12.12.12.4 lladdr 02:42:c0:a8:00:04 dev vxlan1

# node1(skyns) -> node2(pinkns) ping 테스트

ip netns exec skyns ping 12.12.12.3

#####

# node3(192.168.104.4) 추가하고 node1,2와 통신하기

# vagrantfile 노드 추가 후 

# HOST_NAME3 = "ubuntu1804-3" # node3 192.168.104.4

# ubuntu1804-3(node3) 만 추가로 띄우기

# vagrant up

# ubuntu1804-3(node3) 접속

vagrant ssh ubuntu184-3

# node3 overns,pinkns, skyns network namespace 추가

ip netns add overns

ip netns add pinkns

ip netns add skyns

# node3 veth1(overns) <-> eth0(pinkns) 연결(link 생성)

ip link add dev veth1 mtu 1450 netns overns type veth peer name eth0 mtu 1450 netns pinkns

# node3 veth1(overns) <-> eth0(skyns) 연결(link 생성)

ip link add dev veth2 mtu 1450 netns overns type veth peer name eth0 mtu 1450 netns skyns

# node3(pinkns) 에서 eth0 에 mac,ip address 추가

ip netns exec pinkns ip link set dev eth0 address 02:42:c0:a8:00:0a

ip netns exec pinkns ip addr add dev eth0 12.12.12.10/24

# node3(skyns) 에서 eth0 에 mac,ip address 추가

ip netns exec skyns ip link set dev eth0 address 02:42:c0:a8:00:0b

ip netns exec skyns ip addr add dev eth0 12.12.12.11/24

# node3(overns) 에서 bridge 생성

ip netns exec overns ip link add dev br0 type bridge

ip netns exec overns ip addr add dev br0 12.12.12.1/24

# node3(overns) 에서 vxlan 생성

ip link add dev vxlan1 netns overns type vxlan id 42 proxy learning dstport 4789

# node3(overns) 에서 veth1 <-> br0, veth2 <-> br0, vxlan1 <-> br0 연결

ip netns exec overns ip link set veth1 master br0

ip netns exec overns ip link set veth2 master br0

ip netns exec overns ip link set vxlan1 master br0

# node3 overns, pinkns, skyns 의 장치들 모두 power on

ip netns exec overns ip link set br0 up

ip netns exec overns ip link set vxlan1 up

ip netns exec overns ip link set veth1 up

ip netns exec overns ip link set veth2 up

ip netns exec pinkns ip link set eth0 up

ip netns exec skyns ip link set eth0 up

# node3(overns) 에 node1,node2 ip,mac 정보를 ARP 테이블에 기록

ip netns exec overns ip neighbor add 12.12.12.3 lladdr 02:42:c0:a8:00:03 dev vxlan1

ip netns exec overns ip neighbor add 12.12.12.2 lladdr 02:42:c0:a8:00:02 dev vxlan1

# node3(overns) 에 node1,nod2 ip,mac 정보를 fdb 로 기록

ip netns exec overns bridge fdb add 02:42:c0:a8:00:02 dev vxlan1 self dst 192.168.104.2 vni 42 port 4789

ip netns exec overns bridge fdb add 02:42:c0:a8:00:03 dev vxlan1 self dst 192.168.104.3 vni 42 port 4789

# node1(overns), node2(overns) 에 node3 ip,mac 정보를 ARP 테이블에 기록

ip netns exec overns ip neighbor add 12.12.12.10 lladdr 02:42:c0:a8:00:0a dev vxlan1

ip netns exec overns ip neighbor add 12.12.12.11 lladdr 02:42:c0:a8:00:0b dev vxlan1

# node1(overns), node2(overns) 에 node3 ip,mac 정보를 fdb 로 기록

ip netns exec overns bridge fdb add 02:42:c0:a8:00:0a dev vxlan1 self dst 192.168.104.4 vni 42 port 4789

ip netns exec overns bridge fdb add 02:42:c0:a8:00:0b dev vxlan1 self dst 192.168.104.4 vni 42 port 4789

# node1(pinkns) -> node3(pinkns), node3(skyns) ping 테스트

ip netns exec pinkns ping 12.12.12.10

ip netns exec pinkns ping 12.12.12.11

# node2(pinkns) -> node3(pinkns), node3(skyns) ping 테스트

ip netns exec pinkns ping 12.12.12.10

ip netns exec pinkns ping 12.12.12.11

# node3(pinkns) -> node1(skyns) ping 테스트

ip netns exec pinkns ping 12.12.12.2

# node3(pinkns) -> node2(skyns) ping 테스트

ip netns exec pinkns ping 12.12.12.3

# 모든 테스트가 끝나고 network namespace 삭제하려면

ip netns delete overns

ip netns delete pinkns

ip netns delete skyns

container overlay filesystem

# union filesystem mount 는 n개의 파일시스템을 하나로 마운트하는 것으로

# overlayFS, overlayFS2, AUFS 등이 있다.

# overlayFS 는 다음과 같은 layer 구조다.

# 아래 layer 파일은 상위 layer 에 투영되어 사용자는 최종 merged view 에서 모든 이전 layer 들의 파일이 있다.

# 같은 파일이라면 상위 layer 쪽이 선택된다.

# overlayFS2 는 다음과 같은 layer 로 구성된다.

[merged dir] - container mount 로 보여지는 내용으로, 최종 통합된 레이어

c.txt(from lower dir2) b.txt(from upper dir) a.txt(from lower dir1)

[upper dir] - container 에 변경 사항을 기록 하는 레이어

b.txt

[lower dir2] - 기존 이미지 readonly

c.txt b.txt

[lower dir1] - 기존 base 이미지 readonly

a.txt

# 위 4개의 layer 외에 추가로 work dir 이 있다.

[work dir] - atomic 보장을 위해, merged 에 반영되기전에 사용하는 임시 공간

# overlay filesystem 마운트 테스트

# 마운트 테스트에 사용할 디렉토리 생성

mkdir ysoftman_overlay1

cd ysoftman_overlay1

mkdir image1 image2 upper work merge

touch image1/a.txt image2/{b.txt,c.txt}

# -o 옵션으로 각 layer 에 해당하는 디렉토리 설정

# workdir 는 merged 에 반영전 준비를 위한 공간

# 최종 merged view layer 는 merge 디렉토리에 마운트 된다.

mount -t overlay overlay \

-o lowerdir=image2:image1,upperdir=upper,workdir=work \

merge

# 마운트 후 work 디렉토리를 보면 변경된 내용을 파악할 수 있다.

tree -I work

.

├── image1

│   └── a.txt

├── image2

│   ├── b.txt

│   └── c.txt

├── merge

│   ├── a.txt

│   ├── b.txt

│   └── c.txt

├── upper

└── work

    └── work

# 파일을 삭제하면 upper에 whiteout(파일 변경되었음을 표시)된다.

rm -rf merge/a.txt

ls -ahl upper/a.txt

c--------- 1 root root 0, 0 Dec  1 05:00 upper/a.txt

tree -I work

.

├── image1

│   └── a.txt

├── image2

│   ├── b.txt

│   └── c.txt

├── merge

│   ├── b.txt

│   └── c.txt

└── upper

    └── a.txt # whiteout

#####

# docker image layer 정보 확인

# 최신 nginx 도커 이미지 다운로드

docker pull nginx:latest

# layer id 확인

docker image inspect nginx:latest | jq '.[].RootFS'

# docker storage driver, root dir 확인해

docker info | grep -i -E "storage driver|root dir"

# (layer 정보를 가지고 있는)layerdb id 확인

cd /var/lib/docker/image/overlay2/layerdb

tree ./sha256/ -L 1

# layer id 확인

ls sha256/*/diff | awk '{system("cat "$0"; echo")}'

# 이 layer 의 부모 layer 를 가진 layerdb id 가 기록되어 있다.

ls sha256/*/parent | awk '{system("cat "$0"; echo")}'

# layer 가 저장된 경로 id 확인

# /var/lib/docker/overlay2/xxx 디렉토리 이름을 나타낸다.

ls sha256/*/cache-id | awk '{system("cat "$0"; echo")}'

#####

# nginx image layer 로 container 띄우기

# nginx GraphDriver(layer) 확인

docker image inspect nginx | jq '.[].GraphDriver'

# LowerDir 값중 마지막 부분은 최상위 부모 이미지로 내용을 확인해 볼 수 있다.

tree -L 1 /var/lib/docker/overlay2/1431186159df61d78822ed287754ce0e079739695e8966adb816f509687a1d92/diff

# nginx overlayFS 가 마운트될 디렉토리 생성

mkdir nginx_overlay

cd nginx_overlay

mkdir upper work merge

# nginx overlay 마운트

# lower 는 기존 이미지 사용

# upper,worker 는 생성한 디렉토리로 연결

# 모든 layer 가 오버레이된 디렉토리 merge 연결

mount -t overlay overlay \

-o "lowerdir=/var/lib/docker/overlay2/cfe31bc0b1bcc056093f9d1b73a090c81f4ce284eccf37e50344258a434fa5b1/diff:/var/lib/docker/overlay2/a9bcb65c3bfbad6d4fb692677b94fcda85b8856e4836490cc987296a5f902f4a/diff:/var/lib/docker/overlay2/3d6e60f9c348c81d24ecafbfb23a6e531541778efc36d41dd064c1e8b20dd4ad/diff:/var/lib/docker/overlay2/6d60e98403eadb29449726645f338d8a47dd8cd6fcfa22b6565d5c46d83519bc/diff:/var/lib/docker/overlay2/1431186159df61d78822ed287754ce0e079739695e8966adb816f509687a1d92/diff,\

upperdir=upper,\

workdir=work" \

merge

# nginx 마지막 layer 에서 nginx 실행 커맨드 파악

docker history nginx:latest --no-trunc | sed -n '1,2p' | tr -d ' '

# -m 새로운 마운트 네임스페이스 시작

unshare -m

# 새로운 마운트 네임스페이스에서 chroot 커맨드로 ./merge 를 root 디렉토리로 설정

chroot ./merge

# 또는 pivot_root 로 root 를 ./merge 로 변경

cd merge

mkdir put_old

pivot_root . put_old

# nginx 백그라운드로 실행하고 access 로그를 확인

nginx -g "daemon off;" & tail -F /var/log/nginx/access.log

# 새 터미널을 열고 nginx 동작 확인

curl localhost

# 위 과정 실행 결과

# unshare 종료하고, nginx 프로세스 마운트 해제

exit

killall nginx

umount /tmp/nginx_overlay/merge

container 에 없는 iptables 커맨드 실행하기

# container 에 없는 iptables 커맨드 실행하기

# 방법1

# container 시작시 호스트 볼륨 연결하기

# 이미 컨테이너가 존재하면 삭제(--rm)

# 호스트의 root path 를 컨테이너의 /host 로 연결하고, (--volume /:/new_root)

# 컨테이너에게 확장권한을 부여한다.(--privileged)

# 컨테이너 실행시 /new_root 로 root 를 변경한다.

docker run -it \

--name=ysoftman

--hostname=ysoftman \

--rm \

--volume /:/new_root \

--privileged  \

busybox \

chroot /new_root

# 이제 컨테이너 내에서 호스트의 커맨드가 실행된다.

iptables -t filter -S

# 방법2

# 컨테이너 내에서 --pid=host 로 호스트 PID namespace 를 사용한다.

# https://docs.docker.com/engine/reference/run/#pid-settings---pid

# 호스트의 pid 1(system) 대상으로(-t) -m(--mount[=file], 파일을 명시하지 않으면 target process 의 mount namespace 조인)

docker run -it \

--name=ysoftman \

--hostname=ysoftman \

--rm \

--privileged \

--pid=host \

busybox \

nsenter -t 1 -m sh

# 이제 컨테이너 내에서 호스트의 mount 정보로 호스트의 커맨드가 실행된다.

iptables -t filter -S

# 방법3

# 그냥 컨테이너 실행

docker run -it --name=ysoftman --hostname=ysoftman busybox

# 터미널을 하나 더 열고 호스트에서

# 위 컨테이너의 pid 의 network namespace 조인해 iptables 명령 실행한다.

# -t(--target) pid -n(--net[=file], 파일을 명시하지 않으면 target process의 네트워크 네임스페이스로 조인)

nsenter -t $(docker inspect --format {{.State.Pid}} ysoftman) -n iptables -t filter -S

linux namespace

# 2002년 리눅스 커널에 포함된 namespace(mnt, pid, net, ipc, cgroup...타입) 로 isolation 구현

# 모든 프로세스들은 특정 네임스페이스에 속하고 unshare 로 새로운 네임스페이스에서 프로세스를 실행할 수 있다. 네임스페이스는 exit 로 빠져나올 수 있다.

# unshare 시 프로세스를 명시하지 않으면 ${SHELL}값(/bin/sh 또는 /bin/bash등)이 디폴트로 실행된다.

#####

# mnt namespace

# 부모(호스트)로 부터 격리된 mount타입(-m, --mount)의 네임스페이스로 /bin/bash 프로그램 실행

unshare --mount /bin/sh

# mount_ns 에 마운트하면 현재 네임스페이스에서만 마운트된것을 알 수 있다.

# tmpfs : 가상 메모리 파일시스템

# ushare 된 마운트 스페이스(격리됨)에서 생성한 마운트는 호스트에서 보이지 않는다.

mkdir /tmp/mount_ns

mount -n -t tmpfs tmpfs /tmp/mount_ns

mount | grep mount_ns

# 터미널을 하나 더 띄워 호스트 네임스페이스에서 보면 값이 다른것을 알 수 있다.

readlink /proc/$$/ns/mnt

# 호스트에서 tmpfs 마운트 정보가 안보이는것을 확인

mount | grep mount_ns

# 테스트 결과

#####

# pid namespace

# 새로운 pid(-p, --pid), -f(--fork) 네임스페이스으로 실행

# --mount-proc Just before running the program, mount the proc filesystem at mountpoint (default is /proc)

# --mount-prod 옵션을 사용하면 pid 네임스페이스가 /proc/{pid} 로 마운트되어 쉽게 pid 네임스페이스 접근할 수 있도록 해준다.(mount namspace 도 생긴다.)

unshare -fp --mount-proc /bin/sh

# 호스트 네임스페이스와 현재 pid 네임스페이스에 다른 pid 로 보인다.

# 현재 pid 네임스페이스에서 프로세스를 확인해보면 1번이다.

echo $$

ps -ef

# pid 네임스페이스에서의 pid namespace 정보를 보면

# 아래 호스트의 unshare mount namespace 와 다른것을 알 수 있다.

# unshare(mt ns id:4026532202) ---> pid-namespace /bin/sh (pid ns id:4026532203)

lsns -t pid -p 1

# 호스트에서 unshare 프로세스 pid 찾기

ps -ef | grep unshare

# ushare 프로세스의 namespace 정보

# ls -ahl /proc/{pid}/ns 로도 알 수 있다.

lsns -p {pid}

# mnt 네임스페이스ID 로 확인

lsns {namespace id}

# 테스트 결과 화면

#####

# cgroup namespace

# cgroup 는 controlgroup으로 프로세스의 리소스 제어하는 파일시스템이다.(sys/fs/cgroup)

# sleep 백그라운드 프로세스를 freezer(cgroup 작업 중지,재개를 위한 subsystem)의 sub2로 등록

mkdir -p /sys/fs/cgroup/freezer/sub2

sleep 100000 &

[1] 2932

# 테스트를 위해 sleep pid 환경변수로 설정 

export sleep_pid=2932

# sleep pid 를 sub2 cgroup 으로 등록

echo ${sleep_pid} > /sys/fs/cgroup/freezer/sub2/cgroup.procs

# 현재 프로세스도 freezer sub1 로 등록하자.

mkdir -p /sys/fs/cgroup/freezer/sub1

# 현재프로세스 확인, 테스트를 위해 현재 pid 환경변수로 설정 

echo $$

2178

export parent_pid=$(echo $$)

# 현재 프로세스 pid 를 sub1 cgroup 으로 등록

echo ${parent_pid} > /sys/fs/cgroup/freezer/sub1/cgroup.procs

# freezer (init process, PID 1), parent, sleep pid 확인

cat /proc/1/cgroup | grep freezer

cat /proc/${parent_pid}/cgroup | grep freezer

cat /proc/${sleep_pid}/cgroup | grep freezer

# freezer 파일 확인

tree -L 1 /sys/fs/cgroup/freezer/

/sys/fs/cgroup/freezer/

├── cgroup.clone_children

├── cgroup.procs

├── cgroup.sane_behavior

├── docker

├── notify_on_release

├── release_agent

├── sub1

├── sub2

└── tasks

# 새로운 cgroup(-C, --cgroup) 네임스페이스로 실행

unshare -Cm /bin/sh

# freezer (init process, PID 1), parent, sleep pid 확인해보면

# sub1 --> / 가 루트가 되고

# sub2 --> ../sub2 로 변경되었지만 호스트 cgroup 은 그대로 보인다.

cat /proc/1/cgroup | grep freezer

cat /proc/2178/cgroup | grep freezer

cat /proc/2932/cgroup | grep freezer

# 테스트 결과

#####

# stress 툴로 시스템 부하(cpu)를 테스트해보자.

# new_root 에 bash 준비하기

mkdir -p new_root/{bin,usr,lib,lib64} new_root/lib/x86_64-linux-gnu/ new_root/usr/lib/x86_64-linux-gnu

cp /bin/bash new_root/bin

cp /bin/mount new_root/bin

cp /lib/x86_64-linux-gnu/{libtinfo.so.5,libdl.so.2,libc.so.6} new_root/lib

cp /lib64/ld-linux-x86-64.so.2 new_root/lib64

# mount 명령등 준비하기

cp -rv /bin/{ls,cat,mount,umount,mkdir,rmdir,rm,cp,grep,ps} new_root/bin

cp -rv /usr/lib/x86_64-linux-gnu/* new_root/usr/lib/x86_64-linux-gnu

cp -rv /lib/x86_64-linux-gnu/* new_root/lib/x86_64-linux-gnu

cp -rv /lib64/* new_root/lib64

# stress, cgroup 툴 설치

apt-get install -y stress cgroup-tools

# chroot 후 필요한 파일들 복사

mkdir -p new_root/usr/bin/bin

cp /usr/bin/{top,stress,cgcreate,cgset,cgexec} new_root/usr/bin/

# top 실행시 필요한 파일들 복사

mkdir -p new_root/usr/share/terminfo

cp -r /usr/share/terminfo/ new_root/usr/share/terminfo

# cgcreate 시 root uid 파악에 필요

mkdir -p new_root/etc

cp /etc/group new_root/etc/group

cp /etc/passwd new_root/etc/passwd

# cgroup 관련 마운트 확인

mount | grep -E "cgroup*.cpu"

# chroot 후 mount 하기

chroot new_root

mkdir -p /sys/fs/cgroup

mkdir -p /sys/fs/cgroup/{cpuset,"cpu,cpuacct"}

mount -t cgroup -o cpuset cgroup /sys/fs/cgroup/cpuset

mount -t cgroup -o cpu,cpuacct cgroup /sys/fs/cgroup/cpu,cpuacct

# /proc 마운트

mkdir -p /proc

mount -t proc proc /proc

# mycgroup 생성 및 확인

cgcreate -a root -g cpu:mycgroup

ls -al /sys/fs/cgroup/cpu,cpuacct/ | grep mycgroup

# CPU 사용률(%) = (cpu.cfs_quota_us / cpu.cfs_period_us) * 100

# cpu.cfs_period_us 를 확인해 보면 100000(us, 100ms) 이다.

# cat /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us

# 따라서 cpu.cfs_quota_us=30000 을 주면 30% cpu 사용률로 제한한다.

cgset -r cpu.cfs_quota_us=30000 mycgroup

# mycgroup 에 strecc -c(--cpu) 1로 부하 테스트 백그라운드로 실행

cgexec -g cpu:mycgroup stress -c 1 &

# top 으로 stress 프로세스 30% 사용 확인

export TERM="xterm-256color"

top

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND

 3129 root      20   0    8248     96      0 R  30.0  0.0   0:03.50 stress

# 테스트 결과

#####

# net namespace

# 새로운 network(-n, --net) 네임스페이스으로 실행

unshare --net /bin/sh

# 호스트 네임스페이스와 정보가 다른것을 알 수 있다.

ip a

# 테스트 결과

# ip 로 net namespace 생성해보기

ip netns add mynet

# net namespace 확인

ip netns list

# 또는

ls /var/run/netns

# nsenter 로 net네임스페이스(--net)에 들어가기

# 별도 프로그램 명시하지 않으면 디폴트로 $SHELL -> /bin/bash 를 실행한다.

nsenter --net=/var/run/netns/mynet

ip a

# net 네임스페이스에서 현재 프로세스의 pid,user,ipc,mnt등의 네임스페이스 정보 확인

lsns -p $$

# 호스트에서 net 네임스페이스 id 확인

# readlink /proc/$$/ns/net 대신 lsns 명령어로도 네임스페이스 정보를 확일 수 있다.

# lsns -t 타입 -p pid

lsns -t net -p $$

# 테스트 결과

#####

# user namespace 생성

# 새로운 user(-U, --user) 네임스페이스으로 실행

unshare --user /bin/sh

# 새로운 user 네임스페이스에서의 사용자 정보 확인

whoami

id

# 네임스페이스 확인해보기

ls -al /proc/$$/ns

lsns -p $$

# 테스트 결과 화면

# container 와 호스트 root 가 같은것인지 확인해보기

# docker 로 busybox 컨테이너 띄우기

docker container run -it --name busybox --rm busybox

# ps 로 보면 root 로 실행됐고, uid=0 으로 되어 있다

ps -ef

id

# 현재 프로세스의 user 네임스페이스 확인

readlink /proc/$$/ns/user

# 호스트에서도 확인해보면 root 이름이고 uid=0 이다.

ps -ef | grep root | head -3

id

# 호스트에서 현재 프로세스의 user 네임스페이스 확인해보면 위 container user namespace id 와 같은것을 알 수 있다.

# 결국 container 의 root 도 호스트 user 네임스페이스를 공유하기 때문에 호스트 root 와 같은것이다.

readlink /proc/$$/ns/user

# 테스트 결과 화면

# 참고로 docker v1.10 이상 부터는 별도의 user namespace 를 지원하지만

기본적으로 docker 로 컨테이너를 실행하면 root 로 프로세스를 실행한다.(user namespace 를 별도로 만들지 않고 호스트를 user namespace 를 사용한다.)

# 이 때문에 container root 계정이 악용될 수 있음을 인지해야 한다.

# docker remap 설정으로 uid 를 다르게할 수 있다. 아래 별도 포스트로 정리

https://yoonbh2714.blogspot.com/search?q=docker%20remap

#####

# uts(unix time sharing system) namespace

# 새로운 uts(-u, --uts) 네임스페이스으로 실행

unshare --uts /bin/sh

# 호스트명 변경하고 확인

hostname ysoftman

hostname

# 터미널을 하나 더 띄워 호스트를 확인해 보면 영향을 주지 않는것을 알 수 있다.

# 테스트 화면

#####

# ipc(interprocess communication) namespace

# shared memory, queue, semaphore 등의 리소스에서 사용되며 같은 ipc 네임스페이스안 프로세스들은 ipc 통신할 수 있다.

# ipc (shared memory, pipe) 상태 정보 보기

# -m  Write information about active shared memory segments.

ipcs -m

# ipc shared memeory 리소스 1000byte 생성

# -m Create a shared memory segment of size bytes.

ipcmk -M 1000

# 1000 byte shared memory segemnt 가 생성된것을 확인할 수 있다.

ipcs -m

# 새로운 ipc(-i, --ipc) 네임스페이스 생성

unshare --ipc /bin/sh

# 새로운 ipc 네임스페이스에서는 호스트에서 만든 1000bytes 리소스가 보이지 않는다.

ipcs -m

# 호스트로 나오기

exit

# ipc 리소스 삭제

# -M Remove the shared memory segment created with shmkey after the last detach is performed.

ipcrm -M {shared memory segment key}

# 삭제된 리소스 확인 

ipcs -m

# 위 과정을 테스트한 결과

chroot, pvirot_root, unshare

# container 없던 시절 완벽하진 않은 격리효과를 위해서 사용할 수 있는 명령들

# 가상작업환경 : virtualbox + vagrant + ubuntu box image

# vagrant up 후 vagrant ssh 로 접속

# root 환경에서 작업하기

sudo -Es

# 마운트등의 이슈로 /tmp 에서 작업한다.

cd /tmp

# chroot 사용하기

# 새로운 root 경로가 될 디렉토리 생성

mkdir new_root

# 단순히 chroot new_root 하면

chroot new_root

# 다음과 같은 에러가 발생한다.

chroot: failed to run command ‘/bin/bash’: No such file or directory

# chroot 하면 bash 가 실행하는데 new_root 에서는 bin/bash 가 없어 이를 새루트에 복사해야 한다.

# bash 구동을 위해 필요한 파일들 확인하자

ldd /bin/bash

linux-vdso.so.1 (0x00007ffe49bfb000)

libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fc6e4d28000)

libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc6e4b24000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc6e4733000)

/lib64/ld-linux-x86-64.so.2 (0x00007fc6e526c000)

# bash 및 관련 라이브러리 복사

mkdir -p new_root/{bin,usr,lib,lib64} new_root/lib/x86_64-linux-gnu/ new_root/usr/lib/x86_64-linux-gnu

cp /bin/bash new_root/bin

cp /lib/x86_64-linux-gnu/{libtinfo.so.5,libdl.so.2,libc.so.6} new_root/lib

cp /lib64/ld-linux-x86-64.so.2 new_root/lib64

# ls 외 필요한 기본 명령어도 확인하고 복사하자.

# ps 는 /proc 디렉토리를 생성(mkdir)하고 mount 해야 사용할 수 있다.

ldd /bin/ps

linux-vdso.so.1 (0x00007ffc403b6000)

libprocps.so.6 => /lib/x86_64-linux-gnu/libprocps.so.6 (0x00007f594c99d000)

libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f594c799000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f594c3a8000)

libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f594c124000)

/lib64/ld-linux-x86-64.so.2 (0x00007f594ce03000)

librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f594bf1c000)

liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f594bcf6000)

liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f594bada000)

libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f594b7be000)

libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f594b59f000)

libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f594b38a000)

# 일일히 lib 복사하지 말고 그냥 lib,lib64 파일 모두 복사해놓자.

cp -rv /bin/{ls,cat,mount,umount,mkdir,rmdir,rm,cp,grep,ps} new_root/bin

cp -rv /usr/lib/x86_64-linux-gnu/* new_root/usr/lib/x86_64-linux-gnu

cp -rv /lib/x86_64-linux-gnu/* new_root/lib/x86_64-linux-gnu

cp -rv /lib64/* new_root/lib64

# 이제 chroot 를 해보면 /bin/bash 가 실행된다.

chroot new_root

# root 경로가 바뀐것 확인(cat,mkdir,ps 등도 동작한다.)

ls /

# ps 명령을 실행하기 위해선 /proc 디렉토리를 만들고 마운트해야한다.

mkdir -p /proc

mount -t proc proc /proc

# chroot 는 다음코드를 실행하면 현재 root 경로를 나갈수 있다(탈옥가능)

cat > break_chroot.c << EOF

#include <sys/stat.h>

#include <unistd.h>

int main(void)

{

    mkdir("foo", 0755);

    chroot("foo");

    chdir("../../../../../");

    chroot(".");

    return execl("/bin/bash", "-i", NULL);

}

EOF

# 빌드

gcc break_chroot.c -o break_chroot

# new_root 에 복사하고

cp -v break_chroot new_root

# new_root 에서 실행하면 chroot 의 / 를 빠져나가는 이슈가 있다.

chroot new_root

./break_chroot

# chroot 나가기

exit

#####

# pivot_root : root 를 new_root 아래로 mount 하여 경로 탈옥을 막아보자.

# 새로운 root 경로가될 디렉토리 생성

mkdir new_root2

# unshare 는 부모로 부터 격리된 특정 네임스페이스로 프로그램 실행�한다.

# -m : unshare mount namespace

# 프로그램 명시하지 않으면 기본 $SHELL(/bin/sh 등) 를 실행한다.

unshare -m

# 새로운 파일시스템을 생성해 new_root2 에 마운트

# 참고로 

# chroot 테스트에서 사용했던 파일들 모두 사용하기 위해 디스크 크기를 넉넉하게 한다.

# 디스크 크기를 너무 적게 설정하면 mount 오류로 다음과 같은 에러가 발생할 수 있다.

# -bash: /bin/ls: Input/output error

mount -t tmpfs -o size=500M none new_root2

# chroot 테스트에서 사용했던 파일들 복사해오기

cp -rv new_root/* new_root2/

# root 경로를 마운트할 디렉토리 생성

mkdir new_root2/put_old

cd new_root2

# pivot_root: change the root filesystem

# 현재 프로세스의 root 파일시스템을 put_old 로 옮기고 . 를 새로운 root 파일 시스템으로 만든다.

pivot_root . put_old

# root 파일 시스템 자체가 바뀌었음으로

# chroot 탈옥 코드로 root 경로 탈옥이 되지 않는다.

./break_chroot

# unshare 나가기

exit

pid 네임스페이스에 관한 이슈와 해결책

[들어 가기전]

고아(orphan) process : 부모 프로세스가 자식 프로세스보다 먼저 종료되면, 자식 프로세스는 고아 프로세스가 된다. 고아 프로세스는 init(pid 1)에서 거둬 들여, 고아의 부모 프로세스는 init(pid 1)이 된다. 고아 프로세스가 종료되면 init 이 종료 상태를 파악해 좀비 프로세스가 되는것을 막는다.

좀비(zombie/defunct) process : 자식 프로세스는 종료되었지만 부모 프로세스가 wait()등으로 자식 프로세스의 종료 상태를 파악하지 못해 자식 프로세스를 거둬 드릴 수 없는 경우로 process table 에만 남아 있어 kill -9 좀비프로세스PID 로도 삭제되지 않는다.

좀비 프로세스를 삭제 방법

- kill -CHLD PPID (부모 프로세스가 CHLD 시그널을 처리할 수 있는 경우에만 가능)

- kill -KILL PPID (좀비 프로세스의 부모프로세스를 제거한다. 모든 child 가 죽기 때문에 신중해야함)

pid 네임스페이스에 관한 이슈와 해결책을 보고 정리해 봤다

출처 : https://hackernoon.com/the-curious-case-of-pid-namespaces-1ce86b6bc900

!!! Caution 잘못된 번역이나 이해로 틀릴 수 있음!!! ^^;;

[linux 의 pid(process identifier)]

user space 의 root 프로세스는 init (pid 1, 이것의 부모는 pid 0 으로 커널)이다.

1 번 프로세스가 죽으면 커널이 패닉을 발생해 시스템을 재부팅해야 한다.

[linux namespace 생성]

리눅스 네임스페이스들(uts(host, domain 구분), network, mount, ipc, cgroup(cpu,memory,disk,network 등 리소스 구분), pid)는 unshare 시스템콜로 생성한다. unshare 하면 바로 새로운 네임스페이스로 들어간다.

하지만 pid 네임스페이스의 경우 unshare 로 바로 pid 네임스페이스로 들어가지 않고, fork 로 pid 네임스페이스에 pid 1(init)번를� 만든다. 이 1번 프로세스는 pid 네임스페이스 밖(호스트)에서는 다른 pid 값이다.

[네임스페이스에서의 pid 1]

1. pid 네임스페이스의 init 프로세스는 기본 signal 핸들러가 없어, HUP, INT, QUIT, TERM, KILL .. 등의 시그널 처리를 하지 못한다.(별다른 옵션 없이 docker 컨테이너를 수행하면 ctrl-c 가 동작하지 않는다. 그래서 docker kill 등을 사용한다.)

2. pid 네임스페이스의 init 외 다른 프로세스가 자식 프로세스보다 먼저 죽으면 그 자식 프로세스의 부모는 init (pid 1)이 되고, init 은 프로세스들이 exit 상태를 수집해 커널이 process table 에서 정리할 수 있도록 한다.

3. pid 네임스페이스의 init(pid 1)이 죽으면, 같은 네임스페이스의 모든 프로세스가 강제로 제거되며, pid 네임스페이스는 clean up 된다.

[docker 의 실수]

docker(runc:lightweight docker runtime)는 컨테이너의 entrypoint 를 pid 1 로 하는 새로운 pid 네임스페이스를 만든다. pid 1번에서 signal 처리가 되어 있지 않으면 ctrl-c 와 같은 signal 이 동작하지 않는다. 손자 프로세스가 종료(exit)되기 전에 죽은 자식 프로세스를 fork 하게 되면 zombie(좀비) 프로세스가 컨테이너에 쌓이게 되고, 결국 process table 을 꽉 채우게되는 상황이 발생할 수 있다.

이런 문제를 피하기 위해 fork-exec 를 할 수 있는 특별할 application process 를 실행할 수 있다. 이는 컨테이너가 복잡해지지만 실제 호스트(컨테이너가 아닌)의 init 처럼 만들 수 있다. 사람들은 종속성 격리의 이점을 희생하더라도 여러개의 apt 를 실행(dockerfile 에서 apt install a b c 컨테이너 내에서 패키지를 설치)을 포함시키는 경향이 있다.

[Rkt 해결책]

Rkt(rkt is an application container engine) 로 위 문제를 다소 해결할 수 있다. Rkt 는 사용자가 만든 시작 프로세스(container process)가 init 이 아니라고 가정하고 init (systemd) 를 생성하고 systemd 로 컨테이너에서 동작하는 filesystem 네임스페이스를 만들고 구동시킨다. systemd 는 pid 1번이 되고, (사용자가 만든) container process 는 pid 2번으로 동작한다. 만약 container process 가 init 이라면 이것도 pid 2 로 동작해 또 다른 이슈가 될 수 있다.

[간단한 대체 방법]

fork 후 pid 네임스페이스에서 container process 를 바로 실행하는 대신, spawner 가 다시 fork 한다. 이 두번째 fork 는 container spawner 가 pid 1이 되도록 하고, 모든 child 프로세스들에 signal을 전달할 수 있는 signal handler 를 구성한다. 이렇게 하면 child 프로세스가 죽을때 까지 좀비 프로세스를 거둬들일 수 있고, 이 시점에 container process 의 종료 상태를 수집해 컨테이너화 시스템에 전달한다. 이것은 ctrl-c 와 같은 signal 을 처리할 수 있고 zombie 프로세스도 적절히 거둬들 수 있다는 의미다.

docker 1.13 부터 가능하며 --init 플래그를 사용하면 된다.

[하나의 pod 내에서의 다중 컨테이너]

pod 는 네임스페이스를 공유 하는 컨테이너들의 집합이다. rkt 에서는 파일시스템 네임스페이스를 제외한 모든 네임스페이스들이 공유된다.

앞서 pid 네임스페이스 이슈로 kubernetes(k8s) 는 pod 내 컨테이너들간에 pid 네임스페이스를 공유 하지 않는다. 때문에 같은 pod 내의 container 들 끼리 signal 주고 받을 수 없고, 앞서 언급한 init 문제를 가지고 있어 container processor 는 pid 1로 실행된다.

rkt 방법을 사용하면 컨테이너 안에 init 프로세스를 만들지 않아도 통신이나 signal 을 주고받을 수 있는 컨테이너들을 쉽게 생성할 수 있다. 하지만 이미 존재하는 pod 에 컨테이너를 추가하는 상황에서는 바로 되지는 않는다.

[pod 에 컨테이너 추가하기]

k8s 는 pod sandbox 라는 개념이 있다. k8s 컨테이너 런타임은 컨테이너 시작에 앞서 리소스를 할당하는데, 이는 특히 네트워킹에 유용하고 존재하는 pod 에 컨테이너를 추가하는데도 적용할 수 있다. sandbox pod 를 먼저 생성 후 컨테이너를 하나씩 추가하는 경우, 왜 나중에 컨테이너 추가하는게 허용되지 않을까? 이는 데이터베이스 백업이나 로그 수집과 같은 주기적인 작업에 특히 유용할 것이다.

rkt(에서는 container 를 app 으로 부른다.)는 실험적으로 컨테이너와 독립적으로 pod 생성을 허용하여, 추후에라도 pod 에서 컨테이너를 추가,삭제할 수 있다. 별도 실행되는 유닛(프로세스?)없이 systemd 로 가능하게 한다. 새로운 app(container) 시작 요청이 있으면 pod 의 systemd 와 통신한다. 이러한 모델로 init 프로세스는 다음과 같은 추가적인 특권(privilege)을 가진다.

- 호스트 파일시스템 네임스페이스에 접근할 수 있어서 컨테이너 시작을 위한 파일시스템 네임스페이스를 생성할 수 있다.

- 각 app 시작에 필요한 privilege 들을 알 수 없어 전체 privilege 을 유지해야 한다.

- 컨테이너상의 모든 실행중인 프로세스를 볼 수 있다.

non-sandbox 모델이라면 init 프로세스는 child 프로세스를 시작한 다음 compromise 영향을 최소화 하기 위해 privilege 를 삭제한다.

[sandboxes 와 pid namespaces]

init, sandboxes, pid namespace 를 이용한 방법들 각각 약간의 결점(단점)이 있고, 다음 옵션을 사용할 수 있다.

1. pid namespace 가 sandbox 와 같이 생성되지 않을때, 각 컨테이너는 자신의만의 pid 네임스페이스를 가진다. k8s 에서 사용하는 방식이며, signal 처리를 위한 간단한 init 전략이다. 중요 단점으로는 pod 내 프로세스들간 signal 을 통신을 할 수 없다.

2. pid namespace 가 sandbox 와 같이 생성되지 않을때, sandbox 에서 처음으로 시작되는 컨테이너에 pid namespace 가 생성된다. 이 상태에서는 프로세스간 signal을 주고 받을 수 있다. 단점은 첫번째 프로세스가 pod 의 master 가 되고 이 master 프로세스가 죽으면 컨테이너 내 모든 프로세스는 커널에 의해 종료된다. 때문에 master 프로세스는 pod lifecycle 동안 살아 있어야 한다.

3. pid namespace 가 sandbox와 함께 생성될때, 다른 프로세스를 실행할 수 있는 smart init 프로세스를 포함한다. 이것은 rkt app sandbox 가 동작하는 방식이다. 단점으로는 init 프로세스가 너무 많은 privilege 를 가져 그 만큼 보안 공격에 취약할 수 있다.

4. pid namespace 가 sandbox와 함께 생성될때, sandbox 는 signal을 처리하고 zombie 프로세스를 회수하는 간단한 init 프로세스를 포함한다. 다른 프로세스들은 pid namespace 로 들어갈 수 있지만 부모 프로세스들은 네임스페이스 밖에 있다. init 프로세스는 새로운 컨테이너를 시작하지 않기 때문에, privilege 나 호스트 파일시스템 액세스를 유지할 필요가 없다. 단점은 네임스페이스 내의 각 프로세스들은 pid 0인 부모를 가져 일반적인 process tree 가 깨진다.

5. pid namespace 와 init 이 정확히 위 4번 옵션과 같을때, 다른 프로세스들은 pid namespace 에 들어가고 daemonize 된다. 커널은 위 4번에 pid 0으로 깨진 process tree 에서의 부모를 init 으로 돌릴 것이다. 단점은 daemonize 후 밖에 있는 새로운 프로세스를 모니터링 하기 어렵다. containerizationo system 은 간단하게 프로세스를 waiting 하는 대신 pid 를 통해 프로세스를 추적하도록 강요된다.

(필자는) 위 옵션 중 4번, 5번을 선호한다. 사실 기대하는 프로세스의 lifetime 에 따라 하나를 선택하면 된다. 위 옵션들은 프로세스를 오래 실행하기 위한 좋은 방법들이고 특히 프로세스를 spawner 로 daemonize 프로세스를 종료하는 docker 환경에 좋은 솔루션이다. 만약 간단하게 끝나는 프로세스라면 4번 옵션을 사용하고 프로세스를 pid process tree 와 분리해 유지하면 아주 쉽다. 

어떤 작업들은 k8s 가 init 처럼 동작하는 pause container를 생성하는것과 비슷하다. k8s 에 pid namespace 공유가 지원되면 5번 옵션도 가능할것이다.

[결론]

pid namespace 에는 꽤 숨겨진 복잡도가 존재한다. 오늘날 containerization 시스템은 중요한 단점과 이걸 피할 수 있는 방법들에 따라 선택한다. docker 의 싱글 컨테이너의 단점은 잘 이해되고 적당한 해결방법이 있는 반면, 컨테이너 spawner 가 init 처럼 동작하게 허용되면 컨테이너 빌더 작업이 단순화된다.

그룹 컨테이너의 경우 init 분리 방식이 rkt 가 docker 보다 우수하다. rkt 방식은 현재 k8s pod 모델에서 가능하지 않는 signal 을 통한 프로세스간 통신을 허용한다. 하지만 지연된 시작 컨테이너가 포함되기 때문에 rkt 방식도 몇가지 단점을 보인다.

지연된 시작 컨테이너에 가장 강력한 해결 방법은 pid namespace 와 함께 간단한 init 프로세스를 시작하는것이다. 하지만 새로운 컨테이너를 생성하려면 container spawner 를 통해야 한다. 이는 init 프로세스가 privileges 삭제를 허용하여, 공격을 차단한다. spawner 는 새 프로세스를 daemonize 하고 process tree 를 일관되게 유지하거나 새 프로세스의 부모로 남아 프로세스 관리를 단순화할 수 있다.

linux ip iptables 사용하기

# linux 에서 자주 사용되는 ip 명령 예제들

# 참고로 다음과 같이 각 명령에 대한 도움말을 볼 수 있다.

ip addr help 

ip link help 

# 네트워크 장치�ipv4, ipv6 주소 정보

ip addr

# ip 주소할당, dev(device)로 eth0 를 사용

ip addr add 10.10.10.2/24 dev eth0

# ip 주소 삭제

ip addr add 10.10.10.10/24 dev eth0

ip addr delete 10.10.10.10/24 dev eth0

# 장치별 링크 정보 

ip link

# 라우터 정보

ip route

# 연결된 이웃 장치 정보

ip neighbor

##### 네트워크 네임스페이스 구분해서 통신하기 #####

# veth(virtual Ethernet devices) 타입으로

# lemon_eth0 apple_eth0 를 생성하고 연결한다.

ip link add lemon_eth0 type veth peer name apple_eth0

# namespace 확인

ip netns

# LEMON namespace(네트워크가 호스트 네트워크와 격리됨) 생성

# /var/run/netns/LEMON 파일이 생성된다.

ip netns add LEMON

ip netns add APPLE

# lemon_eth0 의 네임스페이스를 LEMON 으로 설정

ip link set lemon_eth0 netns LEMON

ip link set apple_eth0 netns APPLE

# LEMON 네임스페이스에 접속해서 lemon_eth0 장치 시작하기 

ip netns exec LEMON ip link set lemon_eth0 up

ip netns exec APPLE ip link set apple_eth0 up

# LEMON 네임스페이스에 접속해서 lemon_eth0 장치에 ip 설정하기

ip netns exec LEMON ip addr add 10.10.10.2/24 dev lemon_eth0

ip netns exec APPLE ip addr add 10.10.10.3/24 dev apple_eth0

# APPLE apple_eth0 의 패킷을 모니터링 하고

ip netns exec APPLE tcpdump -l -i apple_eth0

# LEMON(lemon_eth0) --> APPLE(apple_eth0) 로 핑을 보내 확인 할 수 있다.

ip netns exec LEMON ping 10.10.10.3

# 참고로 매번 네임스페이스 exec 를 명시하지 않고,

# nsenter 명령으로 네임스페이스 들어가 있을 수 있다.

# 들어간 네임스페이스에 exit 를 하면 빠져나온다.

nsenter --net=/var/run/netns/LEMON

ping 10.10.10.3

# 통신시 ARP 로 매번 브로드캐스팅은 비효율적이라 캐싱하게 된다.

# LEMON 네임스페이스 상에서 이웃을 조회하면 10.10.10.3(apple_eth0)가 캐싱되있다.

ip neighbor

# 현재 네임스페이스를 빠져나온다.(호스트(루트) 네임스페이스로 이동)

exit

# 이제 LEMON, APPLE 네임스페이스 삭제하면 LEMON, BLUE 네임스페이스 안의 이더넷도 모두 삭제된다.

ip netns del LEMON

ip netns del APPLE

##### iptables(netfilter) 설정하기 #####

# iptables 은 커널의 netfilter(프레임워크)에 rules를 설정하고 실제로는 netfilter 로 방화벽 기능이 동작한다.

# netfilter 는 다음 5개의 chain 을 hook 하고 룰에 따라 패킷을 필터링한다.

# 참고 https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture

# PREROUTING: 외부로부터 들어오는 패킷

# INPUT: PREROUTING -> 로컬에서 받아야 하는 패킷

# FORWARD: PREROUTING -> FORWARD -> POSTROUTING 으로 로컬을 거치지 않고 외부로 부터 들어온 패킷을 다른 외부로 가야하는 패킷

# OUTPUT: 로컬 -> POSTROUTING 으로 로컬에서 외부로 가는 패킷

# POSTROUTING: FORWARD 또는 로컬에서 외부로 나가야하는 패킷

# 각 chain 에 맞는 다음과 같은 성격의 룰 테이블이 있다.

# filter:  패킷 필터링에 사용하는 테이블, INTPUT,FORWARD,OUTPUT 에서 사용

# nat: 출발지, 목적지 변경시 사용하는 테이블, PREROUTING,POSTROUTING 에서 사용

# mangle: 패킷 변조시 사용하는 테이블�, 5개 chain 모두에서 사용

# raw: 주로 netfilter 에서 추적하지 않도록 NOTRACK 설정하는데 사용하는 테이블, PREROUTING,OUTPUT 에서 사용

# security: SELinux 보안 사용시 사용하는 테이블, INPUT,FORWARD,OUTPUT 에서 사용

# filter 테이블 -S(list-rules) 룰 리스트 보기

iptables -t filter -S 

# -t 명시하지 않으면 filter 가 기본값이다.

iptables -S

# FOWARD chain에 설정된 rule들 보기 -v(가 없으면 in,out 이더넷 장치가 보인다) 

iptables -L FORWARD -v

iptables -L INPUT -v

# 10.10.10.3 으로 부터 들어오는(INPUT chain) -j(--jump) DROP(패킷 차단) 룰 추가(-A, --append)

iptables -A INPUT -s 10.10.10.3/32 -j DROP

# 10.10.10.3 으로 부터 들어오는(INPUT chain) -j(--jump) ACCEPT(패킷 허용) 룰 추가(-A, --append)

iptables -A INPUT -s 10.10.10.3/32 -j ACCEPT

# 룰 삭제(-D, --delete)

iptables -D INPUT -s 10.10.10.3/32 -j ACCEPT

# -A 같은 내용의 룰이 계속 추가 되 때문에

# -D 같은 내용이라도 마지막 룰만 삭제되어 모두 삭제하려면 N번 실행해야 한다.

# 외부(인터넷) 통신을 위해서는

# POSTROUTING 에 nat 추가

iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j MASQUERADE

# 패킷을 내 사설IP 에서 받을 수 있도록 -d(--destination) 허용

iptables -t filter -A FORWARD -d 10.10.10.3/24 -j ACCEPT

# nat 설정 상태 확인

iptables -t nat -S