AWS ได้ประกาศอัปเดตสำหรับ AWS Security Token Service (STS): ตอนนี้คุณสามารถตรวจสอบ JWT claims เฉพาะของผู้ให้บริการข้อมูลประจำตัวที่เลือกได้จาก Google, GitHub, CircleCI, และ Oracle Cloud Infrastructure (OCI) เมื่อคุณใช้ AssumeRoleWithWebIdentity สิ่งนี้สำคัญเพราะทำให้การเขียน นโยบายความน่าเชื่อถือของ IAM ที่เข้มงวด สำหรับ OIDC-based federation (CI/CD, workload identity) ง่ายขึ้น โดยไม่ต้องพึ่งพารูปแบบที่กว้างเกินไป
ที่มา: ประกาศจาก AWS
ทำไมสิ่งนี้ถึงมีประโยชน์ ลิงก์ไปยังหัวข้อ
หากคุณใช้ OIDC federation อยู่แล้ว คุณอาจเคยทำอย่างน้อยหนึ่งในสิ่งเหล่านี้:
- จำกัดการเข้าถึงด้วยรูปแบบ
subเดียว และหวังว่ามันจะเฉพาะเจาะจงเพียงพอ - ใช้ชื่อ repository หรือชื่อ branch ที่เปลี่ยนได้ง่าย
- ยอมรับ “เวิร์กโฟลว์ใดๆ ในองค์กรนี้สามารถ assume role ได้” เพราะนโยบายซับซ้อนเกินไป
คีย์ claim เฉพาะของผู้ให้บริการช่วยให้คุณแสดงเจตนาได้ชัดเจนยิ่งขึ้น: “เฉพาะ repo นี้ (ตาม ID ที่ไม่เปลี่ยนรูป)”, “เฉพาะ enterprise นี้”, “เฉพาะเวิร์กโฟลว์นี้”, “เฉพาะ actor นี้”
ตัวอย่าง: เงื่อนไขนโยบายความน่าเชื่อถือของ GitHub Actions ลิงก์ไปยังหัวข้อ
สำหรับ GitHub Actions, AWS รองรับคีย์เงื่อนไขที่แมปกับ OIDC claims ทั่วไปของ GitHub
| คีย์เงื่อนไข AWS STS | IdP JWT claim | พร้อมใช้ใน session |
|---|---|---|
| actor | actor | No |
| actor_id | actor_id | No |
| job_workflow_ref | job_workflow_ref | No |
| repository | repository | No |
| repository_id | repository_id | No |
| workflow | workflow | No |
| ref | ref | No |
| environment | environment | No |
| enterprise_id | enterprise_id | No |
หมายเหตุเกี่ยวกับ “available in session”: การตรวจสอบ claim เหล่านี้จะถูกประเมินในขั้นตอน role assumption (trust policy) พวกมันไม่ได้ถูกสร้างขึ้นโดยอัตโนมัติเป็น attributes ที่คุณสามารถอ้างอิงได้ในภายหลังภายในนโยบายสิทธิ์ของ role
รูปแบบการใช้งานจริง ลิงก์ไปยังหัวข้อ
token.actions.githubusercontent.com:actor: ระบุ ใคร เป็นผู้เรียกใช้เวิร์กโฟลว์ ตัวอย่างเช่น หาก actor คือdependabot[bot]คุณอาจอนุญาตให้เข้าถึงแบบอ่านอย่างเดียวเท่านั้นtoken.actions.githubusercontent.com:repository_id: ควรใช้ ID ที่ไม่เปลี่ยนรูปแทนชื่อ เพื่อหลีกเลี่ยงสถานการณ์ “เปลี่ยนชื่อเพื่อเลี่ยงนโยบาย”token.actions.githubusercontent.com:enterprise_id: ตรวจสอบให้แน่ใจว่าเฉพาะเวิร์กโฟลว์จาก GitHub Enterprise ของคุณเท่านั้นที่สามารถ assume role ได้
ตัวอย่างนโยบายความน่าเชื่อถือของ IAM (GitHub Actions) ลิงก์ไปยังหัวข้อ
นี่คือรูปแบบนโยบายที่ฉันชอบ: รักษานโยบายความน่าเชื่อถือให้เข้มงวด และจำกัดสิทธิ์ให้อยู่ในขอบเขตการดำเนินการที่จำเป็นขั้นต่ำ
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:repository_id": "123456789",
"token.actions.githubusercontent.com:enterprise_id": "987654321"
},
"StringLike": {
"token.actions.githubusercontent.com:ref": "refs/heads/main",
"token.actions.githubusercontent.com:job_workflow_ref": "my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main"
}
}
}
]
}
คำแนะนำสั้นๆ ลิงก์ไปยังหัวข้อ
- ควรใช้ ตัวระบุที่ไม่เปลี่ยนรูป (
repository_id,enterprise_id) แทนชื่อเท่าที่จะทำได้ - ถือว่านโยบายความน่าเชื่อถือเป็น “การควบคุมการเข้าถึง” ของคุณ: ทำให้มันแคบที่สุดเท่าที่จะทำได้
- อย่าพึ่งพา OIDC federation session เพื่อ “ส่งต่อ” claims เหล่านี้ หากคุณต้องการบริบทสำหรับการตรวจสอบย้อนหลังที่ละเอียดขึ้น ให้วางแผนไว้โดยตรง เช่น ใช้ CloudTrail เพิ่มการบันทึก หรือแยก role สำหรับแต่ละเวิร์กโฟลว์