EC2 인스턴스 ID를 스크립트에서 가져오는 법 — IMDSv2가 V1보다 안전한 이유
서버 내부에서 실행 중인 스크립트가 자신이 어느 인스턴스인지 알아야 할 때가 있다. 로그에 인스턴스 ID를 찍거나, 태그를 조회하거나, Auto Scaling 그룹에서 자기 자신을 식별해야 할 때 — 이 시나리오에서 EC2 인스턴스 메타데이터 서비스(IMDS)가 유일한 현실적 선택지다. 문제는 기본 설정 그대로 두면 SSRF 취약점 하나로 IAM 자격증명까지 탈취당할 수 있다는 점이다. TL;DR — IMDSv1 vs IMDSv2 핵심 비교 항목 IMDSv1 IMDSv2 인증 방식 없음 (단순 GET) 세션 토큰 (PUT → GET) SSRF 취약점 노출 높음 낮음 (토큰 발급에 PUT 필요) TTL 제어 불가 가능 (1초 ~ 21600초) 강제 적용 방법 해당 없음 HttpTokens=required 기본 엔드포인트 http://169.254.169.254 인스턴스 메타데이터 서비스(IMDS)가 동작하는 방식 IMDS는 인스턴스 내부에서만 접근 가능한 링크-로컬 HTTP 엔드포인트( 169.254.169.254 )다. 하이퍼바이저 계층에서 라우팅을 차단하기 때문에 인스턴스 외부에서는 원칙적으로 도달할 수 없다. 인스턴스 ID, AMI ID, IAM 역할 자격증명, 네트워크 인터페이스 정보 등 부트스트랩에 필요한 거의 모든 런타임 정보를 여기서 가져온다. IMDSv1은 단순 GET 요청만으로 모든 데이터를 반환한다. 애플리케이션에 SSRF(Server-Side Request Forgery) 취약점이 있으면 공격자는 그 취약점을 통해 http://169.254.169.254/latest/meta-data/iam/security-credentials/ 까지 도달해 임시 자격증명을 탈취할 수 있다. 실제로 2019년 Capital One 침해 사고의 핵심 경로가 이 패턴이었다. IMDSv2는 세션...