Kubernetes හි ආරක්ෂාව පිළිබඳ ABC: සත්‍යාපනය, අවසරය, විගණනය

ඉක්මනින් හෝ පසුව, ඕනෑම පද්ධතියක ක්රියාකාරිත්වය තුළ, ආරක්ෂාව පිළිබඳ ගැටළුව පැන නගී: සත්යාපනය සහතික කිරීම, අයිතිවාසිකම් වෙන් කිරීම, විගණනය සහ අනෙකුත් කාර්යයන්. දැනටමත් Kubernetes සඳහා නිර්මාණය කර ඇත බොහෝ විසඳුම්, ඉතා ඉල්ලුමක් ඇති පරිසරයන් තුළ පවා ප්‍රමිතීන්ට අනුකූල වීමට ඔබට ඉඩ සලසන ... එම ද්‍රව්‍යයම K8s හි ගොඩනඟන ලද යාන්ත්‍රණ තුළ ක්‍රියාත්මක කරන ලද ආරක්ෂාව පිළිබඳ මූලික අංශ සඳහා කැප කර ඇත. පළමුවෙන්ම, එය Kubernetes සමඟ දැන හඳුනා ගැනීමට පටන් ගන්නා අයට ප්රයෝජනවත් වනු ඇත - ආරක්ෂාව සම්බන්ධ ගැටළු අධ්යයනය කිරීම සඳහා ආරම්භක ලක්ෂ්යයක් ලෙස.

සත්යාපනය

Kubernetes හි භාවිතා කරන්නන් වර්ග දෙකක් ඇත:

• සේවා ගිණුම් - Kubernetes API විසින් කළමනාකරණය කරන ගිණුම්;
• පරිශීලකයන් - "සාමාන්‍ය" පරිශීලකයන් බාහිර, ස්වාධීන සේවා මගින් කළමනාකරණය කරයි.

මෙම වර්ග අතර ඇති ප්‍රධාන වෙනස නම් සේවා ගිණුම් සඳහා Kubernetes API හි විශේෂ වස්තු තිබීමයි (ඒවා හඳුන්වන්නේ - ServiceAccounts), ඒවා නම් අවකාශයක් සහ රහස් වර්ගයේ වස්තූන් තුළ පොකුරේ ගබඩා කර ඇති අවසර දත්ත කට්ටලයකට බැඳී ඇත. එවැනි පරිශීලකයින් (සේවා ගිණුම්) මූලික වශයෙන් අදහස් කරන්නේ Kubernetes පොකුරේ ක්‍රියාත්මක වන ක්‍රියාවලි වල Kubernetes API වෙත ප්‍රවේශ හිමිකම් කළමනාකරණය කිරීමයි.

සාමාන්‍ය පරිශීලකයින්ට Kubernetes API හි ඇතුළත් කිරීම් නොමැත: ඒවා බාහිර යාන්ත්‍රණ මගින් කළමනාකරණය කළ යුතුය. ඒවා පොකුරෙන් පිටත ජීවත්වන පුද්ගලයන් හෝ ක්‍රියාවලි සඳහා අදහස් කෙරේ.

සෑම API ඉල්ලීමක්ම සේවා ගිණුමක්, පරිශීලකයෙකු සමඟ සම්බන්ධ වී ඇත, නැතහොත් නිර්නාමික ලෙස සලකනු ලැබේ.

පරිශීලක සත්‍යාපන දත්ත ඇතුළත් වේ:

• පරිශීලක නාමය - පරිශීලක නාමය (නඩු සංවේදී!);
• UID - "පරිශීලක නාමයට වඩා ස්ථාවර සහ අද්විතීය" යන්ත්‍රයෙන් කියවිය හැකි පරිශීලක හඳුනාගැනීමේ තන්තුවක්;
• කණ්ඩායම් - පරිශීලකයා අයත් වන කණ්ඩායම් ලැයිස්තුව;
• අමතර - අවසර යාන්ත්‍රණය මගින් භාවිතා කළ හැකි අතිරේක ක්ෂේත්‍ර.

Kubernetes හට සත්‍යාපන යාන්ත්‍රණ විශාල සංඛ්‍යාවක් භාවිතා කළ හැක: X509 සහතික, Bearer tokens, Authenticating proxy, HTTP Basic Auth. මෙම යාන්ත්‍රණ භාවිතයෙන්, ඔබට අවසර යෝජනා ක්‍රම විශාල ප්‍රමාණයක් ක්‍රියාත්මක කළ හැක: මුරපද සහිත ස්ථිතික ගොනුවක සිට OpenID OAuth2 දක්වා.

එපමණක් නොව, එකවර අවසර යෝජනා ක්රම කිහිපයක් භාවිතා කළ හැකිය. පෙරනිමියෙන්, පොකුර භාවිතා කරන්නේ:

• සේවා ගිණුම් ටෝකන - සේවා ගිණුම් සඳහා;
• X509 - පරිශීලකයින් සඳහා.

සේවා ගිණුම් කළමනාකරණය පිළිබඳ ප්‍රශ්නය මෙම ලිපියේ විෂය පථයෙන් ඔබ්බට ය, නමුත් මෙම ගැටළුව වඩාත් විස්තරාත්මකව දැන ගැනීමට කැමති අය සඳහා, මම ආරම්භ කිරීමට නිර්දේශ කරමි නිල ලේඛන පිටු. 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 cluster 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

• වින්‍යාස ගොනුවක් නිර්මාණය කිරීම:
  • පොකුරු විස්තරය (නිශ්චිත පොකුරු ස්ථාපනයක් සඳහා CA සහතික ගොනුවේ ලිපිනය සහ ස්ථානය සඳහන් කරන්න):

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

  • නැත්නම් කොහොමද නෑනිර්දේශිත විකල්පය - ඔබට මූල සහතිකය සඳහන් කිරීමට අවශ්‍ය නැත (එවිට 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

ඉහත උපාමාරු වලින් පසුව, ගොනුවේ .kube/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

ගිණුම් සහ සේවාදායකයන් අතර වින්‍යාසය මාරු කිරීම පහසු කිරීම සඳහා, පහත යතුරු වල අගයන් සංස්කරණය කිරීම ප්‍රයෝජනවත් වේ:

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

මෙය සිදු කිරීම සඳහා, ඔබට Base64 භාවිතයෙන් ඒවායේ දක්වා ඇති ගොනු කේතනය කර ඒවා වින්‍යාසය තුළ ලියාපදිංචි කළ හැකිය, යතුරු වල නමට උපසර්ගය එක් කරන්න. -data, i.e. ලැබී ඇත certificate-authority-data හා සමාන ය.

kubeadm සහිත සහතික

මුදා හැරීමත් සමඟ කුබර්නෙට්ස් 1.15 සහතික සමඟ වැඩ කිරීම එහි ඇල්ෆා අනුවාදයට ස්තුති වන්නට පහසු වී ඇත kubeadm උපයෝගීතාව. උදාහරණයක් ලෙස, පරිශීලක යතුරු සමඟ වින්‍යාස ගොනුවක් උත්පාදනය කිරීම දැන් පෙනෙන්නේ මෙයයි:

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

NB: අවශ්යයි ලිපිනය ප්‍රචාරණය කරන්න පෙරනිමියෙන් පිහිටා ඇති api-සේවාදායක වින්‍යාසය තුළ සොයාගත හැකිය /etc/kubernetes/manifests/kube-apiserver.yaml.

ලැබෙන වින්‍යාසය stdout වෙත ප්‍රතිදානය වනු ඇත. එය තුළ සුරැකිය යුතුය ~/.kube/config පරිශීලක ගිණුම හෝ පරිසර විචල්‍යයක සඳහන් කර ඇති ගොනුවකට KUBECONFIG.

ගැඹුරට හාරන්න

විස්තර කර ඇති ගැටළු වඩාත් හොඳින් අවබෝධ කර ගැනීමට කැමති අය සඳහා:

• වෙනම ලිපියක් නිල Kubernetes ලේඛනවල සහතික සමඟ වැඩ කිරීමේදී;
• බිට්නාමිගෙන් හොඳ ලිපියක්, සහතික නිකුත් කිරීම ප්‍රායෝගික දෘෂ්ටිකෝණයකින් ස්පර්ශ කර ඇත.
• සාමාන්ය ලියකියවිලි Kubernetes හි සත්‍යාපනය මත.

අවසරය

පෙරනිමි බලයලත් ගිණුමට පොකුරේ ක්‍රියා කිරීමට අයිතියක් නැත. අවසර ලබා දීමට, Kubernetes අවසර යාන්ත්‍රණයක් ක්‍රියාත්මක කරයි.

1.6 අනුවාදයට පෙර, Kubernetes නම් අවසර වර්ගයක් භාවිතා කළේය ABAC (ගුණාංග පාදක ප්රවේශ පාලනය). ඒ පිළිබඳ විස්තර සොයා ගත හැක නිල ලියකියවිලි. මෙම ප්‍රවේශය දැනට උරුමයක් ලෙස සලකනු ලැබේ, නමුත් ඔබට එය තවමත් වෙනත් සත්‍යාපන වර්ග සමඟ භාවිතා කළ හැක.

පොකුරකට ප්‍රවේශ හිමිකම් බෙදීමේ වත්මන් (සහ වඩාත් නම්‍යශීලී) ක්‍රමය හැඳින්වේ ආර්බීඒසී (භූමිකාව පදනම් කරගත් ප්‍රවේශ පාලනය) අනුවාදයේ සිට එය ස්ථාවර බව ප්‍රකාශ කර ඇත කුබර්නෙට්ස් 1.8. RBAC පැහැදිලිවම අවසර නොලබන සෑම දෙයක්ම තහනම් කර ඇති අයිතිවාසිකම් ආකෘතියක් ක්රියාත්මක කරයි.
RBAC සබල කිරීමට, ඔබ පරාමිතිය සමඟ Kubernetes api-server ආරම්භ කළ යුතුය --authorization-mode=RBAC. පරාමිති api-සේවාදායක වින්‍යාසය සමඟ මැනිෆෙස්ටයේ සකසා ඇත, එය පෙරනිමියෙන් මාර්ගය ඔස්සේ පිහිටා ඇත. /etc/kubernetes/manifests/kube-apiserver.yaml, කොටසේ command. කෙසේ වෙතත්, RBAC දැනටමත් පෙරනිමියෙන් සක්‍රීය කර ඇත, එබැවින් බොහෝ විට ඔබ ඒ ගැන කරදර නොවිය යුතුය: ඔබට මෙය අගය අනුව සත්‍යාපනය කළ හැකිය authorization-mode (දැනටමත් සඳහන් කර ඇති පරිදි kube-apiserver.yaml) මාර්ගය වන විට, එහි අර්ථයන් අතර වෙනත් ආකාරයේ අවසරයන් තිබිය හැකිය (node, webhook, always allow), නමුත් අපි ඔවුන්ගේ සලකා බැලීම ද්රව්යයේ විෂය පථයෙන් පිටත තබමු.

මාර්ගය වන විට, අපි දැනටමත් ප්රකාශයට පත් කර ඇත ලිපිය RBAC සමඟ වැඩ කිරීමේ මූලධර්ම සහ විශේෂාංග පිළිබඳ තරමක් සවිස්තරාත්මක විස්තරයක් සමඟ, තවදුරටත් මම මූලික කරුණු සහ උදාහරණ පිළිබඳ කෙටි ලැයිස්තුවකට සීමා කරමි.

පහත API ආයතන RBAC හරහා Kubernetes හි ප්‍රවේශය පාලනය කිරීමට භාවිතා කරයි:

• Role и ClusterRole - ප්රවේශ අයිතිවාසිකම් විස්තර කිරීමට සේවය කරන භූමිකාවන්:
• Role නාම අවකාශයක් තුළ අයිතිවාසිකම් විස්තර කිරීමට ඔබට ඉඩ සලසයි;
• ClusterRole - පොකුර තුළ, නෝඩ්, සම්පත් නොවන url වැනි පොකුරු-විශේෂිත වස්තු ඇතුළුව (එනම් Kubernetes සම්පත් වලට සම්බන්ධ නොවේ - උදාහරණයක් ලෙස, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - බැඳීම සඳහා භාවිතා වේ Role и ClusterRole පරිශීලකයෙකුට, පරිශීලක කණ්ඩායමකට හෝ සේවා ගිණුමකට.

භූමිකාව සහ භූමිකාව බන්ධන ආයතන නාම අවකාශයෙන් සීමා වේ, i.e. එකම නාම අවකාශය තුළ තිබිය යුතුය. කෙසේ වෙතත්, RoleBinding හට ClusterRole වෙත යොමු විය හැක, එමඟින් ඔබට සාමාන්‍ය අවසර කට්ටලයක් නිර්මාණය කිරීමට සහ ඒවා භාවිතයෙන් ප්‍රවේශය පාලනය කිරීමට ඉඩ සලසයි.

භූමිකාවන් අඩංගු නීති මාලාවක් භාවිතා කරමින් අයිතිවාසිකම් විස්තර කරයි:

• API කණ්ඩායම් - බලන්න නිල ලියකියවිලි apiGroups සහ ප්‍රතිදානය මගින් kubectl api-resources;
• සම්පත් (සම්පත්: pod, namespace, deployment සහ යනාදි.);
• ක්‍රියාපද (ක්‍රියා පද: set, update ආදිය).
• සම්පත් නම් (resourceNames) - ඔබට නිශ්චිත සම්පතකට ප්‍රවේශය සැපයිය යුතු අවස්ථාව සඳහා මිස මෙම වර්ගයේ සියලුම සම්පත් සඳහා නොවේ.

Kubernetes හි අවසරය පිළිබඳ වඩාත් සවිස්තරාත්මක විශ්ලේෂණයක් පිටුවෙන් සොයාගත හැකිය නිල ලියකියවිලි. ඒ වෙනුවට (හෝ ඒ වෙනුවට, මෙයට අමතරව), මම ඇගේ වැඩ නිරූපණය කරන උදාහරණ දෙන්නෙමි.

RBAC ආයතනවල උදාහරණ

සරල Role, එය ඔබට කරල් ලැයිස්තුවක් සහ තත්ත්වය ලබා ගැනීමට සහ නාම අවකාශයේ ඒවා නිරීක්ෂණය කිරීමට ඉඩ සලසයි 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"]

උදාහරණ: ClusterRole, ඔබට කරල් ලැයිස්තුවක් සහ තත්ත්වය ලබා ගැනීමට සහ පොකුර පුරා ඒවා නිරීක්ෂණය කිරීමට ඉඩ සලසයි:

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

උදාහරණ: RoleBinding, පරිශීලකයාට ඉඩ ලබා දෙන mynewuser නාම අවකාශයේ කරල් "කියවන්න" 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 ධාවනය ධාවනය කරන විට Kubernetes හි කුමක් සිදුවේද?".

පද්ධති විගණනය යනු පෙරනිමියෙන් අක්‍රිය කර ඇති Kubernetes හි සිත්ගන්නා අංගයකි. Kubernetes API වෙත සියලුම ඇමතුම් ලොග් කිරීමට එය ඔබට ඉඩ සලසයි. ඔබ අනුමාන කළ හැකි පරිදි, පොකුරේ තත්ත්වය නිරීක්ෂණය කිරීම සහ වෙනස් කිරීම සම්බන්ධ සියලුම ක්‍රියා මෙම API හරහා සිදු කෙරේ. එහි හැකියාවන් පිළිබඳ හොඳ විස්තරයක් (සාමාන්‍ය පරිදි) සොයාගත හැකිය නිල ලියකියවිලි K8s. ඊළඟට, මම මාතෘකාව සරල භාෂාවෙන් ඉදිරිපත් කිරීමට උත්සාහ කරමි.

එසේ නම්, විගණනය සක්රිය කිරීමට, අපට අවශ්‍ය පරාමිති තුනක් api-සේවාදායකයේ ඇති බහාලුමට ලබා දිය යුතු අතර ඒවා වඩාත් විස්තරාත්මකව පහත විස්තර කෙරේ:

• --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-apserver ලියකියවිලි.

දැනටමත් සඳහන් කර ඇති පරිදි, සියලුම පරාමිති api-සේවාදායක වින්‍යාසය සමඟ මැනිෆෙස්ටයේ සකසා ඇත (පෙරනිමියෙන් /etc/kubernetes/manifests/kube-apiserver.yaml), කොටසේ command. අවශ්‍ය පරාමිති 3 වෙත ආපසු ගොස් ඒවා විශ්ලේෂණය කරමු:

1. audit-policy-file - විගණන ප්‍රතිපත්තිය විස්තර කරන YAML ගොනුව වෙත මාර්ගය. අපි පසුව එහි අන්තර්ගතය වෙත ආපසු යන්නෙමු, නමුත් දැනට මම ගොනුව api-සේවාදායක ක්‍රියාවලියට කියවිය හැකි බව සටහන් කරමි. එමනිසා, එය කන්ටේනරය තුළ සවි කිරීම අවශ්ය වේ, ඒ සඳහා ඔබට පහත කේතය වින්යාසයේ සුදුසු කොටස් වලට එකතු කළ හැකිය:

     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 - ලොග් පාර-දත්ත සහ ඉල්ලීම් ශරීරය;
• RequestResponse - ලොග් පාර-දත්ත, ඉල්ලීම් ශරීරය සහ ප්‍රතිචාර ශරීරය.

අවසාන මට්ටම් දෙක (Request и RequestResponse) සම්පත් වෙත ප්‍රවේශ නොවූ ඉල්ලීම් ලොග් නොකරන්න (ඊනියා සම්පත් නොවන url වෙත ප්‍රවේශ වීම).

එසේම සියලුම ඉල්ලීම් ඉටු වේ අදියර කිහිපයක්:

• RequestReceived - ප්‍රොසෙසරය මඟින් ඉල්ලීම ලැබුණු සහ තවමත් ප්‍රොසෙසර දාමය ඔස්සේ තව දුරටත් සම්ප්‍රේෂණය කර නොමැති අදියර;
• ResponseStarted - ප්‍රතිචාර ශීර්ෂ යවනු ලැබේ, නමුත් ප්‍රතිචාර ශරීරය යැවීමට පෙර. දිගුකාලීන විමසුම් සඳහා ජනනය කරන ලදී (උදාහරණයක් ලෙස, watch);
• ResponseComplete - ප්රතිචාර ශරීරය යවා ඇත, තවත් තොරතුරු යවනු නොලැබේ;
• Panic - අසාමාන්ය තත්වයක් අනාවරණය වූ විට සිදුවීම් ජනනය වේ.

ඔබට භාවිතා කළ හැකි ඕනෑම පියවරක් මඟ හැරීමට omitStages.

ප්‍රතිපත්ති ගොනුවක, අපට විවිධ ලොගින් මට්ටම් සහිත කොටස් කිහිපයක් විස්තර කළ හැක. ප්‍රතිපත්ති විස්තරයේ ඇති පළමු ගැළපෙන රීතිය යොදනු ලැබේ.

kubelet daemon api-සේවාදායක වින්‍යාසය සමඟ මැනිෆෙස්ටයේ වෙනස්කම් නිරීක්ෂණය කරන අතර, යමක් අනාවරණය වුවහොත්, api-සේවාදායකය සමඟ කන්ටේනරය නැවත ආරම්භ කරයි. නමුත් වැදගත් විස්තරයක් තිබේ: ප්‍රතිපත්ති ගොනුවේ වෙනස්කම් එය නොසලකා හරිනු ඇත. ප්‍රතිපත්ති ගොනුවේ වෙනස්කම් සිදු කිරීමෙන් පසු, ඔබට api-සේවාදායකය අතින් නැවත ආරම්භ කිරීමට අවශ්‍ය වනු ඇත. api-server ලෙස ආරම්භ කර ඇති බැවින් ස්ථිතික පොඩ්, කණ්ඩායම kubectl delete එය නැවත ආරම්භ කිරීමට හේතු නොවනු ඇත. ඔබට එය අතින් කිරීමට සිදුවනු ඇත 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

විගණන ප්‍රතිපත්තියට තවත් හොඳ උදාහරණයක් අ.පො.ස.හි භාවිතා කරන පැතිකඩ.

විගණන සිදුවීම් වලට ඉක්මනින් ප්රතිචාර දැක්වීමට, එය හැකි ය webhook විස්තර කරන්න. මෙම ප්රශ්නය ආවරණය කර ඇත නිල ලියකියවිලි, මම එය මෙම ලිපියේ විෂය පථයෙන් පිටත තබමි.

ප්රතිඵල

පුද්ගලාරෝපිත පරිශීලක ගිණුම් සෑදීමට, ඔවුන්ගේ අයිතිවාසිකම් වෙන් කිරීමට සහ ඔවුන්ගේ ක්‍රියාවන් වාර්තා කිරීමට ඔබට ඉඩ සලසන Kubernetes පොකුරු වල මූලික ආරක්ෂක යාන්ත්‍රණ පිළිබඳ දළ විශ්ලේෂණයක් ලිපිය සපයයි. න්‍යායාත්මකව හෝ ප්‍රායෝගිකව මෙවැනි ප්‍රශ්නවලට මුහුණ දෙන අයට එය ප්‍රයෝජනවත් වේ යැයි මම බලාපොරොත්තු වෙමි. “පීඑස්” හි දක්වා ඇති කුබර්නෙට්ස් හි ආරක්ෂාව පිළිබඳ මාතෘකාව පිළිබඳ වෙනත් ද්‍රව්‍ය ලැයිස්තුවක් කියවන ලෙස මම නිර්දේශ කරමි - සමහර විට ඒවා අතර ඔබට අදාළ ගැටළු පිළිබඳ අවශ්‍ය තොරතුරු සොයාගත හැකිය.

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

• «33+ Kubernetes ආරක්ෂක මෙවලම්»;
• «ආරක්ෂක වෘත්තිකයන් සඳහා Kubernetes ජාල ප්‍රතිපත්ති පිළිබඳ හැඳින්වීමක්»;
• «Kubernetes හි RBAC අවබෝධ කර ගැනීම»;
• «9 Kubernetes ආරක්ෂක හොඳම භාවිතයන්»;
• «Kubernetes Hack එකක ගොදුරක් වීමට (නොවන) මාර්ග 11".

මූලාශ්රය: www.habr.com