MCSO ကိုဘာကြောင့်ရေးဖြစ်ခဲ့လဲ

Secret တွေကို ရိုးရိုး poll တာက အတိုင်းအတာတခုအထိပဲ အလုပ်ဖြစ်ပါတယ်။ ဒီနေ့ခေတ်လို microservice တွေ၊ database တွေ၊ AI, Mailing နဲ့ Messaging Queue တို့လို service တွေကြောင့် infrastructure ကတနေ့ထက်တနေ့ ပိုရှုပ်လာတာနဲ့အမျှ credential management ရဲ့ကဏ္ဍက အရင်ထက် သိသိသာသာ ပိုအရေးပါလာတယ်။ Dev ရော၊ Ops ပါ ဒီတာဝန်ကို ထမ်းရတာ ဆိုပေမယ့် တကယ်တမ်းမှာ secret တွေကို သေချာ rotate လုပ်ဖို့၊ ချရေးမှတ်ထားဖို့၊ သက်ဆိုင်တဲ့ application process တွေကို restart လုပ်ဖို့နဲ့ တခြားဘာညာကွိကွတွေ အကုန်လုံး Ops ကပဲ အမောဆို့နေအောင် လုပ်ရတာပါ။

container orchestration platform တခုဖြစ်တဲ့ kubernetes မှာ Secret အတွက် native support ပါတယ်။ ပြီးတော့ ဒီကနေ့ခေတ် cloud platform တွေကလည်း secret storage တွေကို SAAS အဖြစ်ရောင်းကြတယ်။ အဲဒီ central secret storage တွေမှာ လိုအပ်တဲ့ username, password, token, API key, certificate တို့လို credential တွေအကုန်လုံးကို တနေရာတည်းမှာ လုံလုံခြုံခြုံ သိမ်းလို့ရစေသလို rotation အတွက်လည်း native မရဘူးဆိုရင်တောင် တနည်းနည်းနဲ့ အဆင်​ပြေအောင် လုပ်ထားပေးတယ် (ဥပမာ AWS ပေါ်မှာဆိုရင် Lambda သုံးတာလိုမျိုး)

ဒါပေမယ့် ဒါက ပြဿနာကို တဝက်ပဲဖြေရှင်းရသေးတယ်။ secret တွေကို rotate လုပ်ပြီးတိုင်း runtime environment ထဲမှာသွား update ဖို့နဲ့ အဲဒီ secret အသစ်ကို application တွေက refresh ဖြစ်ဖို့လုပ်ရဦးမယ်။ အလုပ် တကယ်ရှုပ်တာကလည်း ဒီဟာတွေပဲ။ ESO လို project တွေကဒီပြဿနာကို ဖြေရှင်းဖို့ ပေါ်လာခဲ့တယ်။ ဒါပေမယ့် project အများစုက polling သုံးထားတာမို့ secret ခပ်နည်းနည်း cluster တွေမှာ ကိစ္စမရှိပေမယ့် secret ဒါဇင်နဲ့ချီလာတဲ့အခါ intervaled poll (ခဏခဏ query နေတာ) က resource ဖြုန်းတီးရာရောက်သလို traffic noise လည်းထစေတဲ့အပြင် အခန့်မသင့်ရင် rate limit ထိနိုင်တယ်။ တကယ်လို့ secret အသစ်ကို 10 စက္ကန့်ဝန်းကျင်မှာ application ကချက်ချင်း refresh လုပ်ရမယ်။ ခဏခဏလည်း rotate လုပ်နေဖို့လိုတဲ့ healthcare နဲ့ finance system တွေမှာဆိုရင် 5 စက္ကန့်တခါ aggressive polling လုပ်နေရုံကလွဲလို့ တခြားအဖြေမရှိပါဘူး။

MCSO ကိုကျွန်တော်ရေးခဲ့တာ ဒီလိုအ​ခြေအနေတွေကို ဖြေရှင်းဖို့ပါပဲ။ MCSO က kubernetes native ဖြစ်တဲ့အတွက် Secret တွေကို တယောက်ယောက် manual ချိန်းသွားရင် Secret Store ထဲက value အတိုင်း ပြန် reconcile လုပ်ပေးတယ်။ event-driven architecture လည်းဖြစ်တဲ့အတွက် rotation လုပ်မှသာ Secret Store ကို query ပြီး Kubernetes Secret ဆောက်ပေးတယ်။

နောက်တချက်က multi-cluster support ပါတာမို့ cluster ဆယ်ချီ manage လုပ်နေရတဲ့ platform team တွေအတွက် တနေရာတည်းကနေ ထိန်းချုပ်လို့ရမယ်။ ဒီနေရာမှာ engineering detail တခုကို ပြောပြရရင် MCSO ရဲ့ multi-cluster ပုံစံက Argo CD လိုမျိုး source of truth ကနေ state ကိုဖတ်ပြီး target cluster တွေဆီဆက်တိုက် push နေတဲ့ပုံစံ မဟုတ်ပါဘူး။ kubernetes မှာ native ပါပြီးသား long polling http (watches) တွေနဲ့ implement လုပ်ထားတာ​ ဖြစ်တဲ့အတွက် တော်တော်လေး lightweight ဖြစ်တယ်။

ESO တို့လို project တွေနဲ့မတူတာက Secret တန်ဖိုးပြောင်းသွားတဲ့အခါ Deployment, DaemonSet တွေကိုပါ rollout လုပ်ပေးနိုင်တယ်။ အလုပ်အတွက် စစရေးခဲ့တုန်းက AWS ရဲ့ Secrets Manager နဲ့ event-driven အတွက် လိုအပ်မယ့် infrastructure provisioning ကို in-tree implementation ပါခဲ့ပေမယ့် ကိုယ့် fork မှာတော့ MSI နဲ့ MII plugin တွေအဖြစ် ခွဲထုတ်လိုက်ပြီး ပို portable ဖြစ်အောင် support ခဲ့တယ်။ အခုလက်ရှိသုံးလို့ရမယ့် implementation ကတော့ msi-aws (AWS Secrets Manager) နဲ့ mii-aws (Lambda, CloudTrail, S3 Bucket, EventBridge Rule, IAM, SNS) ရှိနှင့်ပြီးသားမို့ AWS ပေါ်မှာဆိုရင် out-of-the-box တန်းသုံးနိုင်တယ်။

mii-aws ကလိုအပ်တဲ့ resource တွေကို create နဲ့ cleanup 2 ခုလုံး လုပ်ပေးနိုင်ပေမယ့် state-aware plugin လည်းဖြစ်တဲ့အတွက် ရှိပြီးသား resource တွေကို သုံးနိုင်တယ်။ အဲဒါကြောင့် လိုအပ်တဲ့ resource တွေကို IaC နဲ့ဆောက်ပြီး plugin ကို privilege မပေးထားတာကောင်းတယ်။ ဒါပေမယ့် အဲဒါက plugin contract မှာ enforce မလုပ်ထားတဲ့အတွက် သက်ဆိုင်ရာ plugin author အပေါ်ပဲ မူတည်မယ်။ အတိုချုပ်ပြောရရင် secret management ကို bash script တွေနဲ့ပဲလုပ်လုပ်၊ ESO ပဲသုံးသုံး၊ MCSO သုံးသုံး အဓိကက operation ကိုတနေတနေ့ ဒါတွေနဲ့ပဲ အချိန်မကုန်နေစေဖို့က ကျွန်တော်တို့ platform engineer တွေရဲ့ တာဝန်ဖြစ်ပါတယ်။