AWS Security Group for Pod
AWS에서 제공하는 VPC CNI 플러그인을 통해 **파드 단위로 보안 그룹(Security Group)**을 적용하는 기능은 매우 중요한 보안 및 네트워크 관리 기능입니다. 이를 통해 특정 파드가 AWS의 네트워크 보안 정책을 적용받아, 접근 제어 및 네트워크 트래픽 필터링을 할 수 있습니다. 파드에 보안 그룹이 어떻게 동작하는지 살펴보면 다음과 같은 내부 동작 원리가 있습니다.
1. ENI(Elastic Network Interface) 할당
AWS의 VPC CNI 플러그인을 사용하면, EKS 클러스터의 **노드(EC2 인스턴스)**는 하나 이상의 **ENI(Elastic Network Interface)**를 가지게 됩니다.
각 ENI는 하나 이상의 IP 주소를 가질 수 있으며, 이는 파드에 고유한 IP를 제공하는 데 사용됩니다.
ENI는 AWS에서 보안 그룹을 적용할 수 있는 네트워크 인터페이스로, ENI에 연결된 IP 주소를 통해 파드가 네트워크 트래픽을 주고받습니다.
2. 보안 그룹과 ENI의 관계
파드에 적용되는 보안 그룹은 기본적으로 ENI에 적용됩니다. 이는 EC2 인스턴스에서 적용되는 보안 그룹과 같은 방식으로 동작합니다.
ENI에 연결된 모든 파드는 ENI에 할당된 보안 그룹 규칙을 따르게 됩니다. 이 보안 그룹 규칙에 따라 허용된 IP 및 포트로의 트래픽만이 파드로 들어오거나 나갈 수 있습니다.
3. AWS의 파드별 보안 그룹 기능(AWS Security Group for Pods)
기본적으로 AWS VPC CNI 플러그인을 사용하는 경우, EC2 인스턴스에 ENI가 부착되면 해당 ENI에 하나 이상의 보안 그룹이 연결됩니다. 이때 모든 파드는 ENI에 할당된 보안 그룹을 공유하게 됩니다.
그러나 AWS는 파드별 보안 그룹(Security Groups for Pods) 기능을 통해 파드마다 서로 다른 보안 그룹을 할당할 수 있도록 지원합니다.
이 기능을 사용하면, 파드마다 독립적으로 보안 그룹을 설정할 수 있으며, 이를 통해 파드의 역할 및 기능에 따라 세분화된 네트워크 정책을 적용할 수 있습니다.
4. 파드에 보안 그룹 적용하는 과정
AWS VPC CNI 플러그인이 설치된 EKS 클러스터에서 파드가 스케줄링되면, 해당 파드는 노드의 ENI를 통해 IP 주소를 할당받습니다.
만약 파드별 보안 그룹 기능이 활성화되어 있으면, 파드를 위해 새로운 ENI가 생성되고, 해당 ENI에 특정 보안 그룹이 연결됩니다. 이때, ENI는 파드의 IP 주소를 관리하며 보안 그룹 규칙을 적용합니다.
이렇게 설정된 ENI는 파드의 네트워크 트래픽에 대한 인바운드 및 아웃바운드 규칙을 강제하며, 네트워크 트래픽이 보안 그룹 규칙에 맞는지 여부를 검사합니다.
5. 보안 그룹 동작 방식
인바운드 규칙: 특정 파드로 들어오는 트래픽에 대해 허용된 포트, 프로토콜, IP만이 파드로 전달됩니다. 예를 들어, 보안 그룹 규칙에서 파드가 특정 포트(예: 8080)에서만 트래픽을 수신하도록 허용했다면, 다른 포트로 들어오는 트래픽은 차단됩니다.
아웃바운드 규칙: 파드에서 외부로 나가는 트래픽 또한 보안 그룹 규칙에 따라 제어됩니다. 예를 들어, 파드가 외부 서비스와 통신할 때 특정 IP 및 포트로만 아웃바운드 트래픽이 허용됩니다.
이 보안 그룹은 파드 레벨에서 설정되므로, 같은 노드에 있는 다른 파드들과는 독립적으로 작동하며, 네트워크 격리가 강화됩니다.
6. 기술적 요구 사항
ENI의 한계: EC2 인스턴스의 ENI 수는 인스턴스 유형에 따라 제한이 있습니다. 예를 들어, 하나의 EC2 인스턴스는 일정 수의 ENI만 가질 수 있으며, 각 ENI당 할당 가능한 IP 수도 제한이 있습니다. 이 때문에 파드의 수에 따라 ENI의 수를 관리하는 것이 필요합니다.
VPC CNI 플러그인 버전: 파드별 보안 그룹 기능을 사용하려면 VPC CNI 플러그인이 최신 버전이어야 하며, Kubernetes와의 호환성도 확인해야 합니다.
7. 활용 사례
다중 테넌트 환경: 여러 팀이 동일한 클러스터를 사용할 때, 팀별로 파드에 별도의 보안 그룹을 설정하여 네트워크 격리를 강화할 수 있습니다.
데이터베이스 접근 제어: 민감한 데이터베이스에 접근하는 파드에만 보안 그룹을 설정하여 해당 파드들만 데이터베이스와 통신할 수 있게 할 수 있습니다.
외부 서비스 통신: 특정 파드만이 외부 API나 외부 네트워크와 통신하도록 보안 그룹을 설정하여, 외부와의 통신을 세분화할 수 있습니다.
결론
AWS에서 제공하는 파드별 보안 그룹(Security Groups for Pods) 기능을 통해 파드 단위로 보안 정책을 적용할 수 있으며, 이를 통해 세밀한 네트워크 접근 제어와 보안을 강화할 수 있습니다. 각 파드가 ENI와 연동된 보안 그룹을 통해 네트워크 트래픽을 필터링하며, AWS의 VPC 인프라 내에서 Kubernetes 워크로드의 보안을 극대화할 수 있습니다.
AWS VPC CNI (Container Network Interface)는 Amazon EKS (Elastic Kubernetes Service)에서 기본적으로 사용되는 네트워킹 플러그인입니다. 이 CNI는 Kubernetes 클러스터의 pod 네트워킹을 AWS VPC (Virtual Private Cloud) 네트워크와 통합하는 역할을 합니다. 다음은 AWS VPC CNI의 주요 특징과 작동 방식입니다:
네이티브 VPC 네트워킹:
Pod는 VPC 내의 실제 IP 주소를 할당받습니다.
이를 통해 VPC 내의 다른 AWS 서비스와 직접 통신이 가능합니다.
보안 그룹 통합:
Pod 수준에서 AWS 보안 그룹을 적용할 수 있습니다.
세분화된 네트워크 정책 구현이 가능합니다.
높은 네트워크 성능:
VPC의 네이티브 네트워킹을 사용하므로 오버레이 네트워크에 비해 성능이 우수합니다.
IP 주소 관리:
각 노드에 대해 보조 IP 주소 풀을 관리합니다.
Pod가 생성될 때 이 풀에서 IP 주소를 할당받습니다.
ENI (Elastic Network Interface) 활용:
각 노드에 여러 ENI를 연결하여 사용 가능한 IP 주소 수를 늘립니다.
프리픽스 위임 지원:
대규모 클러스터에서 IP 주소 관리를 효율적으로 할 수 있습니다.
IPv4 및 IPv6 지원:
듀얼 스택 네트워킹을 지원합니다.
커스텀 네트워킹:
사용자 정의 네트워킹 구성이 가능합니다.
자동 설정:
EKS 클러스터 생성 시 자동으로 설치 및 구성됩니다.
오픈소스:
GitHub에서 소스 코드를 확인하고 기여할 수 있습니다.
AWS VPC CNI는 AWS 환경에서 Kubernetes를 운영할 때 네트워킹을 간소화하고 AWS 서비스와의 통합을 용이하게 만듭니다. 그러나 다른 클라우드 환경이나 온-프레미스 환경에서는 사용할 수 없다는 제한이 있습니다. [{"type":"text","text":"pod 에 AWS security group 이 동작하는 내부 동작원리를 알려줄 수 있을까?"}] AWS VPC CNI에서 Pod에 Security Group을 적용하는 내부 동작 원리는 다음과 같습니다:
ENI (Elastic Network Interface) 생성:
Security Group을 적용할 Pod가 생성되면, VPC CNI는 해당 Pod를 위한 새로운 ENI를 생성합니다.
이 ENI는 Pod 전용이며, "트렁크 ENI"라고 불립니다.
Security Group 연결:
생성된 ENI에 지정된 Security Group이 연결됩니다.
Branch ENI 생성:
트렁크 ENI에서 가상의 "Branch ENI"가 생성됩니다.
이 Branch ENI는 실제로 AWS에 존재하지 않고, VPC CNI 내부에서만 관리됩니다.
IP 주소 할당:
Branch ENI에 IP 주소가 할당됩니다.
이 IP 주소는 Pod의 IP 주소가 됩니다.
네트워크 네임스페이스 설정:
Pod의 네트워크 네임스페이스에 Branch ENI가 연결됩니다.
트래픽 라우팅:
Pod에서 나가는 트래픽은 Branch ENI를 통해 트렁크 ENI로 전달됩니다.
트렁크 ENI에 연결된 Security Group 규칙에 따라 트래픽이 필터링됩니다.
인바운드 트래픽 처리:
Pod로 들어오는 트래픽도 트렁크 ENI를 통과하며, 여기서 Security Group 규칙이 적용됩니다.
CNI 데몬 관리:
VPC CNI 데몬이 지속적으로 Pod, ENI, IP 주소, Security Group 간의 매핑을 관리합니다.
동적 업데이트:
Pod의 수명 주기 동안 Security Group 규칙이 변경되면, 트렁크 ENI에 연결된 Security Group이 업데이트됩니다.
리소스 정리:
Pod가 종료되면, 관련된 Branch ENI가 제거되고, 필요 없어진 트렁크 ENI도 삭제됩니다.
이 방식을 통해 AWS VPC CNI는 Pod 레벨에서 Security Group을 적용할 수 있으며, 이는 기존 EC2 인스턴스에 Security Group을 적용하는 것과 유사한 수준의 네트워크 보안을 제공합니다. 이 기능은 특히 마이크로서비스 아키텍처에서 세분화된 보안 정책을 구현할 때 유용합니다.
[{"type":"text","text":"혹시 kubernetes network 중 AWS에서만 제공하는 VPC CNI 에 대해서 설명해줄 수 있을까?"}] AWS VPC CNI (Container Network Interface)는 Amazon EKS (Elastic Kubernetes Service)에서 기본적으로 사용되는 네트워킹 플러그인입니다. 이 CNI는 Kubernetes 클러스터의 pod 네트워킹을 AWS VPC (Virtual Private Cloud) 네트워크와 통합하는 역할을 합니다. 다음은 AWS VPC CNI의 주요 특징과 작동 방식입니다:
네이티브 VPC 네트워킹:
Pod는 VPC 내의 실제 IP 주소를 할당받습니다.
이를 통해 VPC 내의 다른 AWS 서비스와 직접 통신이 가능합니다.
보안 그룹 통합:
Pod 수준에서 AWS 보안 그룹을 적용할 수 있습니다.
세분화된 네트워크 정책 구현이 가능합니다.
높은 네트워크 성능:
VPC의 네이티브 네트워킹을 사용하므로 오버레이 네트워크에 비해 성능이 우수합니다.
IP 주소 관리:
각 노드에 대해 보조 IP 주소 풀을 관리합니다.
Pod가 생성될 때 이 풀에서 IP 주소를 할당받습니다.
ENI (Elastic Network Interface) 활용:
각 노드에 여러 ENI를 연결하여 사용 가능한 IP 주소 수를 늘립니다.
프리픽스 위임 지원:
대규모 클러스터에서 IP 주소 관리를 효율적으로 할 수 있습니다.
IPv4 및 IPv6 지원:
듀얼 스택 네트워킹을 지원합니다.
커스텀 네트워킹:
사용자 정의 네트워킹 구성이 가능합니다.
자동 설정:
EKS 클러스터 생성 시 자동으로 설치 및 구성됩니다.
오픈소스:
GitHub에서 소스 코드를 확인하고 기여할 수 있습니다.
AWS VPC CNI는 AWS 환경에서 Kubernetes를 운영할 때 네트워킹을 간소화하고 AWS 서비스와의 통합을 용이하게 만듭니다. 그러나 다른 클라우드 환경이나 온-프레미스 환경에서는 사용할 수 없다는 제한이 있습니다. [{"type":"text","text":"pod 에 AWS security group 이 동작하는 내부 동작원리를 알려줄 수 있을까?"}] AWS VPC CNI에서 Pod에 Security Group을 적용하는 내부 동작 원리는 다음과 같습니다:
ENI (Elastic Network Interface) 생성:
Security Group을 적용할 Pod가 생성되면, VPC CNI는 해당 Pod를 위한 새로운 ENI를 생성합니다.
이 ENI는 Pod 전용이며, "트렁크 ENI"라고 불립니다.
Security Group 연결:
생성된 ENI에 지정된 Security Group이 연결됩니다.
Branch ENI 생성:
트렁크 ENI에서 가상의 "Branch ENI"가 생성됩니다.
이 Branch ENI는 실제로 AWS에 존재하지 않고, VPC CNI 내부에서만 관리됩니다.
IP 주소 할당:
Branch ENI에 IP 주소가 할당됩니다.
이 IP 주소는 Pod의 IP 주소가 됩니다.
네트워크 네임스페이스 설정:
Pod의 네트워크 네임스페이스에 Branch ENI가 연결됩니다.
트래픽 라우팅:
Pod에서 나가는 트래픽은 Branch ENI를 통해 트렁크 ENI로 전달됩니다.
트렁크 ENI에 연결된 Security Group 규칙에 따라 트래픽이 필터링됩니다.
인바운드 트래픽 처리:
Pod로 들어오는 트래픽도 트렁크 ENI를 통과하며, 여기서 Security Group 규칙이 적용됩니다.
CNI 데몬 관리:
VPC CNI 데몬이 지속적으로 Pod, ENI, IP 주소, Security Group 간의 매핑을 관리합니다.
동적 업데이트:
Pod의 수명 주기 동안 Security Group 규칙이 변경되면, 트렁크 ENI에 연결된 Security Group이 업데이트됩니다.
리소스 정리:
Pod가 종료되면, 관련된 Branch ENI가 제거되고, 필요 없어진 트렁크 ENI도 삭제됩니다.
이 방식을 통해 AWS VPC CNI는 Pod 레벨에서 Security Group을 적용할 수 있으며, 이는 기존 EC2 인스턴스에 Security Group을 적용하는 것과 유사한 수준의 네트워크 보안을 제공합니다. 이 기능은 특히 마이크로서비스 아키텍처에서 세분화된 보안 정책을 구현할 때 유용합니다. [{"type":"text","text":"그럼 왜 t 타입 인스턴스에서 pod for security group\u001c을 쓸 수 없는걸까?"}] T 타입 인스턴스에서 Pod에 대한 Security Group을 사용할 수 없는 이유는 주로 이러한 인스턴스의 네트워크 인터페이스 제한과 관련이 있습니다. 구체적인 이유는 다음과 같습니다:
ENI (Elastic Network Interface) 제한:
T 타입 인스턴스는 일반적으로 제한된 수의 ENI만 지원합니다.
Pod에 대한 Security Group 기능은 추가 ENI (트렁크 ENI)를 필요로 하지만, T 타입 인스턴스는 이를 지원하기에 충분한 ENI를 제공하지 않습니다.
네트워크 대역폭 제한:
T 타입 인스턴스는 버스트 가능한 성능을 제공하는 인스턴스로, 지속적인 높은 네트워크 성능을 보장하지 않습니다.
Pod에 대한 Security Group 기능은 추가적인 네트워크 처리를 필요로 하며, 이는 T 타입 인스턴스의 네트워크 성능 제한에 부담을 줄 수 있습니다.
리소스 제약:
T 타입 인스턴스는 일반적으로 리소스가 제한된 경제적인 옵션으로 설계되었습니다.
Pod에 대한 Security Group 기능은 추가적인 CPU와 메모리 리소스를 필요로 하며, 이는 T 타입 인스턴스의 제한된 리소스에 부담을 줄 수 있습니다.
아키텍처 제한:
Pod에 대한 Security Group 기능은 특정 네트워크 아키텍처와 드라이버를 필요로 하며, 이는 T 타입 인스턴스의 하드웨어 또는 소프트웨어 구성과 호환되지 않을 수 있습니다.
AWS 설계 결정:
AWS는 T 타입 인스턴스의 사용 사례와 성능 특성을 고려하여 이 기능을 지원하지 않기로 결정했을 수 있습니다.
복잡성 관리:
T 타입 인스턴스는 주로 간단하고 경제적인 워크로드를 위해 설계되었습니다. Pod에 대한 Security Group 기능의 복잡성은 이러한 설계 철학과 맞지 않을 수 있습니다.
이러한 이유로 인해 AWS는 T 타입 인스턴스에서 Pod에 대한 Security Group 기능을 지원하지 않습니다. 대신, 이 기능을 사용해야 하는 경우 C, M, R 등의 다른 인스턴스 타입을 사용하는 것이 권장됩니다. 이러한 인스턴스 타입들은 더 많은 네트워크 리소스와 성능을 제공하여 Pod에 대한 Security Group 기능을 지원할 수 있습니다.
Last updated