[AWS] IMDSv1과 IMDSv2 비교

 

글을 작성하게된 계기

현재 Pulumi 기반 IaC 도구로 EC2 인스턴스 생성 자동화를 진행 중이다. 인스턴스 생성 시 User Data를 적용하고, 이 데이터를 기반으로 CloudWatch 대시보드까지 한 번의 프로세스로 만들어내는 작업을 수행하고 있다.

 

CloudWatch 대시보드에는 생성된 인스턴스의 ID, Name, EBS, EFS 등 인스턴스 생성 후 확인 가능한 메타데이터 값들이 포함되어야 했다. 이 값을 동적으로 조회하기 위해 IMDSv2 방식을 사용했다.

 

처음에는 "IMDSv2 방식으로 인스턴스 정보를 동적으로 가져올 수 있다" 정도로만 알고 있었지만, IMDSv1과 v2의 차이점과 정확한 개념은 명확하지 않았다. 이번 기회에 IMDS의 동작 방식, v1과 v2의 차이, 그리고 v2가 어떤 문제를 해결하기 위해 등장했는지를 정리하게 되었다.

 

IMDS(Instance Metadata Service)의 개념

IMDS는 EC2 인스턴스 내부에서 실행되는 애플리케이션이나 사용자 스크립트가 해당 인스턴스의 메타데이터를 조회할 수 있도록 제공하는 AWS의 HTTP 서비스이다.

• 접근 방법: 인스턴스 내부에서 http://169.254.169.254로 HTTP 요청
• 외부에서 접근 불가: EC2 인스턴스 내부에서만 접근 가능
• 사용 목적: 동적으로 인스턴스 정보를 가져와서 사용
• 버전: IMDSv1(기존), IMDSv2(강화된 보안 버전)

 

나는 인스턴스 메타데이터를 사용하여 CloudWatch 대시보드를 생성하는 작업을 실제로 수행했다:

1. Pulumi(IaC)에 의해 EC2 인스턴스가 생성된다.
2. User Data를 적용하기 위한 쉘스크립트가 실행되고, 이 쉘스크립트에서 IMDS 방식으로 인스턴스 메타데이터를 조회한다.
   1. 인스턴스 ID, 인스턴스 Name, EBS ID(sda1, sdm), ...
3. 조회한 메타데이터를 기반으로 CloudWatch 대시보드를 생성하는 쉘스크립트를 실행한다.

 

IMDSv1의 개념

IMDSv1은 초기 EC2 인스턴스에서 사용되던 메타데이터 접근 방식으로, 인스턴스 내부에서 다음과 같이 메타데이터에 접근이 가능했다.

curl http://169.254.169.254/latest/meta-data/

 

IMDSv1의 특징으로는

• HTTP GET 요청만으로 간단하고 빠르게 인스턴스 메타데이터 조회 가능
• 인스턴스 메타데이터 조회 시에 인증 과정이 없음
  • 보안에 취약

IMDSv1은 보안에 취약하다.

 

IMDSv1은 인스턴스 메타데이터 조회 시에 별다른 인증 과정이 없으므로 SSRF(Server-Side Request Forgery) 공격에 취약하다.

• 애플리케이션에 SSRF 취약점이 존재하면 외부 공격자가 인스턴스 메타데이터에 접근 가능
  • IAM Role의 Credentials 탈취 가능

 

SSRF(Server-Side Request Forgery)는 공격자가 서버 측 애플리케이션의 취약점을 통해 의도하지 않은 내부 리소스에 접근하도록 만드는 보안 취약점이다. 예를 들어, 공격자가 서버 측의 보안 취약점을 악용하여 외부에서는 접근할 수 없는 내부 리소스에 접근하여 내부 시스템 정보 탈취, 관리 콘솔 접근, IAM 자격증명 탈취 등이 가능해진다.

 

예를 들어, 서버가 인스턴스의 메타데이터를 가져와서 공격자에게 반환하도록 할 수 있다:

http://your-ec2-instance.com/fetch-image?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/YourRole

 

이게 가능한 이유는 IMDSv1에서는 인증 과정 없이 curl http://169.254.169.254/latest/meta-data 요청을 통해 메타데이터를 가져올 수 있기 때문이다:

• curl http://169.254.169.254/latest/meta-data/ 는 EC2 인스턴스 내부에서만 접근 가능한 메타데이터 전용 IP
• 외부에서는 접근할 수 없지만 EC2 내에서 실행되는 애플리케이션이 SSRF 공격에 취약하다면 공격자가 이 주소를 우회적으로 요청 가능

 

이러한 보안 취약점을 IMDSv2에서는 개선되었다.

 

IMDSv2의 개념

IMDSv2는 EC2 인스턴스에서 메타데이터에 접근하기 위한 보안 강화 버전(IMDSv1의 보안 강화 버전)이다.

 

IMDSv2는 세션 기반 접근을 사용한다. 클라이언트는 Token을 먼저 요청해야 하고, 이 Token을 사용하여 메타데이터에 접근하게 된다.

1. PUT 요청을 통해 메타데이터에 접근하기 위한 Token 발행
2. GET 요청 헤더에 Token을 포함하여 메타데이터에 접근

 

IMDSv2는 Token을 발행하기 위해 PUT 요청이 필요한데 SSRF 공격의 경우 주로 GET 요청만 지원되므로 인스턴스 메타데이터에 접근할 수 없다. Token을 헤더에 포함하지 않고 메타데이터에 접근할 경우 메타데이터가 절대 반환되지 않는다. (401 인증 실패)

 

IMDSv2 예제 시나리오

1. PUT 요청을 통해 Token 발급

IMDSv2는 단순히 GET 요청을 통해 메타데이터에 접근하는 것이 아닌, 먼저 PUT 요청을 통해 Token을 발급받아야 한다.

• 이 요청은 HTTP Method가 PUT이어야 한다.
• 타켓 주소는 고정 IP인 http://169.254.169.254/latest/api/token 이다.
• 그리고 요청 헤더에 X-aws-ec2-metadata-token-ttl-seconds 값을 지정해야 한다.
  • X-aws-ec2-metadata-token-ttl-seconds: 토큰 만료 시간

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

 

대부분의 SSRF 공격은 GET 요청만 서버에 전송할 수 있으므로, Token을 발급받기 위한 PUT 요청이 불가능하다. 이는 공격자가 Token 발급받는 것부터 실패하게 되므로 인스턴스 메타데이터 조회가 불가능하다. 

또한, PUT 요청 시에 Token의 TTL을 지정해야 하므로, 탈취당한 Token을 무한정 사용할 수 없다.

 

 

IMDSv2만 사용가능하도록 강제 설정하는 명령어:

aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-endpoint enabled \
  --http-tokens required

 

IMDSv1 vs IMDSv2

인증 방식	없음	세션 토큰 (PUT 요청)
보안 수준	낮음	높음
SSRF 방지	불가능	가능
토큰 TTL 설정	불가능	가능
사용 방식	curl http://169.254.169.254/...	토큰 발급 → 헤더 포함 GET 요청

 

---

 

• AWS 공식: Instance metadata and user data
• AWS 공식 문서 - IMDSv2 소개