Today Keys : VPC, Organization, Reachability, Analyzer, reachability, analysis, role, 교차, 계정, 도달가능성, 분석
이번 포스팅에서는 AWS re:Invent 2022 기간에 추가된 AWS Organization의 계정 간의 VPC Reachability Analyzer를 통한 reachability analysis 지원에 대한 내용입니다. 기존에는 하나의 계정 내에서만 VPC Reachability Analyzer를 이용해서 AWS 리소스 간의 통신이 가능한지 reachability에 대한 분석이 가능했지만, 이제는 AWS Organization내에 속한 계정에도 reachability에 대한 분석이 가능해졌습니다. 이번 포스팅에서는 AWS Organization의 계정 간의 VPC Reachability Analyzer을 이용한 reachability analysis을 하는 방법에 대해서 알아봅니다.
이번 포스팅에서 다뤄 질 전체 아키텍처입니다.
먼저 간단히 구성을 살펴 보겠습니다.
하나의 Organization이 있고, Organization 내에 2개의 계정이 존재합니다.
각 계정에는 VPC와 EC2가 존재하고, VPC는 RAM을 이용해서 TGW로 계정 간 연결되어 있습니다.
기존에는 VPC Reachability Analyzer를 통해서 AWS 리소스 간의 네트워크 연결이 가능한지를
아래와 같이 동일 계정 내에서만 자원을 지정해서 볼 수 있었습니다.
이제 Organization에 속한 여러 계정에 속한 AWS 리소스 간의 VPC Reachability Analyzer를 지원합니다.
Organization에 속한 계정 간의 VPC Reachability Analyzer 지원을 위해서 필요한 작업은 매우 간단합니다.
VPC Reachability Analyzer에 새로 생긴, 'Setting' 메뉴로 들어가서,
'Trusted access' 기능을 활성화 해주기만 하면 됩니다.
현재 기본 상태가 'Turned off'로 해당 기능이 꺼져 있는 것을 볼 수 있습니다.
'Trusted access'를 활성화 하기 위해서 'Turn on trusted access'를 클릭합니다.
아래와 같은 팝업 메뉴가 뜨는 데, 'Turn on trusted access' 를 클릭하시면 끝납니다.
팝업 메뉴의 내용을 간단히 읽어보면,
Reachability Analyzer와 CloudFormation StackSet이 Organization에 접근 하도록 허용을 하게 되는 데,
Organization에 속한 멤버에 CloudFormation StackSet이 Role을 배포하게 됩니다.
배포된 Role은 아래에서 다시 살펴 보겠습니다.
'Trusted access' 기능을 켜고 나면, 이제 상태 값이 'Turned on'으로 변경 된 것을 볼 수 있습니다.
그리고, 제일 하단에 보시면 IAM Role이 Organization 내의 Member Account에 배포된 것을 볼 수 있습니다.
Trusted access 기능을 켜자마자 바로 아래와 같이 배포가 완료되지는 않고,
약 5분 이내로 아래와 같이 'Stackset managed'로 바뀌고, 그 전에는 'in Progress' 상태로 표지 됩니다.
참고로, 'Trusted access' 기능은 Organization의 Management Account에서만 설정이 가능하며,
다른 Account에서 'Setting' 메뉴로 들어가면 아래와 같은 안내 창만 뜹니다.
이제 너무나도 간단하게 모든 설정이 완료되었기 때문에 바로 Reachability Analyzer에서 analyze path를 만들겠습니다.
아래 그림과 같이 Source Type과 Destination Type 앞에 Account를 선택하는 메뉴가 생긴 것을 볼 수 있습니다.
Source Account 메뉴를 선택해 보면, Organization에 속한 계정을 선택하도록 되어 있습니다.
이제 analyze path를 만들어 보겠습니다.
Organizaion에 속한 Account 2개의 각각의 EC2 인스턴스를 Source와 Destination으로 지정해서 경로를 만듭니다.
아래와 같이 정상적으로 출발지와 목적지가 서로 다른 Account에 있는 Analyze path가 만들어진 것을 볼 수 있습니다.
잠시 후, EC2 간이 정상적으로 'Reachable'하다는 것을 볼 수 있습니다 .
상세히 분석된 Path를 확인해 보면, 아래와 같이 서로 다른 계정 간의 AWS 리소스를 거쳐서,
EC2 인스턴스 간의 모든 경로가 분석된 것을 볼 수 있습니다.
만약, 아래와 같이 'Not reachable' 상태로 Reachability가 분석 되면,
어느 구간에, 어떤 문제인지 확인이 할 수 있습니다.
물론 이러한 분석은 기존에도 지원이 됐지만,
아래와 같이 서로 다른 계정에서 발생하는 문제도 한 눈에 볼 수 있기 때문에
보다 쉽게 VPC의 리소스 간으이 Reachability를 확인 할 수 있습니다.
잠시, 'Trusted access' 기능을 활성화 하면서 만들어진 IAM Role을 살펴보면,
Management Account와 일반 Account로 나눠 볼 수 있습니다.
Management Account에는 AWSServiceRoleForReachabilityAnalyzer라는 Role이,
일반 Account에는 AWSServiceRoleForReachabilityAnalyzer와 IAMRoleForReachabilityAnalyzerCrossAccountResourceAccess라는 Role이 만들어진 것을 볼 수 있습니다.
|
※ 참고
- AWSServiceRoleForReachabilityAnalyzer : Reachability Analyzer에 대한 service-linked role
- IAMRoleForReachabilityAnalyzerCrossAccountResourceAccess : Reachability Analyzer에 대한 console access role
|
Analyze path를 만들 때 IAMRoleForReachabilityAnalyzerCrossAccountResourceAccess Role에 대한 허용 권한이 있어야만 Console 내에서 출발지와 목적지 AWS 리소스에 대한 계정 설정이 가능하도록 보입니다.
이러한 권한은 Organization의 Management Account에 대해서만 허용되지만, Delegated administrators 을 통해서 다른 Account에 권한을 추가로 할당 할 수 있습니다.
그럼 이제 Organization의 다른 Account에서 계정 간 Reachability Analyzer를 사용할 수 있도록 권한을 할당해보겠습니다.
VPC Reachability Analyzer에 새로 생긴, 'Setting' 메뉴 중간쯤에 있는 Delegate administrators에서 'Resgister delegated administrator'을 클릭합니다.
팝업 메뉴에서 AWS Account ID를 입력 할 수 있게 되어 있고,
아래와 같이 Organization에 속한 Account를 선택 할 수 있는 것을 볼 수 있습니다.
권한을 추가하면, 아래와 같이 기존 Member Account에 대한 Console Role이 변경되어야 하기 때문에
상태 값이 In progress로 변경된 것을 볼 수 있습니다.
변경이 모두 완료되면, 아래와 같이 Member Account의 Console role status가 'StackSet managed'로 상태가 변경된 것을 볼 수 있습니다.
Delegated administrator에도 방금 전에 권한을 추가한 Account ID가 등록(Regsitered)된 것을 볼 수 있습니다.
|
참고로 본 예제에서는 Management Account 이외의 Account가 1개이기 때문에 같은 Account 1개만 보이지만,
여러 Account가 있는 Organization의 경우에
IAM role deployments status는 Organization 내의 Account들이 추가로 보이게 되고,
Delegated administrator에는 권한을 등록한 Account만 보이게 됩니다.
|
이제 일반 Account의 IAMRoleForReachabilityAnalyzerCrossAccountResourceAccess Role을 다시 확인해 보면, Delegated administrator에 대한 Account가 추가 되었기 때문에 해당 Role의 Trusted entities가 늘어나 있습니다.
접근이 허용된 Account ID를 확인하기 위해서 Role의 Trust relationships을 보면, Principal에 해당 Role에 접근 가능한 Organization내의 모든 Account ID를 볼 수 있습니다.
