Secure access to 100 AWS accounts

Segment · 2018 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bối cảnh

Segment bắt đầu trong một tài khoản AWS, năm 2017 tách thành dev, stage, prod và "ops". Đầu 2018 họ có vài chục tài khoản và thêm khoảng một tài khoản mỗi 1–2 tuần, hướng tới tài khoản riêng theo team và theo hệ thống.
Lý do chia nhỏ tài khoản (theo Segment): cô lập bảo mật giữa các hệ, phục vụ các sáng kiến GDPR, và giới hạn bán kính ảnh hưởng của rate limit AWS (mỗi tài khoản có hạn mức riêng).
Cách cũ: nhân viên đăng nhập tài khoản "ops" bằng email, mật khẩu, 2FA, rồi AssumeRole sang role ops-admin ở dev/stage/prod; mỗi người giữ IAM user key trong keychain qua aws-vault, mọi người dùng chung một ~/.aws/config.

Hub-and-spoke qua identity provider: nhân viên đăng nhập Okta vào tài khoản hub ("ops"), từ đó sts:AssumeRole sang các tài khoản spoke. Hướng dẫn của Okta gợi ý nối IdP vào từng tài khoản; Segment không làm vậy vì cách đó phá tính năng chuyển tài khoản có sẵn của AWS và khó audit team nào có role nào.
Role theo team ở hub: mỗi team có một role ở hub, chủ yếu chứa quyền assume sang các role ở spoke. Ví dụ: team FP&A chỉ xem billing và reserved capacity, không vào spoke nào; team Foundation & Reliability (trực on-call) có ReadOnly và Administrator ở mọi tài khoản. Nhóm trong Okta gắn với role ở hub.
Hai module Terraform (role ở hub, role ở spoke) chỉ khác nhau ở trust relationship: hub tin IdP, spoke chỉ tin tài khoản hub.
Không nhân viên nào còn AWS key: mọi truy cập qua IdP với credential tạm từ SAML assertion.
Giữ trải nghiệm cũ: team tooling viết aws-okta (mã nguồn mở) thay gần như y hệt aws-vault: mật khẩu Okta trong keychain, push 2FA, SAML → credential tạm; thêm lệnh login mở console bằng Custom Federated Login vì bookmark chuyển role của AWS chỉ hỗ trợ 5 đích. Config theo team nằm trong repo dotfiles, sinh bằng robo aws.config dựa vào biến SEGMENT_TEAM mà mọi engineer đã có.

Theo Segment, chất lượng của aws-okta là lý do chính việc thu hồi toàn bộ key của engineer diễn ra êm: cách làm việc hằng ngày gần như không đổi.
Họ dự kiến khoảng 50 tài khoản cuối 2018 và cho rằng kiến trúc đủ cho hàng trăm tài khoản.

Chia tài khoản cloud là một cách giới hạn bán kính ảnh hưởng, cả cho bảo mật lẫn cho rate limit của nhà cung cấp; cái giá là độ phức tạp của quyền truy cập, nên cần gom quyền về một điểm (hub + IdP) trước khi số tài khoản tăng.
Gỡ credential dài hạn của người là thay đổi phá vỡ quy trình: muốn được chấp nhận thì công cụ thay thế phải gần như "thả vào là chạy".
Đối chiếu: năm 2019 Postman vẫn dùng IAM user có key và audit định kỳ (Postman 2019); Segment bỏ hẳn key của người.