Our Journey Migrating to AWS IMDSv2

Slack · 2023 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Động lực là bảo mật (IMDSv1 làm lỗ hổng SSRF dễ lấy credential); wiki chỉ tóm tắt ngắn phần đó, tập trung vào cách chuyển cả fleet mà nhiều team sở hữu.

Bối cảnh

• Slack (2023) chạy khoảng 60.000 instance EC2 ở 17 region, hàng trăm AWS account (theo môi trường, theo team, đôi khi theo ứng dụng), nhiều team sở hữu. IMDS được dùng nhiều khi cấp phát máy và trong công cụ. Cấp phát qua Terraform, CloudFormation và công cụ tự viết gọi EC2 API.
• IMDSv2 (AWS ra 2019) đòi lấy token bằng PUT trước mỗi phiên, khó khai thác qua SSRF hơn. Mục tiêu: chuyển toàn bộ fleet và công cụ sang v2, tắt v1.

Thay đổi chính (các bước)

1. Đo phạm vi: metric CloudWatch MetadataNoToken đếm lần gọi v1 theo instance; app imds-cw-metric-collector lấy danh sách account từ API nội bộ (Archipelago), ghép với chủ sở hữu và Chef role, đẩy lên Prometheus; dashboard theo dõi mọi instance còn gọi v1 để làm việc với từng team.
2. Tìm process nào gọi: đóng gói AWS ImdsPacketAnalyzer thành gói Debian cho team tự cài; máy Ubuntu 18.04 cũ không chạy được nên dùng lsof, nethogs; cuối cùng trên vài máy dev thì tắt v1 và xem cái gì hỏng.
3. Ngừng gọi v1: sửa script bash, nâng AWS CLI và SDK các ngôn ngữ lên bản hỗ trợ v2 cùng team sở hữu; số instance dùng v1 giảm mạnh.
4. Tắt v1 cho máy mới: sửa ở module Terraform dùng chung do team cung cấp (một chỗ, nhiều team hưởng). Module accounts_using_imdsv1 là danh sách ngoại lệ các account còn đang chuyển; module chung đọc nó để đặt http_tokens là required hay optional. Danh sách co dần khi team chuyển xong.
5. Chặn ở tầng tổ chức: Service Control Policy cấm tạo instance có v1 và cấm bật lại v1, cũng trừ các account trong danh sách ngoại lệ. Giới hạn: SCP không áp cho account gốc của organization và cho service-linked role (ví dụ AutoScaling tự tạo máy); điều kiện cho Launch Template chưa hỗ trợ thuộc tính này.
6. Lưới cuối: rule EventBridge ở mọi account bắt sự kiện CloudTrail RunInstances có v1, gửi về event bus trung tâm, Lambda báo lên Slack; thêm một service tự khắc phục quét instance theo lô và ép v2, báo lại mỗi lần sửa và đẩy metric trạng thái lên Prometheus. Ban đầu hàng trăm thông báo cho máy cũ, rồi về không.

Vì sao

• Không có cách nào chặn tuyệt đối 100%, nên kết hợp nhiều lớp: sửa nguồn (code), mặc định (module chung), chặn (SCP), phát hiện và sửa sau (event + auto-remediation).

Bài học cho SWE

• Migration cả fleet bắt đầu bằng đo xem ai còn dùng cái cũ, ở cấp instance rồi cấp process (Migration không downtime).
• Danh sách ngoại lệ co dần cho phép bật mặc định mới cho mọi người ngay, trừ những team chưa xong; cùng danh sách dùng được cho cả module và policy.
• Module hạ tầng dùng chung là đòn bẩy: sửa một chỗ, mọi team nhận (Nền tảng nội bộ cho service (đường ray chung)).
• Biết chỗ thủng của cơ chế chặn (account gốc, service-linked role) và lấp bằng phát hiện + tự khắc phục (Tự động hoá vận hành và auto-remediation).

Liên quan

• Bảo mật hạ tầng và quản lý secret
• Cùng công ty: Slack 2016 · Slack 2018 · Slack 2020
• Migration không downtime · Tự động hoá vận hành và auto-remediation · Nền tảng nội bộ cho service (đường ray chung)