ပုံမှန်အားဖြင့် AWS servicesတွေဖြစ်တဲ့s3 bucketကိုသုံးကြတဲ့အခါ ဥပမာ web application တစ်ခု run နေရင် user uploadလုပ်တဲ့ image တွေကို S3 ထဲ သိမ်းတာ၊ application log တွေကို S3 bucket တစ်ခုထဲ daily dump လုပ်ထားတာ၊ ဒါမှမဟုတ် backup file တွေကို EC2ကနေ S3 ထဲ push လုပ်ထားတာမျိုးတွေကိုproject တွေမှာ အမြဲတွေ့ရပါတယ်။အဲ့ဒီလို situation တွေမှာ အများဆုံးတွေ့ရတာက access key တွေကို server ထဲထည့်ပြီး သုံးတာပါ။ လွယ်ပေမယ့် long-term မှာတော့ risk တွေပါလာတတ်ပါတယ်။

ဒီ setupမှာ EC2 instance ကို IAM role မပါတဲ့ state နဲ့ အရင်create လုပ်ထားပါတယ်။ အဲ့ဒီအချိန်မှာEC2 ထဲကနေ aws s3 ls လို command ကို run လိုက်ရင် permission denied ဖြစ်သွားပါလိမ့်မယ်။ developer တစ်ယောက်ကဘာကြောင့် S3 မရလဲ လို့မေးရင် အကြောင်းပြချက်ကရှင်းပါတယ်။ instance ကို ဘာ permission မှမပေးထားသေးလို့ပါ။ Access ဆိုတာ default အနေနဲ့ ရှိရမယ့်အရာ မဟုတ်ဘဲ လိုအပ်မှပဲ ပေးသင့်တဲ့အရာပါပဲ ။

နောက်တစ်ဆင့်မှာတော့ ကျွန်တော်တို့ application data သိမ်းဖို့အတွက် S3 bucket ကို private အနေနဲ့ create လုပ်ထားပါတယ်။ Public access ကိုblock လုပ်ထားပြီး network level မဟုတ်ဘဲ IAM permission အပေါ်မှာပဲ access ကိုcontrol မယ်ဆိုတဲ့ logic ကိုသုံးထားပါတယ်။

S3 ကို access လုပ်ဖို့အတွက် file upload လုပ်ဖို့၊ ပြန်ဖတ်ဖို့၊ bucket ကိုlist လုပ်ဖို့ လိုအပ်တဲ့ permission တွေပါတဲ့IAM policy တစ်ခု createလုပ်ထားပါတယ်။ Instance တစ်လုံး compromiseဖြစ်သွားခဲ့ရင်တောင် attacker ကaccount ထဲက S3 bucketအကုန်လုံးကိုaccess မရအောင်permission ကို controlလိုက်တဲ့အတွက်ကြောင့် impactကြီးမသွားနိုင်ပါဘူး။

ဒီpolicy ကို IAM role တစ်ခုမှာ attach လုပ်ပြီး အဲ့ဒီ role ကို EC2 serviceက assume လုပ်နိုင်အောင် trust policy ထားပေးရပါမယ် ။ Role ကိုattach လုပ်တဲ့အခါ AWS က IMDSv2(Instance Metadata Service v2) ကို သုံးပြီး temporary credential တွေကို instance ထဲမှာ securely provide လုပ်ပေးပါတယ်။ IMDSv2 က session-based token mechanism ကို သုံးထားလို့ SSRF attackလိုမျိုး metadata credential theft risk ကိုအများကြီး လျှော့ချနိုင်ပါတယ်။

Role attach ပြီးတဲ့အခါ EC2 instance ထဲကို SSH ဝင်ပြီး app.log ဒါမှမဟုတ် hello.txtလို text file တစ်ခုကို upload လုပ်ကြည့်ရင် access keyထဲ့စရာမလိုဘဲ uploadဖြစ်သွားပါလိမ့်မယ်။ AWS CLI က IMDSv2 ကနေ temporary credential ကို autoယူပြီး STSအနေနဲ့ request ကို sign လုပ်ပေးပါလိမ့်မယ်။

ဒီနည်းက EC2 တစ်ခုထဲအတွက်တင်မဟုတ်ဘဲ ECS task တွေ S3 ထဲ log ပို့တာ၊ EKS podတွေ config file ကို S3 ကနေ pull လုပ်တာ၊ lambda function က report fileတစ်ခုကို S3 ထဲ generate လုပ်တာမျိုးတွေမှာပါသုံးလို့ရပါတယ်။ Workload တစ်ခုခုကို AWS service တွေနဲ့ connectရင် access key ထည့်မယ့်အစား IAM role ပေးလိုက်တာက AWS Best Practice တစ်ခုပါဘဲ။