[Kubernetes Advanced Networking Study] 컨테이너 격리 & 네트워크 및 보안_2

CloudNet@ 가시다님이 진행하는 Kubernetes Advanced Networking Study 1주차 정리입니다.

 

▶ 도커 없이 컨테이너 만들기 4 : 자원 관리, Cgroups

• Cgroups, Control Groups
• 컨테이너 별로 자원을 분배하고 limit 내에서 운용
• 하나 또는 복수의 장치를 묶어서 그룹
• 프로세스가 사용하는 리소스 통제

https://wizardzines.com/comics/cgroups/

https://wizardzines.com/comics/cgroups/

 

• 프로세스는 실행 중인 프로그램의 인스턴스를 의미. OS에서 프로세스를 관리하며, 각 프로세스는 고유한 ID(PID) 를 가짐
• 프로세스는 CPU와 메모리를 사용하는 기본 단위로, OS 커널(cgroup)에서 각 프로세스의 자원을 관리
• Control groups : 프로세스들의 자원의 사용(CPU, 메모리, 디스크, 입출력, 네트워크 등)을 제한, 격리시키는 리눅스 커널 기능

• 하나 또는 복수의 장치를 묶어서 하나의 그룹을 만들 수 있으며 개별 그룹은 시스템에서 설정한 값만큼 하드웨어를 사용
• 시스템의 프로세스들은 장치별로 특정한 cgroup에 속하여 프로세스가 사용하는 하드웨어 자원의 총량에 제한을 받음
• process를 계층적인 group으로 구성해서, resource 사용을 제한하고 모니터링할 수 있는 linux kernel feature
• cgroup의 interface는 cgroupfs이라 불리는 pseudo-filesystem을 통해 제공
• cgroupfs의 subdirectory를 생성/삭제/변경하면서 정의됨

 

부하 발생 확인

 

▶ [심화] Container 자원 제한 설정 : Memory, CPU

1. Container는 기본으로 호스트의 자원을 제한 없이 쓸수 있다. 자원 할당 제한 명령 확인

2. Container Memory 사용 제한 : --memory로 메모리 제한. m(megabyte), g(gigabyte) 단위, 제한할 수 있는 최소 메모리는 6MB

 

3. Container CPU 사용 제한 : cpu-shares, cpuset-cpus, CFS(cpu-period, cpu-quota, cpus), Realtime(rt-period, rt-runtime)

1) cpu-shares : 호스트 CPU의 사이클을 해당 컨테이너가 상대적으로 얼마나 사용할 수 있는지에 대한 비중

2) cpuset-cpus : 호스트 CPU가 여러개 일 때, 컨테이너가 특정 CPU를 사용할 수 있게 지정

3) cpu-period + cpu-quota, cpus : CFS 스케줄러 기반 CPU 시간 할당 제한, cpu-period/quota 보다 cpu-quota 사용을 권장

• CFS scheduler : 기본 CPU 스케줄러, The CFS is the Linux kernel CPU scheduler for normal Linux processes. Serveral runtime falgs let you configure the amount of access to CPU resources your container has. When you use these settings, Docker modifies the settings for the container's cgroup on the host machine.
• cpu-period : Specify the CPU CFS scheduler period, which is used alongside --cpu-quota. Defaults to 100000 microseconds (100 milliseconds). Most users don't change this from the default. For most use-cases, --cpus is a more convenient alternative.
• cpu-quota : Impose a CPU CFS quota on the container. The number of microseconds per --cpu-period that the container is limited to before throttled. As such acting as the effective ceiling. For most use-cases, --cpus is a more convenient alternative.
• cpus : Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set --cpus ="1.5", the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting --cpu-period="100000" and --cpu-quota="150000".

4. rt-period + rt-runtime : Realtime 스케줄러 기반 CPU 시간 할당 제한

• Realtime scheduler : You can configure your container to use the real-time scheduler, for tasks which cant' use the CFS scheduler. You need to make sure the host machine's kernel is configured correctly before you can configure the Docker daemon or configure individual containers.
• cpu-rt-period : Limit the CPU real-time period. In microseconds. Requires parent cgroups be set and cannot be higher than parent. Also check rtprio ulimits.
• cpu-rt-runtime : Limit the CPU real-time runtime. In microseconds. Requires parent cgroups be set and cannot be higher than parent. Also check rtprio ulimits.

컨테이너 네트워크 & IPTables

1. 도커 없이 네트워크 네임스페이스 환경에서 통신 구성

1.1 RED <> BLUE 네트워크 네임스페이스 간 통신

결론 : 네트워크 네임스페이스 생성 시 호스트 네트워크와 구별된다

