Security — API Keys, Roles, TLS

နားလည်ထားရမယ့် အချက်

Lesson 3 ကနေစပြီး ဒီ course တစ်ခုလုံးမှာ `xpack.security.enabled=false` ဖြင့် dev container run ခဲ့ပေမယ့် production မှာတော့ security ကို disable လုံးဝ မလုပ်ရပါ—username/password authentication အပြင် API keys ကိုပါ granular access control အတွက် သုံးရပါတယ်။ API key ဆိုတာ user credential တစ်ခုလို ကြာရှည်မသုံးဘဲ short-lived (expiry သတ်မှတ်နိုင်) permission scope ကို narrow ချထားနိုင်တဲ့ token တစ်ခုဖြစ်ပြီး application service တစ်ခုစီအတွက် သီးသန့် key ထုတ်ပေးလို့ credential ကို service များအကြား share ခြင်း (single point of failure) ကို ရှောင်ချင်လို့ပါ။ Role-based access control (RBAC) ကတော့ user/API key တစ်ခုစီကို role တစ်ခု (ဥပမာ "search-readonly") assign ပေးပြီး role တစ်ခုစီမှာ index-level permission (ဘယ် index ကို read/write လုပ်ခွင့်ရှိလဲ) နှင့် document/field-level security (row-level/column-level restriction) ကိုတောင် fine-grained သတ်မှတ်နိုင်ပါတယ်—least-privilege principle (application တစ်ခုစီကို လိုအပ်တဲ့ permission ချည်းသာပေးရမယ်) ကို implement ဖို့ ဒီ mechanism က key ပါ။ TLS ကတော့ client-cluster/node-node communication ကို encrypt လုပ်ပေးလို့ network eavesdropping ကနေ data ကို ကာကွယ်ပေးပါတယ်—Redis course ရဲ့ security lesson မှာ password + network restriction + ACL/TLS ကို ပေါင်းသုံးရမယ်လို့ ရှင်းခဲ့သလိုပဲ Elasticsearch မှာလည်း layer တစ်ခုတည်း (password ချည်း) နဲ့ မလုံလောက်ဘဲ authentication + authorization + encryption layer အားလုံးကို ပေါင်းသုံးရပါတယ်။ ဒါကို office building တစ်ခုရဲ့ security system (badge access = authentication, badge-level room access = authorization/RBAC, locked doors/CCTV = encryption/network controls) နဲ့ တွေးလို့ရပါတယ်။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Tutorial Platform ရဲ့ production Node.js search backend service ကို `tutorials` index ပေါ်မှာ read-only permission ချည်းသာလိုအပ်လို့ "search-readonly" role တစ်ခု ဖန်တီးပြီး ဒီ role ကို API key တစ်ခု generate ပေးမယ်—ဒီ API key ကို environment variable ထဲ သိမ်းပြီး `esClient` config ထဲ pass မယ် (Lesson 15)။ Data-sync worker service (PostgreSQL ကနေ Elasticsearch ဆီ write ဆွဲသောlogic) ကတော့ write permission လိုအပ်လို့ "search-writer" role ပါတဲ့ API key ကို သီးသန့်ထုတ်ပေးမယ်—search backend service ရဲ့ read-only key ကို share သုံးရင် security boundary ပျက်သွားနိုင်ပါတယ်။ Production cluster ကို TLS ဖွင့်ထားမယ်—client library (`esClient`) ရဲ့ `node` URL ကို `https://` ဖြင့် configure ပြီး certificate validation ကိုပါ enable ထားမယ်။

Production security = authentication + authorization + encryption layers ပေါင်းသုံး
API key = service တစ်ခုစီအတွက် scoped/short-lived credential
RBAC role ဖြင့် index-level/field-level least-privilege permission သတ်မှတ်

အတူတူ စမ်းရေးကြည့်မယ်

http

POST /_security/role/search-readonly
{
  "indices": [
    { "names": ["tutorials"], "privileges": ["read"] }
  ]
}

POST /_security/api_key
{
  "name": "tutorial-platform-search-backend",
  "role_descriptors": {
    "search-readonly": {
      "indices": [
        { "names": ["tutorials"], "privileges": ["read"] }
      ]
    }
  },
  "expiration": "90d"
}

You should see

`tutorials` index ပေါ်မှာ read permission ချည်းသာရှိသော role တစ်ခုနှင့် 90 ရက်အတွင်း expire ဖြစ်မည့် scoped API key တစ်ခု ရမည်။

၅ မိနစ် စမ်းကြည့်

PostgreSQL → Elasticsearch sync worker service အတွက် `tutorials` index ပေါ်မှာ write permission ချည်းသာရှိသော role နှင့် API key request ကို ရေးပါ—search backend service ရဲ့ role နှင့် ဘာကွာလဲ ရေးချပါ။

သတိလေးတစ်ချက်

Dev container မှာ `xpack.security.enabled=false` သုံးထားခဲ့တဲ့ habit ကို production deployment ထဲပါ ဆက်ယူသွားခြင်း—cluster တစ်ခုလုံးကို authentication လုံးဝမလိုဘဲ public network ပေါ် expose ဖြစ်သွားနိုင်ပါတယ်။

Service အားလုံးအတွက် single admin-level API key တစ်ခုတည်း share သုံးခြင်း—service တစ်ခု compromise ဖြစ်ရင် cluster ရဲ့ index/permission အားလုံးကို attacker ရနိုင်သွားပါတယ်—service တစ်ခုစီအတွက် scoped key သီးသန့်ထုတ်ရပါမယ်။

Elasticsearch Guide — Secure the Elastic Stack — Elastic