유즈케이스 11 · 기계 주체

크로스 어카운트: dev CI → admin Route 53

dev의 배포 파이프라인이 admin 계정의 zandi.wiki 레코드를 수정.

DevOps 관리자CI 파이프라인

STEP 1 / 5DevOps 관리자

DevOps: admin에 Role 생성

Trust에 dev의 github-deploy Role ARN만 넣는다. 권한은 해당 hosted zone, 특정 레코드 이름으로 제한.

단계단계를 누르면 위 관계도가 그 단계로 바뀐다

Trust에 dev의 github-deploy Role ARN만 넣는다. 권한은 해당 hosted zone, 특정 레코드 이름으로 제한.
```
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::222222222222:role/github-deploy"},
  "Action": "sts:AssumeRole"
}
```
크로스 어카운트는 양쪽 동의가 필요하다. 호출자 Identity 정책에 sts:AssumeRole 허용 + 대상 Role의 Trust 허용.
```
{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::111111111111:role/route53-records"
}
```
Role 세션으로 다른 Role을 빌리는 역할 체이닝이라 세션은 최대 1시간.

admin은 관리 계정이라 SCP가 적용되지 않는다. Role 정책을 레코드 이름 조건까지 좁혀 두는 게 사실상 유일한 상한.

{
  "Effect": "Allow",
  "Action": "route53:ChangeResourceRecordSets",
  "Resource": "arn:aws:route53:::hostedzone/Z0123ABC",
  "Condition": {
    "ForAllValues:StringLike": {
      "route53:ChangeResourceRecordSetsNormalizedRecordNames": ["*.dev.zandi.wiki"]
    }
  }
}

dev.zandi.wiki 호스팅 영역을 dev 계정에 만들고 admin zone엔 NS 레코드만 추가하면, 이후 레코드 작업은 dev 안에서 끝나 크로스 어카운트 Role이 필요 없다.
```
; admin 계정의 zandi.wiki zone
dev.zandi.wiki.  NS  ns-123.awsdns-45.com.
dev.zandi.wiki.  NS  ns-678.awsdns-90.net.
; ... dev 계정 zone의 NS 4개
```