어플리케이션 배포시 최소 권한의 원칙을 적용한 Outbound 설정하기

강재민·2023년 3월 5일
0

Kubernetes

목록 보기
29/29


온프렘 환경 또는 클라우드 환경에서 방화벽을 강력하게 설정해놓았을 경우에는 인바운드 뿐만 아니라 아웃바운드 또한 최소한으로 설정해놓을 필요가 있습니다. 이를 위해 테스트환경에서 미리 어플리케이션을 배포하면서 최소한으로 어떤 아웃바운드를 열어야 하는지 미리 확인하고 이를 리스트업 하여 아웃바운드를 최소한으로 열어놓고 어플리케이션을 배포해보는 방법에 대해서 말씀드리려고 합니다.


테스트 환경

EC2에 KOPS 설치한 환경


Kernel IP routing table 확인하기

외부와 연결되어있는 Interface 확인하기

(repush:N/A) [root@kops-ec2 ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ip-10-0-0-1.ap- 0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
instance-data.a 0.0.0.0         255.255.255.255 UH    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

eth0으로 아웃바운드와 통신되고 있는 것을 확인할 수 있습니다.


tshark를 활용해 평상시에 사용되고 있는 IP와 port 확인하기

tshark 설치하기
yum install -y wireshark

sudo tshark -i eth0 -c 10
### eht0로 통신되는 패킷을 출력하는데 10개만 출력하라는 의미
(repush:N/A) [root@kops-ec2 ~]# sudo tshark -i eth0 -c 10
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
  1 0.000000000 39.7.231.212 -> 10.0.0.10    TCP 60 50604 > ssh [ACK] Seq=1 Ack=1 Win=511 Len=0
  2 0.509215362    10.0.0.10 -> 39.7.231.212 SSH 186 Encrypted response packet len=132
  3 0.651469740 39.7.231.212 -> 10.0.0.10    TCP 60 50604 > ssh [ACK] Seq=1 Ack=133 Win=511 Len=0
  4 1.152386801    10.0.0.10 -> 39.7.231.212 SSH 282 Encrypted response packet len=228
  5 1.241481568 39.7.231.212 -> 10.0.0.10    TCP 60 50604 > ssh [ACK] Seq=1 Ack=361 Win=510 Len=0
  6 1.481854607    10.0.0.10 -> 169.254.169.123 NTP 90 NTP Version 4, client
  7 1.482022264 169.254.169.123 -> 10.0.0.10    NTP 90 NTP Version 4, server
  8 1.732580140    10.0.0.10 -> 39.7.231.212 SSH 282 Encrypted response packet len=228
  9 1.734243209    10.0.0.10 -> 39.7.231.212 SSH 250 Encrypted response packet len=196
 10 1.831622591 39.7.231.212 -> 10.0.0.10    TCP 60 50604 > ssh [ACK] Seq=1 Ack=785 Win=508 Len=0

위 결과값을 보면 39.7.231.212 주소에서 계속해서 통신이 이뤄지는 것을 확인할 수 있습니다. 이제 이를 아래와 같이 무시하면

(repush:N/A) [root@kops-ec2 ~]# sudo tshark -i eth0 -c 10 not host 39.7.231.212
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
  1 0.000000000 02:92:9f:f7:cf:a4 -> Broadcast    ARP 42 Who has 10.0.0.10?  Tell 10.0.0.1
  2 0.000018677 02:cd:fb:e9:5f:64 -> 02:92:9f:f7:cf:a4 ARP 42 10.0.0.10 is at 02:cd:fb:e9:5f:64
  3 1.594774842    10.0.0.10 -> 211.233.40.78 NTP 90 NTP Version 4, client
  4 1.597086089 211.233.40.78 -> 10.0.0.10    NTP 90 NTP Version 4, server
  5 3.506426616    10.0.0.10 -> 3.36.253.109 NTP 90 NTP Version 4, client
  6 3.526449450 3.36.253.109 -> 10.0.0.10    NTP 90 NTP Version 4, server
  7 4.077727427    10.0.0.10 -> 121.174.142.81 NTP 90 NTP Version 4, client
  8 4.087568908 121.174.142.81 -> 10.0.0.10    NTP 90 NTP Version 4, server
  9 6.110404003    10.0.0.10 -> 80.92.66.61  NTP 90 NTP Version 4, client
 10 6.346438802  80.92.66.61 -> 10.0.0.10    NTP 90 NTP Version 4, server
10 packets captured

또 다른 사용되는 포트들을 확인할 수 있습니다. 이렇게 필터를 걸어서 최종적으로 아무 트래픽이 잡히지 않는 순간까지 반복합니다.
결과는 다음과 같습니다.

(repush:N/A) [root@kops-ec2 ~]# sudo tshark -i eth0 -c 20 -Y "not ntp and not arp and not dhcpv6 and not tcp.port == 74 and not tcp.port == 66 and not icmpv6 and not tcp" not host 39.7.231.212
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
0 packets captured

그리고 아래와같이 패킷 필터를 열어놓고

(repush:N/A) [root@kops-ec2 ~]# sudo tshark -i eth0 -Y "not ntp and not arp and not dhcpv6 and not tcp.port == 74 and no
t tcp.port == 66 and not icmpv6 and not tcp" not host 39.7.231.212
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'

원하는 작업을 시작합니다.

(repush:N/A) [root@kops-ec2 ~]# kubectl create ns gitlab
namespace/gitlab created

결과값

Capturing on 'eth0'
  3 2.191406740    10.0.0.10 -> 10.0.0.2     DNS 87 Standard query 0x4790  A api.repush.click
  4 2.191406737    10.0.0.10 -> 10.0.0.2     DNS 87 Standard query 0x75e9  AAAA api.repush.click
  5 2.226505552     10.0.0.2 -> 10.0.0.10    DNS 103 Standard query response 0x4790  A 43.201.104.199
  6 2.226709304     10.0.0.2 -> 10.0.0.10    DNS 174 Standard query response 0x75e9
(repush:N/A) [root@kops-ec2 ~]# helm repo add gitlab https://charts.gitlab.io/
"gitlab" has been added to your repositories
Capturing on 'eth0'
  3 0.000045058    10.0.0.10 -> 10.0.0.2     DNS 76 Standard query 0x4f75  AAAA charts.gitlab.io
  4 0.000047257    10.0.0.10 -> 10.0.0.2     DNS 76 Standard query 0x9e70  A charts.gitlab.io
  5 0.001175046     10.0.0.2 -> 10.0.0.10    DNS 163 Standard query response 0x4f75
  6 0.001917443     10.0.0.2 -> 10.0.0.10    DNS 92 Standard query response 0x9e70  A 35.185.44.232

이런 방식으로 어떤 IP와 통신하는지, 어떤 프로토콜을 사용하는지, 어떤 포트를 사용하는지와 DNS까지 확인할 수 있습니다.

현재는 패킷을 bastion host에서만 받고 있지만 해당 패킷 모니터링을 worker node, master node에도 열어놓고 추출해야합니다.


결론

오늘은 Gitlab쿠버네티스에 설치하는 것을 예시로 진행하였습니다. 이 밖에도 쿠버네티스 환경에 다양한 어플리케이션을 설치해야하는 상황이 있을 수 있습니다. 이럴 때마다 위 방식을 통해서 Outbound를 최소화하는게 쉽지만은 않을것으로 보입니다.

앞으로 해당 방식을 조금 더 개선해서 실제 구축사례까지 블로깅 하는걸 목표로 진행해보겠습니다.

혹시 다른 방식이 있다면 추천부탁드립니다. 감사합니다!


wireshark 사용 예제

sudo tcpdump -vvvs 1024 -l -A | egrep --line-buffered "(GET |HTTP\/|POST |HEAD )|^[A-Za-z0-9-]+: " | sed -r 's/(GET |HTTP\/|POST |HEAD )/\n\1/g'
tcpdump -i ethernet -nn -vv

### 필요시 src dst port and 등으로 덤프쓰시면됩니다
### 저장해야하면 그냥 파일로 내려서 파싱해서 보면됩니다

0개의 댓글