STS และการทำ Cross-Account Access
บริการสร้าง Credential ชั่วคราว และการให้สิทธิ์ข้ามบัญชี
การทำ Cross-account เหมือนการขอวีซ่าไปต่างประเทศ — ประเทศปลายทาง (Account B) ต้องตั้งกฎอนุญาต (Trust Policy) ให้คนจากประเทศต้นทาง (Account A) เข้ามาได้ ส่วนฝั่งต้นทางก็ต้องอนุญาตให้พนักงานตัวเองเดินทางไปได้ด้วย
AWS STS (Security Token Service) คือบริการหลังบ้านที่ทำหน้าที่ "เสก" Credential ชั่วคราว (Access Key, Secret Key, Session Token) ที่มีวันหมดอายุ เมื่อใดก็ตามที่คุณสวม Role (AssumeRole) STS จะเป็นคนออกกุญแจให้คุณ
- Cross-Account Access (การเข้าถึงข้ามบัญชี) — แทนที่จะสร้าง IAM User ใหม่ใน Account B ให้แอดมินใน Account B สร้าง Role และตั้ง Trust Policy อนุญาตให้ Account A สวม (Assume) Role นี้ได้
- แอดมิน Account A ก็ต้องสร้างนโยบายให้ User ของตนสามารถใช้สิทธิ์
sts:AssumeRoleกับ Role ใน Account B ได้ - เมื่อ User จาก A ต้องการทำงานใน B จะเรียกใช้ STS เพื่อขอรับ Credential ชั่วคราว
สรุป Key Takeaways
- STS คือตัวสร้างกุญแจชั่วคราว (Temporary Credentials) เมื่อมีการสวม Role
- Cross-Account Access ทำได้ผ่านการ AssumeRole ข้ามบัญชี
- ต้องมีการอนุญาตจากทั้ง 2 ฝั่ง (Trust Policy ฝั่งปลายทาง, IAM Policy ฝั่งต้นทาง)
คำถามที่พบบ่อย
Cross-account access ที่ถูกต้องทำยังไง
สร้าง role ในบัญชีปลายทางที่ trust บัญชีต้นทาง แล้วให้คน/ระบบต้นทาง AssumeRole ผ่าน STS ได้ credential ชั่วคราว — ห้ามแชร์ access key ข้ามบัญชีเด็ดขาด โจทย์ "บริษัท A ให้ vendor B เข้าถึง S3 ของตน" = cross-account role + external ID
External ID ใน trust policy มีไว้ทำไม
กันปัญหา confused deputy — เมื่อให้ third party สวม role ของเรา external ID เป็นรหัสลับร่วมที่ third party ต้องแนบตอน AssumeRole กันคนอื่นหลอกใช้ vendor นั้นสวม role เราแทน — เจอคำว่า third party access ให้มองหา external ID
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที