Kubernetes ရှိ လုံခြုံရေး ABC- အထောက်အထားပြခြင်း၊ ခွင့်ပြုချက်၊ စာရင်းစစ်ခြင်း။

များမကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် မည်သည့်စနစ်၏လည်ပတ်မှုတွင်မဆို လုံခြုံရေးပြဿနာ ပေါ်ပေါက်လာသည်- စစ်မှန်ကြောင်းသေချာစေရန်၊ လုပ်ပိုင်ခွင့်များကို ခွဲထုတ်ခြင်း၊ စာရင်းစစ်ခြင်းနှင့် အခြားလုပ်ငန်းတာဝန်များကို ဆောင်ရွက်ခြင်း။ Kubernetes အတွက် ဖန်တီးပြီးဖြစ်သည်။ ဖြေရှင်းချက်များစွာအလွန်တောင်းဆိုနေသော ပတ်ဝန်းကျင်များတွင်ပင် စံချိန်စံညွှန်းများနှင့်အညီ လိုက်လျောညီထွေဖြစ်စေရန် ခွင့်ပြုပေးသော... ပစ္စည်းသည် K8s ၏ တပ်ဆင်ထားသော ယန္တရားများအတွင်း အကောင်အထည်ဖော်ဆောင်ရွက်သည့် လုံခြုံရေး၏ အခြေခံကဏ္ဍများအတွက် တူညီသောပစ္စည်းကို မြှုပ်နှံထားသည်။ ပထမဦးစွာ၊ လုံခြုံရေးဆိုင်ရာ ပြဿနာများကို လေ့လာခြင်းအတွက် အစမှတ်အဖြစ် Kubernetes ကို စတင်သိရှိလာသူများအတွက် အသုံးဝင်ပါလိမ့်မည်။

စစ်မှန်ကြောင်းအထောက်အထားပြသခြင်း

Kubernetes တွင် အသုံးပြုသူ နှစ်မျိုးရှိသည်။

• ဝန်ဆောင်မှုအကောင့်များ — Kubernetes API မှ စီမံခန့်ခွဲသော အကောင့်များ။
• အသုံးပြုသူများသည် — ပြင်ပ၊ အမှီအခိုကင်းသော ဝန်ဆောင်မှုများမှ စီမံခန့်ခွဲသော "သာမန်" အသုံးပြုသူများ။

ဤအမျိုးအစားများအကြား အဓိကကွာခြားချက်မှာ ဝန်ဆောင်မှုအကောင့်များအတွက် Kubernetes API တွင် အထူးအရာဝတ္ထုများ ရှိသည် (၎င်းတို့ကို ၎င်းဟုခေါ်သည် - ServiceAccounts) namespace နှင့် လျှို့ဝှက်ချက်များ အမျိုးအစား၏ အရာဝတ္ထုများတွင် အစုအဝေးတွင် သိမ်းဆည်းထားသော ခွင့်ပြုချက်ဒေတာအစုတစ်ခုနှင့် ချိတ်ဆက်ထားသည်။ ထိုသို့သောအသုံးပြုသူများ (ဝန်ဆောင်မှုအကောင့်များ) သည် Kubernetes အစုအဝေးအတွင်း လုပ်ဆောင်နေသည့် လုပ်ငန်းစဉ်များ၏ Kubernetes API သို့ ဝင်ရောက်ခွင့်ကို စီမံခန့်ခွဲရန် အဓိကရည်ရွယ်ပါသည်။

သာမန်အသုံးပြုသူများသည် Kubernetes API တွင် ထည့်သွင်းမှုများမရှိပါ- ၎င်းတို့ကို ပြင်ပယန္တရားများဖြင့် စီမံခန့်ခွဲရမည်ဖြစ်သည်။ ၎င်းတို့သည် အစုအဖွဲ့ပြင်ပတွင်နေထိုင်သော လူများ သို့မဟုတ် လုပ်ငန်းစဉ်များအတွက် ရည်ရွယ်ပါသည်။

API တောင်းဆိုမှုတစ်ခုစီသည် ဝန်ဆောင်မှုအကောင့်တစ်ခု၊ အသုံးပြုသူတစ်ဦးနှင့် ဆက်စပ်နေသည် သို့မဟုတ် အမည်မသိဟု ယူဆပါသည်။

အသုံးပြုသူ စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းဒေတာ ပါဝင်သည်-