( veth에서 v는 virtual을 뜻 합니다. 즉 virtual ethernet 이라는 의미 입니다.)

 

 

 

 

: 격리가 된 상태로 RED, BLUE에서는 각자 자신의 route table만 확인

 

ping 통신 확인

 

 

1.2 RED <- Bridge(br0) -> BLUE 간 통신

 

 

 

▶ Red -> Blue ping failed 분석
IPtables : Basic firewall software
- Interacting with the packet filtering hooks in the kernel's network stack

Netfilter : These kernel hooks are known as the netfilter framework
▶ 5 hooks : INPUT, OUTPUT, PREROUTING, FORWARD, POSTROUTING

 

▶ Chain & Table

• Chain : INPUT - mangle, filter
• Chain : OUTPUT - mangle, nat, filter
• Chain : FORWARD - mangle, filter
• Chain : PREROUTING - mangle, nat
• Chain : POSTROUTING - mangle, nat
• Table
  - Filter : 필터링, 패킷 전송 여부
  - NAT : Network Address Translation. src/dst. 주소의 수정/방법 여부 결정
  - Mangle : 헤더 변조(TTL 조정, 홉 수 조정). 추가 처리를 위한 커널 마킹
  - Raw : connection tracking을 위한 패킷마킹 메커니즘 제공
  - Security : 패킷에 SELinux(보안) context 마

▶ Netfilter과 IPtables
패킷은 netfilter(일종의 백엔드)에서 파놓은 여러 hook을 통과하는데 hook 별로 iptables에서 정의한 각 체인룰을 점검

• iptables(일종의 프런트엔드 혹은 애플리케이션) : Netfilter가 파놓은 hook에 룰을 등록하고 관리하는 방법을 제공하는 툴
• 실제 iptables은 방화벽의 역할처럼 패킷을 차단, 허용하는 등의 필터링 기능을 수행하는 것은 아니며 리눅스 커널에 내장된 netfilter라는 리눅스 커널 모듈을 통해 실제로 필터링이 동작합니다. iptables는 netfilter를 이용할 수 있도록 해주는 사용자 공간 응용 프로그램(User-Spac-Application) 입니다.
• hook에 정의된 체인은 테이블 순서대로 등록된 룰을 체크하고 조건을 만족하면 action(target)을 트리거.
  - table : 목적/용도별 rules 모음 -> 예) filter, nat, mangle..
  - chain : 패킷이 지나가는 hook 별로 존재 -> 예) PREROUTING, FORWARD, INPUT .. (netfilter의 hook에 매핑)
  - rule : table과 chain matrix에 대해서 정의 -> 예)protocol type, dest/src.address, headers..
  - action(target) : 패킷이 룰에 매칭되면 트리거됨 -> 예)ACCEPT, DROP, REJECT ..

 

허용 정책 추가 후 ping 정상 통신 확인

 

 

 

1.3. RED/BLUD -> 호스트 & 외부(인터넷) 통신

 

 

* iptables_conntrack Module??

: conntrack 이란 iptables의 상태추적 모듈로 NAT 테이블, FTP 등과 관련이 있는 모듈로, 

현재 접속 상태에 대한 정보를 일정 시간 동안 시스템에 기억하도록 해주는 모듈.

 

• 상태 기반 정책 설정 시 사용하는 상태(state)
  - NEW : 새로운 접속을 만드는 패킷
  - ESTABLISHED : 존재하는 접속에 속하는 패킷 (응답 패킷을 가졌던)
  - RELATED : 기존의 접속의 부분은 아니지만 연관성을 가진 패킷, ICMP 에러 또는 FTP 데이터 접속을 형성하는 패킷
  - INVALID : 어떤 이유로 확인할 수 없는 패 

 

2.0. 도커 네트워크 모드

▶ 기본 네트워크 모드 : Bridge, Host, None + 추가 네트워크 플러그인 : macvlan, ipvlan, overlay

• Host는 호스트의 환경을 그래도 사용. 애플리케이션 별도 포트 포워딩 없이 바로 서비스 간으. 컨테이너의 호스트 이름도 호스트 머신의 이름과 동일
• None는 말 그대로 아무런 네트워크를 쓰지 않는 것. 외부와의 연결이 단절됨. 컨테이너 내부에 lo 인터페이스만 존재

 

2.1 Bridge 모드

▶ Bride 모드 기본 정보 확인

