1. 개요
ALB에 SSL 인증서 연결 Terraform으로 구현된건가요?
Console에서 생성한 불필요한 리소스를 지우는 과정에서 이런 질문이 나왔다.
History가 명확하지 않은 리소스가 어떻게 생성됐는지 확인이 필요한 작업이었다. (Console, Terraform, AWS CDK 와 같은 방법 중)
Terraform 사용시에는 태그 가능한 모든 Resource에 Key=Terraform,Value=True Tag를 강제하기 때문에 쉽게 Terraform 여부를 판단할 수 있다.
•
EKS Cluster
•
Security Group
•
Elastic IP
하지만 다음과 같이 Resource가 아닌 작업은 Terraform Code 없이 직관적으로 판단하기 쉽지 않다.
•
ALB 리스너에 SSL 인증서 연결
•
RTB에 Routing Rule 추가 등
Terraform의 경우 resource 블럭으로 생성했다면, 폴더에서 이름을 찾으면 된다. 하지만 다음과 같은 경우에는 판단이 어려울 수 있다.
•
어떤 폴더에서 만들었는지 히스토리가 불분명함
•
Module을 사용한 경우 바로 검색하기가 힘듦 (resource는 aws_lb_listener로 고정이라면, 모듈은 listener 부분을 어떻게 입력받는지 모듈별로 모두 다르기 때문)
•
Code로도 존재하고 실제로도 존재하는 리소스인데 값이 다른경우
•
Terraform이 아닌 CDK, AWS CLI등의 작업인 경우
•
결국 포스팅 처음 질문에 대한 대답은 ALB에 리스너 추가 & SSL 인증서 연결 작업이 90일이 지나지 않아서 CloudTrail로 확인할 수 있었고, Console 작업인 것을 확인할 수 있었다.
Event history를 90일 이상 유지하기 위해서는 별도의 백업이 필요하다.
이 과정에서 알게된 CloudTrail Log의 userAgent 에 대한 내용을 정리해봤다.
2. 로그 확인 및 비교
Console 작업 로그와 AWS CLI 작업 로그를 비교해보자
좌 : Console 작업, 우 : AWS CLI 작업
1. Console 작업 로그 중 일부
2. AWS CLI 작업 로그 중 일부
3. Terraform의 aws_alb_listener block으로 리스너 생성시 로그 중 일부
(참고) 1,2 번 로그와 3번 로그의 eventName 값이 다른 이유
가장 크게 다른건 sourceIPAddress, userAgent 두 가지다.
userAgent 값만 보더라도 해당 API 호출이 Console, CLI, CDK, Terraform 등 어떤 방식을 사용했는지 판단할 수 있다.
AWS Console의 경우에는 IAM User, Account가 아닌 SSO로 AssumeRole 접속을 했기 때문에 프록시 클라이언트에 속해서 두 값이 모두 AWS Internal로 표시된다.
3. 마무리
CloudTrail은 AWS에 대한 모든 API 작업을 기록한다. 그리고 API를 호출하는 방법은 Console, CLI, Terraform, CDK 등 다양한 방법이 존재한다.
로그는 육하원칙 모든 정보를 기록하기 때문에 오늘은 특정 작업을 누가, 어디서 했는지 확인하는 방법을 알아보았다.
이를 통해 리소스를 생성한 방법을 쉽게 확인할 수 있으며, 이를 통해 리소스 히스토리를 더욱 쉽게 파악할 수 있다.