• username — အသုံးပြုသူအမည် (အသေးအဖွဲ!);
• UID - "အသုံးပြုသူအမည်ထက် ပို၍ တသမတ်တည်းရှိပြီး ထူးခြားသည်" ဟူသော စက်ဖြင့်ဖတ်နိုင်သော အသုံးပြုသူသတ်မှတ်ရေးစာကြောင်း၊
• အဖွဲ့များ - အသုံးပြုသူပိုင်ဆိုင်သည့်အုပ်စုများစာရင်း။
• အပို - ခွင့်ပြုချက်ယန္တရားဖြင့် အသုံးပြုနိုင်သည့် အပိုအကွက်များ။

Kubernetes သည် အထောက်အထားစိစစ်ခြင်း ယန္တရားအများအပြားကို သုံးနိုင်သည်- X509 လက်မှတ်များ၊ Bearer တိုကင်များ၊ proxy စစ်မှန်ကြောင်းအထောက်အထား၊ HTTP Basic Auth။ ဤယန္တရားများကိုအသုံးပြုခြင်းဖြင့်၊ သင်သည် ခွင့်ပြုချက်အစီအစဥ်အများအပြားကို အကောင်အထည်ဖော်နိုင်သည်- စကားဝှက်များပါသည့် အငြိမ်ဖိုင်မှ OpenID OAuth2 အထိ။

ထို့အပြင်၊ ခွင့်ပြုချက်အစီအစဥ်များစွာကို တစ်ပြိုင်နက် အသုံးပြုနိုင်သည်။ မူရင်းအားဖြင့်၊ အစုအဖွဲ့သည်-

• ဝန်ဆောင်မှုအကောင့်တိုကင်များ - ဝန်ဆောင်မှုအကောင့်များအတွက်;
• X509 - အသုံးပြုသူများအတွက်။

ServiceAccounts များကို စီမံခန့်ခွဲခြင်းဆိုင်ရာ မေးခွန်းသည် ဤဆောင်းပါး၏ ဘောင်ကျော်လွန်သော်လည်း ဤကိစ္စကို ပိုမိုအသေးစိတ်သိရှိလိုသူများအတွက်၊ ကျွန်ုပ်အနေဖြင့် စတင်ရန် အကြံပြုလိုပါသည်။ တရားဝင်စာရွက်စာတမ်းစာမျက်နှာများ. X509 လက်မှတ်များ မည်သို့အလုပ်လုပ်ပုံ ပြဿနာကို ကျွန်ုပ်တို့ အနီးကပ်လေ့လာပါမည်။

သုံးစွဲသူများအတွက် လက်မှတ်များ (X.509)

လက်မှတ်များနှင့် လုပ်ဆောင်ခြင်း၏ ဂန္တဝင်နည်းလမ်းတွင် ပါဝင်သည်-