• 도커에서 기본적으로 쓸 수 있는 네트워크 확인, 컨테이너 기본 생성 시 자동으로 docker0브리지를 사용
• 기본 172.17.0.0/16 대역을 컨테이너가 사용, 대역 변경 설정 가능
• 도커는 IPtables의 PREROUTING POSTROUTING의 NAT Chains를 변경
  - 컨테이너 -> 외부 : POSTROUTING의 SNAT 처리
  - 외부 -> 컨테이너(Exposed services ports) : PREROUTING에서 DNAT 처리

▶ 컨테이너(busybox) 2대 생성

 

▶  도커 호스트가 다수 일 때, 컨테이너들 끼리 직접 통신을 하기 위해서는 네트워크 대역이 중복되지 않게 설정해야 되고 overlay 혹은 직접 라우팅이 가능하게 설정 등이 필요합니다.
이런 부분을 쿠버네티스에서는 CNI(Network Interface) 플러그인 (예. calico 등)이 처리하게 됩니다.

 

2.2. Host 모드

▶ 호스트의 환경을 그대로 사용 가능. 호스트 드라이버의 네트워크는 별도로 생성할 필요 없이 기존의 host 라는 이름의 네트워크를 사용

• 컨테이너의 호스트 이름도 호스트 머신의 이름과 동일. 네트워크도 동일. 애플리케이션 별도 포트 포워딩 없이 바로 서비스 할 수 있음.

2.3. 컨테이너 외부에 노출

▶  설정 및 확인 : bridge mode

보안

▶ 보안 가이드 : 2019년, SK Infosec 클라우드 보안 가이드 (컨테이너 보안)

구분	항목코드	항목명
Docker Configuration	1-1	호스트 OS 주요 자원 접근 제어
	1-2	인증-권한 제어
	1-3	SSL/TLS 적용
	1-4	네임스페이스 관리
	1-5	컨테이너 네트워크 제어
	1-6	컨테이너 리소스 제어
	1-7	컨테이너 권한 제어
	1-8	컨테이너 보안 정책
	1-9	로그 관리
호스트 OS	2-1	설정 파일 및 주요 디렉터리 권한 설정
	2-2	audit 설정
이미지	3-1	Dockerfile Config
	3-2	이미지 취약점 및 구성 결함
	3-3	레지스트리 운영 관리
Docker Swarm	4-1	인증 제어
	4-2	SSL/TLS 적용
	4-3	네트워크 제어
기타	5-1	중요도 수준에 따른 격리 운영
	5-2	앱 취약점
	5-3	보안 패치 적용

 

 

▶ Sysbox 소개 : Sysbox is an open-source and free container runtime (a specialized "runc")

• 2가지 주요 기능 제공
  1) 컨테이너 격리 강화 - Improves container isolation :
  - Linux user0namespace on all containers (i.e., root user in the container has zero privileges on the host).
  - Virtualizes portions of procfs & sysfs inside the container.
  - Hides host info inside the container.
  - Locks the container's initial mounts, and more
  2) 최대한 VM과 유사한 환경을 제공 - Enables containers to run same workloads as VMs :
  - With Sysbox, containers can run system-level software such as systemd, Docker, Kubernetes, K3s, buildx, legacy apps, and more seamlessly & securely.
  - This software can run inside Sysbox containers without modification and without using special versions of the software
  - No privileged containers, no complex images, no tricy entrypointrs, no special volume mounts, etc.
• Sysbox solves problems such as 해결 가능한 문제들
  - Enhancing the isolation of containererized microservices (root in the container maps to an unprivileged user on the host).
  - Enabling a highly capable root user inside the conatiner without compromising host securiy.
  - Securing Ci/CD pipelines by enabling Docker-in-Docker (DinD) or Kubernetes-in-Docker (KinD) without insecure privileged containers or host Docker socket mount.
  - Enabling the use of containers as "VM-like" environments for development, local testing, learning, etc., with strong isolation and the ability to run systemd, Docker, IDEs, and more inside the container.
  - Running legacy apps inside containers (instead of less efficient VMs)
  - Replacing VMs with an easier, faster, more efficient, and more portable container-based alternative, one that can be deployed across cloud environments easily.
  - Partitioning bare-metal hosts into multiple isolated compute environments with 2X the density of VMs (i.e. deploy twice as many VM-like containers as VMs on the same hardware at the same performance).
  - Partitioning cloud isntance into multiple isolated compute environments without resorting to expensive nested virtualizaion.
  
  
• How it Works 동작
  - Sysbox installs easily on Linux hosts (bare-netal, VM, on-prem, cloud.. ) It works on all mayor cloud-based IaaS and Kubernetes services.
  - Once installed, Sysbox works under the covers : you use Docker, Kubernetes, etc. to deploy containers with it.
  - You get a well isolated container capable of seamlessly running microservices as well as system-level software that normally that runs on VMs