[AWS EKS] 클러스터 보안그룹 vs 추가 보안그룹 (Cluster SG vs Additional SG)

공부/AWS

[AWS EKS] 클러스터 보안그룹 vs 추가 보안그룹 (Cluster SG vs Additional SG)

haejang 2024. 4. 28. 13:00

728x90

# 결론

클러스터 보안그룹과 추가 보안그룹은 다르다.

클러스터 보안그룹 (EKS 생성 시 자동 생성되며, self rule도 자동으로 생성되어 있음) 은 eks api로 만든 컴퓨팅 리소스 (fargate, managed ec2 node group) 들에 적용된다.

즉,

컨트롤플레인의 cross-eni : 클러스터 보안그룹 & 추가 보안그룹 사용
fargate, managed node group 노드 : 클러스터 보안그룹 사용
자체 런치템플릿 사용한 managed node group, self managed 노드 : 커스텀 보안그룹 사용 (내가 지정하는걸로)

# 일단 용어정리

클러스터 보안그룹 : eks 클러스터 생성 시 자동으로 생성되는 "Cluster security group"
추가 보안그룹 : eks 클러스터 생성 시 추가할 수 있는, 내가 생성하고 관리하는 "Additional security groups"

# 어쩌다가 이걸 보고 있었나

나는 지금까지 클러스터 보안그룹과 추가 보안그룹이 다른 역할을 하는 것이라고 생각하지 않고 있었다.

그저..셀프 룰이 필수로 박혀있는 보안그룹이 하나 제공되고, 추가적으로 내가 좀 커스텀할 수 있는 보안그룹을 따로 넣을 수 있게 해주는 것이라고만 생각했다.

그래서 지금까지 eks 테라폼 모듈에서 클러스터용 / 노드용 자체 보안그룹을 따로 만들고, 그 친구들끼리만 서로 통신 가능하게 만들어 두었었다.

즉, 클러스터 보안그룹의 룰은 건드리지 않은 채, 추가 보안그룹 <-> 자체 노드 보안그룹 사이 통신만 뚫어두었던 것.

이번에 coredns를 karpenter -> fargate로 바꾸는 작업을 하고 있었는데, (이 작업에 대한 내용은 다른 글에서..)

coredns가 fargate로 뜨니까 다른 파드들이 coredns를 찾지 못하는 것이었다.

근데 어쩌다가 클러스터 보안그룹에서 자체 노드 보안그룹을 허용해줘봤는데, 통신이 되었다...

-> 클러스터 보안그룹과 추가 보안그룹의 역할이 다르다는 것을 인지 후 aws support에 문의를 올려보았다.

굉장히 친절하고 자세한 답을 받을 수 있었는데, 요약하자면 아래와 같다.

1. eks cluster 생성 시, 컨트롤 플레인 리소스들은 aws 소유의 영역에서 작동한다. -> 내 vpc와 통신하기 위해, 서브넷에 cross-eni 라는 네트워크 인터페이스를 2~4개 생성하게 된다. -> 이 네트워크 인터페이스들은 클러스터 보안그룹 & 추가 보안그룹 둘 다 사용

2. eks on fargate 또한 마찬가지로 aws 소유의 영역에서 작동하는 리소스이며, 내 vpc와 통신하기 위해 eni가 생성된다. -> 이 네트워크 인터페이스는 클러스터 보안그룹만 사용한다.

즉, 내 커스텀 노드 보안그룹을 사용하는 카펜터 노드들에서 fargate에 떠있는 coredns를 찌르기 위해선 노드 보안그룹 > 클러스터 보안그룹 통신이 뚫려야 한다는 것.

# 알고 나니 보이는 것

eks console > Networking > Cluster security gruop Info 를 눌러보면 설명이 나온다.

클러스터 보안그룹은 컨트롤플레인과, "EKS API를 통해 생성된 컴퓨팅 리소스"에서 쓰인다는 것.

(이렇게 어렵게 써놓으면 내가 어떻게 아냐!)

그리고 생각해보니, fargate profile을 생성할 땐 보안그룹을 설정한 적이 없다. 나는 왜 자연스럽게 fargate node도 내가 만든 노드 보안그룹을 쓴다고 생각했을까... 싶다. ㅋㅋ

그리고 fargate eni를 직접 확인해보니, 클러스터 보안그룹을 쓰고 있더라.

# 추가 이것저것 확인

아무튼 클러스터 보안그룹이 사실은 매니지드 노드에서 사용되는 보안그룹이란 것을 알고, 이것저것 더 확인해보았다.

난 카펜터 쓰기 전까지는 자체 런치템플릿을 사용한 매니지드 노드그룹을 사용해왔었는데, 그 친구들은 클러스터 보안그룹을 사용하지 않았던 것으로 기억했다. 그래서 "어느 매니지드 정도"까지 클러스터 보안그룹을 사용하는지 테스트해 보았다.

우선 매니지드 노드그룹을 만드는 방법은 3가지가 있다.

(참조 - https://kim-dragon.tistory.com/54 )

위 글에 있는 3가지 방법은 아래와 같다.

1. 그냥 쌩 매니지드 노드그룹 만들기 - 런치템플릿같은거 지정 안함 (대신 자동으로 생성됨)

2. 자체 런치템플릿을 지정한 매니지드 노드그룹 만들기 - 내가 지금까지 해온거. (런치템플릿에서 보안그룹 설정해줘야됨)

3. 자체 런치템플릿에 커스텀 ami까지

1번의 경우는 사실 처음 만들어봤다 (ㅋㅋ..) 만들어보니 진짜로 클러스터 보안그룹을 사용하는 런치템플릿과 노드 인스턴스가 만들어졌다.

2번의 경우는 이전에 만들던대로 만들어보았다.

근데 애초에 런치템플릿은 만들 때 직접 보안그룹을 지정해줘야 한다. -> 이 런치템플릿으로 만들어진 노드그룹은 해당 런치템플릿에 지정된 보안그룹을 사용하게 된다.

3번은 2번과 마찬가지일거라 테스트하지 않았다.

즉.. 1번의 경우(쌩 매니지드 노드그룹)와 fargate를 쓰는 경우에만 클러스터 보안그룹을 쓰게 된다는 것이다.

(물론 내가 런치템플릿에 클러스터 보안그룹을 넣으면 똑같이 사용되긴 하겠다)

추가로 eks 컨트롤플레인의 cross-eni도 확인해보았다.

네트워크 인터페이스 콘솔에서 "Amazon EKS <cluster name>" 이 description인 놈들을 찾으면 된다.

끝!

# Ref

728x90

저작자표시 비영리 변경금지