• အဓိကမျိုးဆက်-

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• လက်မှတ်တောင်းဆိုမှုကို ဖန်တီးနေသည်-

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• အသုံးပြုသူလက်မှတ်ရရှိရန် Kubernetes အစုအဝေး CA သော့များကို အသုံးပြု၍ လက်မှတ်တောင်းဆိုမှုကို လုပ်ဆောင်ခြင်း (လက်မှတ်တစ်ခုရယူရန်၊ ပုံမှန်အားဖြင့် Kubernetes အစုအဝေး CA သော့ကို အသုံးပြုခွင့်ရှိသည့် အကောင့်ကို အသုံးပြုရမည်ဖြစ်ပြီး၊ /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500

• configuration file တစ်ခုကို ဖန်တီးခြင်း-
  • အစုအဝေးဖော်ပြချက် (တိကျသောအစုအဝေးတပ်ဆင်မှုအတွက် CA လက်မှတ်ဖိုင်၏လိပ်စာနှင့် တည်နေရာကို သတ်မှတ်ပါ)။

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • ဒါမှမဟုတ် ဘယ်လိုလဲ။ မဟုတ်အကြံပြုထားသောရွေးချယ်မှု - သင်သည် root လက်မှတ်ကို သတ်မှတ်ရန် မလိုအပ်ပါ (ထို့နောက် kubectl သည် အစုအဝေး၏ api-ဆာဗာ၏ မှန်ကန်မှုကို စစ်ဆေးမည်မဟုတ်ပါ)။

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • အသုံးပြုသူအား ဖွဲ့စည်းမှုပုံစံဖိုင်သို့ ထည့်သွင်းခြင်း-

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • အကြောင်းအရာကို ထည့်သွင်းခြင်း-

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • မူရင်းအကြောင်းအရာတာဝန်-

    kubectl config use-context mynewuser-context

အထက်ပါ manipulations ပြီးနောက်, ဖိုင်ထဲမှာ .kube/config ဤကဲ့သို့သော config ကိုဖန်တီးလိမ့်မည်-

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

အကောင့်များနှင့် ဆာဗာများအကြား config ကို လွှဲပြောင်းရန် ပိုမိုလွယ်ကူစေရန်၊ အောက်ပါသော့များ၏ တန်ဖိုးများကို တည်းဖြတ်ရန် အသုံးဝင်သည်-

• certificate-authority
• client-certificate
• client-key

ဒါကိုလုပ်ဖို့၊ base64 ကိုအသုံးပြုပြီး သတ်မှတ်ထားတဲ့ဖိုင်တွေကို encode လုပ်ပြီး config မှာ စာရင်းသွင်းနိုင်ပြီး သော့အမည်ရဲ့ နောက်ဆက်တွဲကို ထည့်နိုင်ပါတယ်။ -data, i.e. ခံယူပြီး certificate-authority-data စသည်တို့ကို

kubeadm နှင့် အောင်လက်မှတ်များ

လွတ်မြောက်ခြင်းနှင့်အတူ ကူဘာနက် 1.15 ၎င်း၏ပံ့ပိုးမှု၌ရှိသော alpha ဗားရှင်းကြောင့် လက်မှတ်များနှင့် အလုပ်လုပ်ရာတွင် ပိုမိုလွယ်ကူလာသည်။ kubeadm အသုံးဝင်မှု. ဥပမာအားဖြင့်၊ ဤသည်မှာ အသုံးပြုသူကီးများဖြင့် ဖွဲ့စည်းမှုပုံစံဖိုင်ကို ယခုဖန်တီးနေသည့်အရာဖြစ်သည်-

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: လိုအပ်သည် လိပ်စာကြော်ငြာပါ။ ပုံသေအားဖြင့်တည်ရှိသော api-server config တွင်တွေ့နိုင်သည်။ /etc/kubernetes/manifests/kube-apiserver.yaml.

ရရှိလာသော config သည် stdout သို့ output ဖြစ်လိမ့်မည်။ ထဲတွင် သိမ်းဆည်းထားရန် လိုအပ်ပါသည်။ ~/.kube/config အသုံးပြုသူ အကောင့် သို့မဟုတ် ပတ်၀န်းကျင် ပြောင်းလဲသတ်မှတ်နိုင်သော ဖိုင်တစ်ခုသို့ KUBECONFIG.

နက်ရှိုင်းစွာတူးပါ။

ဖော်ပြပါကိစ္စရပ်များကို ပိုမိုနားလည်သဘောပေါက်လိုသူများအတွက်

• သီးခြားဆောင်းပါး တရားဝင် Kubernetes စာရွက်စာတမ်းများတွင် လက်မှတ်များနှင့် လုပ်ဆောင်ခြင်းအပေါ်၊
• Bitnami မှဆောင်းပါးကောင်းလက်မှတ်ထုတ်ပေးသည့်ကိစ္စကို လက်တွေ့ကျသောရှုထောင့်မှ ထိတွေ့ကိုင်တွယ်သည်။
• အထွေထွေစာရွက်စာတမ်း Kubernetes တွင် စစ်မှန်ကြောင်းအထောက်အထားပြခြင်း

အခွင့်အာဏာပေးခြင်း

မူရင်းခွင့်ပြုထားသောအကောင့်သည် အစုအဝေးတွင် လုပ်ဆောင်ပိုင်ခွင့်မရှိပါ။ ခွင့်ပြုချက်များပေးရန်အတွက် Kubernetes သည် ခွင့်ပြုချက်ယန္တရားကို အကောင်အထည်ဖော်သည်။

ဗားရှင်း 1.6 မတိုင်မီတွင် Kubernetes ဟုခေါ်သော ခွင့်ပြုချက်အမျိုးအစားကို အသုံးပြုခဲ့သည်။ ABAC (Attribute-based access control)။ ၎င်းနှင့်ပတ်သက်သည့်အသေးစိတ်အချက်အလက်များကို တွင် ကြည့်ရှုနိုင်ပါသည်။ တရားဝင်စာရွက်စာတမ်း. ဤနည်းလမ်းကို လောလောဆယ်တွင် အမွေအနှစ်အဖြစ် ယူဆထားသော်လည်း ၎င်းကို အခြားအထောက်အထားစိစစ်ခြင်းအမျိုးအစားများနှင့်အတူ သင်အသုံးပြုနိုင်သေးသည်။

အသုံးပြုခွင့်အခွင့်အရေးများကို အစုအဖွဲ့တစ်ခုသို့ ခွဲဝေပေးသည့် လက်ရှိ (နှင့် ပိုမိုပြောင်းလွယ်ပြင်လွယ်) နည်းလမ်းကို ခေါ်သည်။ RBAC (အခန်းကဏ္ based အခြေခံ access ကိုထိန်းချုပ်) ဗားရှင်းကတည်းက တည်ငြိမ်ကြောင်း ကြေညာထားသည်။ ကူဘာနက် 1.8. RBAC သည် အထူးတလည် ခွင့်မပြုသည့်အရာအားလုံးကို တားမြစ်ထားသည့် အခွင့်အရေးပုံစံကို အကောင်အထည်ဖော်သည်။
RBAC ကိုဖွင့်ရန်သင်သည် ကန့်သတ်ချက်ဖြင့် Kubernetes api-ဆာဗာကို စတင်ရန် လိုအပ်သည်။ --authorization-mode=RBAC. ပုံမှန်အားဖြင့် လမ်းကြောင်းတစ်လျှောက်တွင်ရှိသော api-server configuration ဖြင့် ဘောင်များကို မန်နီးဖက်စ်တွင် သတ်မှတ်ထားသည် /etc/kubernetes/manifests/kube-apiserver.yamlအပိုင်း command. သို့သော်၊ RBAC ကို မူရင်းအတိုင်းဖွင့်ထားပြီးဖြစ်သောကြောင့် ဖြစ်နိုင်ချေများသောကြောင့် ၎င်းကို သင်စိတ်မပူသင့်ပါ- ၎င်းကို တန်ဖိုးအားဖြင့် သင်စစ်ဆေးနိုင်ပါသည်။ authorization-mode (ဖော်ပြပြီးသားထဲမှာ kube-apiserver.yaml) စကားမစပ်၊ ၎င်း၏အဓိပ္ပါယ်များကြားတွင် အခြားခွင့်ပြုချက်အမျိုးအစားများ ရှိနိုင်သည် (node, webhook, always allow) သို့သော် ကျွန်ုပ်တို့သည် ပစ္စည်း၏ ဘောင်အပြင်ဘက်တွင် ၎င်းတို့၏ ထည့်သွင်းစဉ်းစားမှုကို ချန်ထားခဲ့ပါမည်။

စကားမစပ်၊ ကျွန်တော်တို့ ထုတ်ပြန်ပြီးသားပါ။ ဆောင်းပါး RBAC နှင့် လက်တွဲလုပ်ဆောင်ခြင်းဆိုင်ရာ အခြေခံမူများနှင့် အင်္ဂါရပ်များအကြောင်း မျှတသောအသေးစိတ်ဖော်ပြချက်နှင့်အတူ၊ ထို့ကြောင့် ကျွန်ုပ်သည် အခြေခံများနှင့် ဥပမာများကို အတိုချုံးဖော်ပြရန် ကျွန်ုပ်ကိုယ်တိုင် ကန့်သတ်လိုက်ပါမည်။

RBAC မှတဆင့် Kubernetes တွင်ဝင်ရောက်ခွင့်ကိုထိန်းချုပ်ရန်အတွက်အောက်ပါ API များကိုအသုံးပြုသည်-

• Role и ClusterRole — ဝင်ရောက်ခွင့်ဆိုင်ရာ အခွင့်အရေးများကို ဖော်ပြရန် ဆောင်ရွက်ပေးသည့် အခန်းကဏ္ဍများ-
• Role namespace တစ်ခုအတွင်း အခွင့်အရေးများကို ဖော်ပြရန် သင့်အား ခွင့်ပြုသည်။
• ClusterRole - အစုအဝေးအတွင်း၊ nodes၊ အရင်းအမြစ်မဟုတ်သော url များကဲ့သို့သော အစုအဝေးမှ သီးခြားအရာဝတ္ထုများအပါအဝင် (ဆိုလိုသည်မှာ Kubernetes အရင်းအမြစ်များနှင့် မသက်ဆိုင်ပါ - ဥပမာ၊ /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - ချည်နှောင်ရာတွင် အသုံးပြုသည်။ Role и ClusterRole သုံးစွဲသူ၊ သုံးစွဲသူအုပ်စု သို့မဟုတ် ServiceAccount သို့။

Role နှင့် RoleBinding entities များကို namespace ဖြင့် ကန့်သတ်ထားပါသည်။ တူညီသော namespace အတွင်းရှိရပါမည်။ သို့သော်လည်း၊ RoleBinding သည် သင့်အား ယေဘူယျခွင့်ပြုချက်အစုအဝေးတစ်ခုဖန်တီးရန်နှင့် ၎င်းတို့ကိုအသုံးပြု၍ ဝင်ရောက်ထိန်းချုပ်နိုင်စေသည့် ClusterRole ကိုကိုးကားနိုင်သည်။

အခန်းကဏ္ဍများပါဝင်သော စည်းမျဥ်းစည်းကမ်းများကို အသုံးပြု၍ အခွင့်အရေးများကို ဖော်ပြသည်-

• API အဖွဲ့များ - ကြည့်ပါ။ တရားဝင်စာရွက်စာတမ်း apiGroups နှင့် output အားဖြင့် kubectl api-resources;
• အရင်းအမြစ်များ (အရင်းမြစ်များ: pod, namespace, deployment နောက် ... ပြီးတော့။);
• ကြိယာများ (ကြိယာများ: set, update နောက် ... ပြီးတော့။)။
• အရင်းအမြစ်အမည်များ (resourceNames) - ဤအမျိုးအစား၏ အရင်းအမြစ်အားလုံးကို မဟုတ်ဘဲ သီးခြားအရင်းအမြစ်တစ်ခုသို့ ဝင်ရောက်ခွင့်ပေးရန် လိုအပ်သည့်အခါ ကိစ္စရပ်အတွက်။

Kubernetes ရှိ ခွင့်ပြုချက်၏ အသေးစိတ်ခွဲခြမ်းစိတ်ဖြာမှုကို စာမျက်နှာပေါ်တွင် တွေ့ရှိနိုင်သည်။ တရားဝင်စာရွက်စာတမ်း. အဲဒီအစား (ဒါမှမဟုတ် ဒီ့အပြင်) သူ့အလုပ်တွေကို ဥပမာပေးမယ်။

RBAC အဖွဲ့အစည်းများ၏ ဥပမာများ

လွယ်ကူသော Role၎င်းသည် သင့်အား pods များ၏ စာရင်းနှင့် အခြေအနေကို ရယူနိုင်ပြီး namespace တွင် ၎င်းတို့ကို စောင့်ကြည့်နိုင်သည်။ target-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

နမူနာ ClusterRolepods များ၏ စာရင်းနှင့် အခြေအနေကို ရယူနိုင်ပြီး အစုအဝေးတစ်ခုလုံးကို စောင့်ကြည့်နိုင်စေသည်-

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

နမူနာ RoleBindingအသုံးပြုသူကိုခွင့်ပြုပေးသော mynewuser namespace တွင် "ဖတ်" pods များ my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

ပွဲစာရင်းစစ်

ဇယားကွက်အရ Kubernetes ဗိသုကာလက်ရာကို အောက်ပါအတိုင်း ကိုယ်စားပြုနိုင်သည်-

တောင်းဆိုမှုများကို လုပ်ဆောင်ခြင်းအတွက် အဓိက တာဝန်ရှိသော Kubernetes အစိတ်အပိုင်းမှာ ဖြစ်သည် api-ဆာဗာ. အစုအဝေးရှိ လုပ်ဆောင်မှုအားလုံးသည် ၎င်းကိုဖြတ်သန်းသည်။ ဆောင်းပါးတွင် ဤပြည်တွင်းရေးယန္တရားများအကြောင်း ပိုမိုဖတ်ရှုနိုင်ပါသည်kubectl run သောအခါတွင် Kubernetes တွင် ဘာဖြစ်သွားသနည်း။"။

စနစ်စစ်ဆေးမှုသည် ပုံမှန်အားဖြင့် ပိတ်ထားသည့် Kubernetes တွင် စိတ်ဝင်စားဖွယ်ကောင်းသော အင်္ဂါရပ်တစ်ခုဖြစ်သည်။ ၎င်းသည် သင့်အား Kubernetes API သို့ ခေါ်ဆိုမှုအားလုံးကို မှတ်တမ်းတင်ရန် ခွင့်ပြုသည်။ သင်ခန့်မှန်းထားသည့်အတိုင်း၊ စောင့်ကြည့်ခြင်းနှင့် အစုအဝေး၏အခြေအနေပြောင်းလဲခြင်းဆိုင်ရာ လုပ်ဆောင်ချက်အားလုံးကို ဤ API မှတစ်ဆင့် လုပ်ဆောင်ပါသည်။ ၎င်း၏စွမ်းဆောင်နိုင်မှုအကြောင်း ကောင်းကောင်းဖော်ပြချက်ကို (ပုံမှန်အတိုင်း) တွင် တွေ့ရှိနိုင်သည်။ တရားဝင်စာရွက်စာတမ်း K8s ဆက်လက်၍ ခေါင်းစဉ်ကို ပိုမိုရိုးရှင်းသော ဘာသာစကားဖြင့် တင်ပြရန် ကြိုးစားပါမည်။

ထို့ကြောင့် စာရင်းစစ်ဖွင့်ရန်အောက်ပါအသေးစိတ်တွင်ဖော်ပြထားသော api-server ရှိကွန်တိန်နာသို့လိုအပ်သော parameter သုံးခုကိုကျွန်ုပ်တို့ဖြတ်သန်းရန်လိုအပ်သည်၊

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

ဤလိုအပ်သော ကန့်သတ်ဘောင်သုံးခုအပြင်၊ စာရင်းစစ်ခြင်းနှင့်ပတ်သက်သည့် နောက်ထပ်ဆက်တင်များစွာပါရှိသည်- မှတ်တမ်းလည်ပတ်ခြင်းမှ webhook ဖော်ပြချက်များအထိ။ မှတ်တမ်းလည်ပတ်မှု ကန့်သတ်ချက်များ၏ ဥပမာ-

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

သို့သော် ကျွန်ုပ်တို့သည် ၎င်းတို့အပေါ်တွင် ပိုမိုအသေးစိတ်နေမည်မဟုတ် - သင်အသေးစိတ်အချက်အလက်များအားလုံးကို သင်ရှာဖွေနိုင်ပါသည်။ kube-apiserver စာရွက်စာတမ်း.

ဖော်ပြထားပြီးဖြစ်သည့်အတိုင်း၊ ကန့်သတ်ချက်များအားလုံးကို api-ဆာဗာဖွဲ့စည်းမှုပုံစံဖြင့် မန်နီးဖက်စ်တွင် သတ်မှတ်ထားသည် (ပုံမှန်အားဖြင့် /etc/kubernetes/manifests/kube-apiserver.yaml), ကဏ္ဍ command. လိုအပ်သော ဘောင် ၃ ခုကို ပြန်၍ ခွဲခြမ်းစိတ်ဖြာကြည့်ကြပါစို့။

1. audit-policy-file — စာရင်းစစ်မူဝါဒကို ဖော်ပြသည့် YAML ဖိုင်သို့ လမ်းကြောင်း။ ကျွန်ုပ်တို့သည် ၎င်း၏အကြောင်းအရာများကို နောက်မှပြန်သွားပါမည်၊ သို့သော် ယခုအချိန်တွင် ဖိုင်ကို api-ဆာဗာလုပ်ငန်းစဉ်ဖြင့် ဖတ်နိုင်ရမည်ကို ကျွန်ုပ်သတိပြုမိပါသည်။ ထို့ကြောင့်၊ config ၏သင့်လျော်သောအပိုင်းများတွင် အောက်ပါကုဒ်များကို သင်ထည့်နိုင်သောကြောင့် ၎င်းကို container အတွင်းတွင် တပ်ဆင်ရန် လိုအပ်ပါသည်။

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - မှတ်တမ်းဖိုင်သို့လမ်းကြောင်း။ လမ်းကြောင်းသည် api-ဆာဗာ လုပ်ငန်းစဉ်တွင်လည်း ဝင်ရောက်နိုင်ရမည်၊ ထို့ကြောင့် ၎င်း၏ တပ်ဆင်ခြင်းကို အလားတူနည်းဖြင့် ဖော်ပြထားပါသည်။

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format - စာရင်းစစ်မှတ်တမ်းပုံစံ။ ပုံသေကား jsonသို့သော် အမွေအနှစ် စာသားဖော်မတ်ကိုလည်း ရနိုင်သည် (legacy).

စာရင်းစစ်မူဝါဒ

ယခု မှတ်တမ်းရေးခြင်းမူဝါဒကို ဖော်ပြသည့် ဖော်ပြထားသော ဖိုင်အကြောင်း။ စာရင်းစစ်မူဝါဒ၏ ပထမသဘောတရားမှာ၊ level, သစ်ထုတ်လုပ်ရေးအဆင့်. ၎င်းတို့မှာ အောက်ပါအတိုင်းဖြစ်သည်။

• None - မှတ်တမ်းမတင်ပါနှင့်။
• Metadata — မှတ်တမ်းတောင်းဆိုမှု မက်တာဒေတာ- အသုံးပြုသူ၊ တောင်းဆိုချိန်၊ ပစ်မှတ်ရင်းမြစ် (pod၊ namespace စသည်)၊ လုပ်ဆောင်ချက်အမျိုးအစား (ကြိယာ) စသည်တို့။
• Request - မှတ်တမ်း metadata နှင့်တောင်းဆိုမှုကိုယ်ထည်;
• RequestResponse — မက်တာဒေတာမှတ်တမ်း၊ တောင်းဆိုချက်ကိုယ်ထည်နှင့် တုံ့ပြန်မှုကိုယ်ထည်။

နောက်ဆုံးအဆင့်နှစ်ခု (Request и RequestResponse) အရင်းအမြစ်များကို မဝင်ရောက်နိုင်သော တောင်းဆိုချက်များကို မှတ်တမ်းမတင်ပါနှင့် (အရင်းအမြစ်မဟုတ်သော url များဟု ခေါ်သည်) သို့ ဝင်ရောက်ခြင်းမပြုပါနှင့်။

တောင်းဆိုမှုအားလုံးလည်း ပြီးသွားပါပြီ။ အဆင့်များစွာ:

• RequestReceived - ပရိုဆက်ဆာမှ တောင်းဆိုချက်ကို လက်ခံရရှိပြီး ပရိုဆက်ဆာများ၏ ကွင်းဆက်တစ်လျှောက် ထပ်မံမပို့ရသေးသည့် အဆင့်၊
• ResponseStarted — တုံ့ပြန်မှု ခေါင်းစီးများကို ပေးပို့သော်လည်း တုံ့ပြန်မှုကိုယ်ထည်ကို မပေးပို့မီ။ ရေရှည်မေးခွန်းများအတွက် ထုတ်လုပ်ခဲ့သည် (ဥပမာ၊ watch);
• ResponseComplete - တုံ့ပြန်မှုအဖွဲ့ကို ပေးပို့ထားပြီး၊ နောက်ထပ် အချက်အလက် ပေးပို့မည်မဟုတ်ပါ။
• Panic — ပုံမှန်မဟုတ်သော အခြေအနေတစ်ခုကို တွေ့ရှိသောအခါ အဖြစ်အပျက်များကို ထုတ်ပေးသည်။

မည်သည့်အဆင့်များကိုမဆို ကျော်ရန် သင်သုံးနိုင်သည်။ omitStages.

မူဝါဒဖိုင်တစ်ခုတွင်၊ ကျွန်ုပ်တို့သည် မတူညီသော မှတ်တမ်းအဆင့်များဖြင့် ကဏ္ဍများစွာကို ဖော်ပြနိုင်ပါသည်။ မူဝါဒဖော်ပြချက်တွင် တွေ့ရသော ပထမကိုက်ညီသော စည်းမျဉ်းကို ကျင့်သုံးပါမည်။

kubelet daemon သည် api-server configuration ဖြင့် manifest တွင်ပြောင်းလဲမှုများကိုစောင့်ကြည့်ပြီးတွေ့ရှိပါက၊ ကွန်တိန်နာကို api-server ဖြင့်ပြန်လည်စတင်သည်။ ဒါပေမယ့် အရေးကြီးတဲ့အသေးစိတ်တစ်ခုရှိပါတယ်။ မူဝါဒဖိုင်တွင် အပြောင်းအလဲများကို ၎င်းမှ လျစ်လျူရှုပါမည်။. မူဝါဒဖိုင်ကို အပြောင်းအလဲများ ပြုလုပ်ပြီးနောက်၊ သင်သည် api-ဆာဗာကို ကိုယ်တိုင် ပြန်လည်စတင်ရန် လိုအပ်မည်ဖြစ်သည်။ api-server သည် as start ဖြစ်သောကြောင့်ဖြစ်သည်။ static pod, အသင်းအဖွဲ့ kubectl delete ၎င်းကို restart လုပ်မည်မဟုတ်ပါ။ သင်ကိုယ်တိုင်ပြုလုပ်ရပါမည်။ docker stop စာရင်းစစ်မူဝါဒကို ပြောင်းလဲထားသည့် kube-masters တွင်-

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

စာရင်းစစ်ကိုဖွင့်သောအခါ၊ ၎င်းကိုမှတ်မိရန်အရေးကြီးသည်။ kube-apiserver တွင်ဝန်တိုးလာသည်။. အထူးသဖြင့်၊ တောင်းဆိုမှုအကြောင်းအရာကို သိမ်းဆည်းရန်အတွက် မှတ်ဉာဏ်သုံးစွဲမှု တိုးလာသည်။ တုံ့ပြန်မှု ခေါင်းစီးကို ပေးပို့ပြီးမှသာ မှတ်တမ်းရယူခြင်း စတင်သည်။ ဝန်သည် စာရင်းစစ်မူဝါဒဖွဲ့စည်းပုံအပေါ်မူတည်ပါသည်။

မူဝါဒများ ဥပမာများ

ဥပမာများကို အသုံးပြု၍ မူဝါဒဖိုင်များ၏ ဖွဲ့စည်းပုံကို ကြည့်ကြပါစို့။

ဒါကတော့ ရိုးရိုးဖိုင်လေးပါ။ policyအဆင့်မှာ အရာအားလုံးကို မှတ်တမ်းတင်ဖို့ Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

မူဝါဒတွင် သင်သည် အသုံးပြုသူများစာရင်းကို သတ်မှတ်နိုင်သည် (Users и ServiceAccounts) နှင့် အသုံးပြုသူအုပ်စုများ။ ဥပမာအားဖြင့်၊ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် စနစ်အသုံးပြုသူများကို လျစ်လျူရှုမည်ဖြစ်သော်လည်း အခြားအရာအားလုံးကို အဆင့်တွင် မှတ်တမ်းတင်ပါ။ Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

ပစ်မှတ်များကို ဖော်ပြရန်လည်း ဖြစ်နိုင်သည်-

• အမည်နေရာများ (namespaces);
• ကြိယာများ (ကြိယာများ: get, update, delete နှင့်အခြားသူများ);
• အရင်းအမြစ်များ (အရင်းမြစ်များ, အမည်: pod, configmaps စသည်တို့) နှင့် အရင်းအမြစ်အဖွဲ့များ (apiGroups).

အာရုံစိုက်! အရင်းအမြစ်များနှင့် အရင်းအမြစ်အုပ်စုများ (API အုပ်စုများ၊ ဥပမာ apiGroups) များအပြင် အစုအဝေးတွင် ထည့်သွင်းထားသည့် ၎င်းတို့၏ဗားရှင်းများကို ညွှန်ကြားချက်များကို အသုံးပြု၍ ရယူနိုင်ပါသည်။

kubectl api-resources
kubectl api-versions

အောက်ဖော်ပြပါ စာရင်းစစ်မူဝါဒကို အကောင်းဆုံးအလေ့အကျင့်များ၏ သရုပ်ပြမှုအဖြစ် ပံ့ပိုးထားပါသည်။ Alibaba Cloud စာတမ်းပြုစုခြင်း။:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для стандартных ресурсов API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

စာရင်းစစ်မူဝါဒ၏ နောက်ထပ်ကောင်းသော ဥပမာတစ်ခုဖြစ်သည်။ GCE တွင်အသုံးပြုသောပရိုဖိုင်.

စာရင်းစစ်ဖြစ်ရပ်များကို အမြန်တုံ့ပြန်ရန်၊ ဖြစ်နိုင်သည်။ webhook ကိုဖော်ပြပါ။. ဤပြဿနာကို ဖုံးကွယ်ထားသည်။ တရားဝင်စာရွက်စာတမ်းဒီဆောင်းပါးရဲ့ ဘောင်အပြင်ကနေ ချန်ထားခဲ့မယ်။

ရလဒ်များကို

ဆောင်းပါးသည် သင့်အား ပုဂ္ဂိုလ်ရေးသီးသန့်ပြုလုပ်ထားသော သုံးစွဲသူအကောင့်များဖန်တီးရန်၊ ၎င်းတို့၏အခွင့်အရေးများကို ခွဲထုတ်ရန်နှင့် ၎င်းတို့၏လုပ်ဆောင်မှုများကို မှတ်တမ်းတင်ရန် ခွင့်ပြုသည့် Kubernetes အစုအဝေးများရှိ အခြေခံလုံခြုံရေးယန္တရားများ၏ ခြုံငုံသုံးသပ်ချက်ကို ပေးပါသည်။ သီအိုရီ သို့မဟုတ် လက်တွေ့တွင် ထိုသို့သော ပြဿနာများနှင့် ရင်ဆိုင်ရသူများအတွက် အသုံးဝင်လိမ့်မည်ဟု မျှော်လင့်ပါသည်။ “PS” တွင်ပေးထားသည့် Kubernetes ရှိ လုံခြုံရေးဆိုင်ရာ အကြောင်းအရာဆိုင်ရာ အခြားပစ္စည်းများစာရင်းကို ဖတ်ရန်လည်း အကြံပြုလိုပါသည် - ၎င်းတို့တွင် သင့်နှင့်သက်ဆိုင်သည့် ပြဿနာများအတွက် လိုအပ်သောအသေးစိတ်အချက်အလက်များကို သင်တွေ့နိုင်မည်ဖြစ်သည်။

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «33+ Kubernetes လုံခြုံရေးကိရိယာများ";
• «လုံခြုံရေးကျွမ်းကျင်သူများအတွက် Kubernetes ကွန်ရက်မူဝါဒများကို မိတ်ဆက်ခြင်း။";
• «Kubernetes ရှိ RBAC နားလည်ခြင်း။";
• «Kubernetes လုံခြုံရေးအတွက် အကောင်းဆုံး အလေ့အကျင့် ၉ ခု";
• «Kubernetes ဟက်ကာ၏ သားကောင်ဖြစ်ရန် (မပြုရန်) နည်းလမ်း 11 ခု"။

source: www.habr.com