이 글은 우리의 AWS DevOps Agent 시리즈의 세 번째 포스트입니다.

대부분의 실제 애플리케이션은 단일 AWS 계정 내에 존재하지 않습니다. 서비스는 한 계정에서 실행되는 반면, 데이터 레이어(data layer), 공유 네트워킹(shared networking) 또는 형제 마이크로서비스(sibling microservice)는 다른 계정에 위치할 수 있습니다. 만약 AWS DevOps Agent가 배포된 계정만 볼 수 있다면, 해당 경계 외부의 리소스를 다루는 모든 조사는 사각지대에 부딪히게 됩니다. 교차 계정 모니터링(Cross-account monitoring)은 이러한 격차를 해소하여, 하나의 Agent Space가 단순히 자신의 홈 계정뿐만 아니라 전체 애플리케이션 발자국(application footprint)을 가로질러 볼 수 있게 해줍니다.

사전 요구 사항 (Prerequisites)

보조 계정을 추가하기 전에 다음 사항을 확인하십시오:

• 기본 계정(primary account)의 AWS DevOps Agent 콘솔에 대한 액세스 권한
• 보조 계정(secondary account)에서 역할을 생성할 수 있는 IAM 권한

교차 계정 액세스 뒤에 숨겨진 IAM 정책 (IAM Policies)

모든 보조 계정 연결은 세 가지 별도의 정책 구성 요소에 기반하며, 각 구성 요소의 역할을 이해하면 아래의 설정 단계가 훨씬 덜 기계적으로 느껴질 것입니다:

• 신뢰 정책 (Trust policy) — AWS DevOps Agent 서비스 주체(service principal, aidevops.amazonaws.com)가 역할을 직접 맡을(assume) 수 있도록 합니다. 여기에는 혼동된 대리인(confused deputy) 방지를 위한 aws:SourceAccount 및 aws:SourceArn 조건이 구체적으로 포함되어 있습니다. 이는 보안 제어 장치로서, 다른 곳의 어떤 AWS DevOps Agent 배포가 아닌, 오직 기본 계정의 귀하의 Agent Space만이 이 신뢰 관계를 사용할 수 있도록 보장합니다.
• AIDevOpsAgentAccessPolicy — 에이전트가 리소스를 조사하는 데 필요한 핵심 읽기 전용(read-only) 권한을 제공하는 AWS 관리형 정책(AWS-managed policy)입니다. AWS는 새로운 기능이 출시됨에 따라 이를 유지 관리하고 업데이트합니다.
• 인라인 정책 (Inline policy) — 귀하의 특정 Agent Space 구성에서 생성되며, 귀하가 활성화한 통합(integrations) 또는 기능과 연결된 권한을 다룹니다.

콘솔을 통한 설정 방법

1단계: 해당 에이전트 스페이스(agent space)로 이동 -> 보조 계정 추가 (Add Secondary Account) -> AWS 계정 선택

devop-agent-cross-acc

2단계: 이 단계에서는 보조 계정(secondary account)에 IAM 역할(role)을 생성해야 합니다. 이 역할은 기본 계정(primary account)과 에이전트 스페이스(agent space)로부터의 신뢰 정책(trust policy)을 가져야 합니다. 계정을 추가하면 아래와 같은 마법사(wizard)가 나타납니다.

devop-agent-cross-acc

3단계: 보조 계정에 역할을 생성합니다. 새 브라우저 탭에서 보조 계정의 IAM 콘솔에 로그인한 후 → 역할(Roles) → 역할 생성(Create role) → 사용자 지정 신뢰 정책(Custom trust policy)을 선택하고, 2단계에서 가져온 신뢰 정책을 붙여넣습니다.

4단계 — AWS 관리형 정책(AWS managed policy) 연결. AIDevOpsAgentAccessPolicy를 검색하여 선택합니다.

5단계 — 역할 이름 지정 및 생성. 2단계에서 지정한 것과 동일한 이름을 사용하고, 선택 사항인 설명을 추가한 뒤 생성합니다.

6단계 — 인라인 정책(inline policy) 연결. 새로 생성된 역할의 권한(Permissions) 탭에서 권한 추가(Add permissions) → 인라인 정책 생성(Create inline policy)을 선택합니다. JSON 탭으로 전환한 다음, 콘솔에서 제공한 정책을 신뢰 정책과 함께 붙여넣습니다. 식별 가능한 이름(예: DevOpsAgentInlinePolicy)을 지정하고 생성합니다.

7단계 — 구성 완료. 다시 기본 계정의 AWS DevOps Agent 콘솔로 돌아가 '다음(Next)'을 선택하고 연결 상태가 '활성(Active)'으로 표시되는지 확인합니다.

데모: 교차 계정(Cross-Account) 가치의 실제 작동 모습

교차 계정 모니터링이 왜 중요한지 체감하는 가장 좋은 방법은 글로 읽는 것이 아닙니다. 교차 계정 설정이 없을 때 조사가 벽에 부딪히는 모습을 보고, 설정이 있을 때 성공하는 모습을 직접 관찰하는 것입니다.

설정 환경:

• 계정 A (기본 계정, 에이전트 스페이스가 있는 곳) — Lambda 함수 및 해당 함수의 오류(Errors) 지표에 대한 CloudWatch 알람
• 계정 B (보조 계정, 위 단계에 따라 연결됨) — 계정 A의 Lambda 역할에 쓰기 권한을 부여하는 리소스 기반 정책(resource-based policy)이 적용된 DynamoDB 테이블

devop-agent-cross-acc

데모 목적으로, DynamoDB의 리소스 정책(resource policy)을 PutItem에서 GetItem으로 의도적으로 수정하여 Lambda 에러를 유발했습니다.

Lambda 에러에 대한 CloudWatch 알람(alarm)을 설정해 두었으므로, 알람이 트리거되면 해당 DevOps Agent Lambda가 DevOps Agent 공간(space)에서 API 호출을 수행합니다.

몇 분 안에 DevOps Agent가 근본 원인(root cause)과 해결 방법(remediation)을 제안합니다.

devop-agent-cross-acc

devop-agent-cross-acc

또한 JIRA와도 연결되어 있으므로 (이전 블로그), JIRA에 티켓이 생성되었습니다.

devop-agent-cross-acc

이 블로그가 DevOps Agent에서 교차 계정(cross-account) 설정을 어떻게 수행할 수 있는지에 대한 정보를 제공했기를 바랍니다.

핵심 요약 (Key Takeaways)

• 대부분의 실제 애플리케이션은 하나 이상의 AWS 계정에 걸쳐 있으므로 교차 계정 모니터링이 필요합니다. 전체 그림을 볼 수 없는 에이전트는 사각지대를 가지고 조사하게 됩니다.
• 액세스 권한은 세 가지 정책에 기반합니다: 혼란스러운 대리인(confused-deputy) 방지 기능이 포함된 신뢰 정책(trust policy), AWS 관리형 AIDevOpsAgentAccessPolicy, 그리고 에이전트 공간(Agent-Space) 전용 인라인 정책(inline policy)입니다.
• 에이전트 공간에서 보조 계정을 제거한다고 해서 해당 계정의 IAM 역할(role)이 삭제되지는 않습니다. 이 점을 오프보딩(offboarding) 체크리스트에 포함시키세요.