ABC ຂອງຄວາມປອດໄພໃນ Kubernetes: ການກວດສອບຄວາມຖືກຕ້ອງ, ການອະນຸຍາດ, ການກວດສອບ

ບໍ່ດົນ, ໃນການດໍາເນີນງານຂອງລະບົບໃດກໍ່ຕາມ, ບັນຫາຄວາມປອດໄພເກີດຂື້ນ: ຮັບປະກັນການຢັ້ງຢືນ, ການແຍກສິດ, ການກວດສອບແລະວຽກງານອື່ນໆ. ສ້າງແລ້ວສຳລັບ Kubernetes ວິທີແກ້ໄຂຫຼາຍ, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານບັນລຸການປະຕິບັດຕາມມາດຕະຖານເຖິງແມ່ນວ່າໃນສະພາບແວດລ້ອມທີ່ມີຄວາມຕ້ອງການຫຼາຍ ... ວັດສະດຸດຽວກັນແມ່ນອຸທິດໃຫ້ລັກສະນະພື້ນຖານຂອງຄວາມປອດໄພທີ່ປະຕິບັດພາຍໃນກົນໄກການກໍ່ສ້າງໃນ K8s. ກ່ອນອື່ນ ໝົດ, ມັນຈະເປັນປະໂຫຍດຕໍ່ຜູ້ທີ່ເລີ່ມຮູ້ຈັກກັບ Kubernetes - ເປັນຈຸດເລີ່ມຕົ້ນຂອງການສຶກສາບັນຫາທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພ.

ການຢືນຢັນ

ມີສອງປະເພດຂອງຜູ້ໃຊ້ໃນ Kubernetes:

• ບັນຊີການບໍລິການ — ບັນຊີທີ່ຄຸ້ມຄອງໂດຍ Kubernetes API;
• ຜູ້ຊົມໃຊ້ — ຜູ້​ຊົມ​ໃຊ້ "ປົກ​ກະ​ຕິ​" ການ​ຄຸ້ມ​ຄອງ​ໂດຍ​ພາຍ​ນອກ​, ການ​ບໍ​ລິ​ການ​ເອ​ກະ​ລາດ​.

ຄວາມແຕກຕ່າງຕົ້ນຕໍລະຫວ່າງປະເພດເຫຼົ່ານີ້ແມ່ນວ່າສໍາລັບບັນຊີການບໍລິການມີວັດຖຸພິເສດໃນ Kubernetes API (ພວກມັນຖືກເອີ້ນວ່າ - ServiceAccounts), ເຊິ່ງຖືກຜູກມັດກັບ namespace ແລະຊຸດຂອງຂໍ້ມູນການອະນຸຍາດທີ່ເກັບໄວ້ໃນ cluster ໃນວັດຖຸຂອງປະເພດຄວາມລັບ. ຜູ້ໃຊ້ດັ່ງກ່າວ (ບັນຊີບໍລິການ) ມີຈຸດປະສົງຕົ້ນຕໍເພື່ອຈັດການສິດການເຂົ້າເຖິງ Kubernetes API ຂອງຂະບວນການທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມ Kubernetes.

ຜູ້ໃຊ້ທົ່ວໄປບໍ່ມີລາຍການໃນ Kubernetes API: ພວກເຂົາຕ້ອງໄດ້ຮັບການຄຸ້ມຄອງໂດຍກົນໄກພາຍນອກ. ພວກມັນມີຈຸດປະສົງເພື່ອຄົນ ຫຼືຂະບວນການທີ່ອາໄສຢູ່ນອກກຸ່ມ.

ແຕ່ລະຄໍາຮ້ອງຂໍ API ແມ່ນກ່ຽວຂ້ອງກັບບັນຊີບໍລິການ, ຜູ້ໃຊ້, ຫຼືຖືວ່າບໍ່ເປີດເຜີຍຊື່.

ຂໍ້ມູນການກວດສອບຜູ້ໃຊ້ປະກອບມີ:

• ຊື່ຜູ້ໃຊ້ — ຊື່​ຜູ້​ໃຊ້ (ຕົວ​ພິມ​ນ້ອຍ​ໃຫຍ່​)​;
• UID - ສະຕຣິງການລະບຸຕົວຜູ້ໃຊ້ທີ່ເຄື່ອງສາມາດອ່ານໄດ້ທີ່ “ສອດຄ່ອງ ແລະເປັນເອກະລັກກວ່າຊື່ຜູ້ໃຊ້”;
• Groups - ບັນຊີລາຍຊື່ຂອງກຸ່ມທີ່ຜູ້ໃຊ້ເປັນ;
• ພິເສດ — ຊ່ອງຂໍ້ມູນເພີ່ມເຕີມທີ່ສາມາດນໍາໃຊ້ໄດ້ໂດຍກົນໄກການອະນຸຍາດ.

Kubernetes ສາມາດໃຊ້ກົນໄກການພິສູດຢືນຢັນໄດ້ຫຼາຍອັນ: ໃບຮັບຮອງ X509, Bearer tokens, authenticating proxy, HTTP Basic Auth. ການນໍາໃຊ້ກົນໄກເຫຼົ່ານີ້, ທ່ານສາມາດປະຕິບັດໂຄງການການອະນຸຍາດຈໍານວນຫລາຍ: ຈາກໄຟລ໌ຄົງທີ່ທີ່ມີລະຫັດຜ່ານໄປຫາ OpenID OAuth2.

ຍິ່ງໄປກວ່ານັ້ນ, ມັນເປັນໄປໄດ້ທີ່ຈະນໍາໃຊ້ລະບົບການອະນຸຍາດຫຼາຍຄັ້ງພ້ອມກັນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ກຸ່ມໃຊ້:

• tokens ບັນຊີການບໍລິການ - ສໍາລັບບັນຊີການບໍລິການ;
• 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 cluster 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-server ຂອງກຸ່ມ):

    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 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 ແລະລົງທະບຽນພວກມັນໃນ config, ເພີ່ມຄໍາຕໍ່ທ້າຍໃສ່ຊື່ຂອງກະແຈ. -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-server config, ເຊິ່ງໂດຍຄ່າເລີ່ມຕົ້ນແມ່ນຕັ້ງຢູ່ໃນ /etc/kubernetes/manifests/kube-apiserver.yaml.

config ຜົນໄດ້ຮັບຈະເປັນ output ກັບ stdout. ມັນຈໍາເປັນຕ້ອງໄດ້ບັນທຶກໄວ້ໃນ ~/.kube/config ບັນຊີຜູ້ໃຊ້ ຫຼືໄຟລ໌ທີ່ລະບຸໄວ້ໃນຕົວແປສະພາບແວດລ້ອມ KUBECONFIG.

ຂຸດ​ເລິກ

ສໍາລັບຜູ້ທີ່ຕ້ອງການເຂົ້າໃຈບັນຫາທີ່ອະທິບາຍຢ່າງລະອຽດ:

• ບົດຂຽນແຍກຕ່າງຫາກ ກ່ຽວກັບການເຮັດວຽກກັບໃບຢັ້ງຢືນໃນເອກະສານ Kubernetes ຢ່າງເປັນທາງການ;
• ບົດຄວາມທີ່ດີຈາກ Bitnami, ໃນທີ່ບັນຫາຂອງໃບຢັ້ງຢືນແມ່ນ touched ຕາມທັດສະນະຂອງການປະຕິບັດ.
• ເອກະສານທົ່ວໄປ ກ່ຽວກັບການພິສູດຢືນຢັນໃນ Kubernetes.

ການອະນຸຍາດ

ບັນຊີທີ່ໄດ້ຮັບອະນຸຍາດເລີ່ມຕົ້ນບໍ່ມີສິດທີ່ຈະດໍາເນີນການຢູ່ໃນກຸ່ມ. ເພື່ອໃຫ້ການອະນຸຍາດ, Kubernetes ປະຕິບັດກົນໄກການອະນຸຍາດ.

ກ່ອນທີ່ຈະເປັນເວີຊັນ 1.6, Kubernetes ໄດ້ໃຊ້ປະເພດການອະນຸຍາດທີ່ເອີ້ນວ່າ ABAC (ການຄວບຄຸມການເຂົ້າເຖິງໂດຍອີງໃສ່ຄຸນລັກສະນະ). ລາຍລະອຽດກ່ຽວກັບມັນສາມາດພົບໄດ້ໃນ ເອກະສານທາງການ. ວິທີການນີ້ໄດ້ຖືກພິຈາລະນາໃນປັດຈຸບັນເປັນມໍລະດົກ, ແຕ່ທ່ານຍັງສາມາດໃຊ້ມັນຄຽງຄູ່ກັບການພິສູດຢືນຢັນປະເພດອື່ນໆ.

ວິທີການປະຈຸບັນ (ແລະມີຄວາມຍືດຫຍຸ່ນຫຼາຍ) ຂອງການແບ່ງສິດການເຂົ້າເຖິງກຸ່ມແມ່ນເອີ້ນວ່າ RBAC (ການຄວບຄຸມການເຂົ້າເຖິງໂດຍອີງໃສ່ບົດບາດ). ມັນໄດ້ຖືກປະກາດວ່າມີຄວາມຫມັ້ນຄົງຕັ້ງແຕ່ຮຸ່ນ ຄູໂບຕ້າ 1.8. RBAC ປະຕິບັດຮູບແບບສິດທິທີ່ທຸກສິ່ງທຸກຢ່າງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດຢ່າງຊັດເຈນແມ່ນຖືກຫ້າມ.
ເພື່ອເປີດໃຊ້ RBAC, ທ່ານຈໍາເປັນຕ້ອງເລີ່ມຕົ້ນ Kubernetes api-server ດ້ວຍພາລາມິເຕີ --authorization-mode=RBAC. ພາລາມິເຕີຖືກກໍານົດໄວ້ໃນ manifest ດ້ວຍການຕັ້ງຄ່າ api-server, ເຊິ່ງໂດຍຄ່າເລີ່ມຕົ້ນແມ່ນຕັ້ງຢູ່ຕາມເສັ້ນທາງ. /etc/kubernetes/manifests/kube-apiserver.yaml, ໃນພາກ command. ຢ່າງໃດກໍຕາມ, RBAC ຖືກເປີດໃຊ້ແລ້ວໂດຍຄ່າເລີ່ມຕົ້ນ, ດັ່ງນັ້ນທ່ານບໍ່ຄວນກັງວົນກ່ຽວກັບມັນ: ທ່ານສາມາດກວດສອບໄດ້ໂດຍມູນຄ່າ. authorization-mode (ໃນທີ່ໄດ້ກ່າວມາແລ້ວ kube-apiserver.yaml). ໂດຍວິທີທາງການ, ໃນບັນດາຄວາມຫມາຍຂອງມັນອາດມີການອະນຸຍາດປະເພດອື່ນໆ (node, webhook, always allow), ແຕ່ພວກເຮົາຈະອອກຈາກການພິຈາລະນາຂອງພວກເຂົາຢູ່ນອກຂອບເຂດຂອງວັດສະດຸ.

ໂດຍວິທີທາງການ, ພວກເຮົາໄດ້ຈັດພີມມາແລ້ວ ບົດຄວາມ ດ້ວຍລາຍລະອຽດທີ່ຂ້ອນຂ້າງກ່ຽວກັບຫຼັກການແລະລັກສະນະຂອງການເຮັດວຽກກັບ RBAC, ດັ່ງນັ້ນຕື່ມອີກຂ້າພະເຈົ້າຈະຈໍາກັດຕົວເອງກັບບັນຊີລາຍຊື່ສັ້ນໆຂອງພື້ນຖານແລະຕົວຢ່າງ.

ຫົວໜ່ວຍ API ຕໍ່ໄປນີ້ຖືກໃຊ້ເພື່ອຄວບຄຸມການເຂົ້າເຖິງໃນ Kubernetes ຜ່ານ RBAC:

• Role и ClusterRole — ພາ​ລະ​ບົດ​ບາດ​ເພື່ອ​ອະ​ທິ​ບາຍ​ສິດ​ການ​ເຂົ້າ​ເຖິງ​:
• Role ອະນຸຍາດໃຫ້ທ່ານອະທິບາຍສິດທິພາຍໃນ namespace;
• ClusterRole - ພາຍໃນກຸ່ມ, ລວມທັງວັດຖຸສະເພາະຂອງກຸ່ມເຊັ່ນ nodes, urls ທີ່ບໍ່ແມ່ນຊັບພະຍາກອນ (ເຊັ່ນ: ບໍ່ກ່ຽວຂ້ອງກັບຊັບພະຍາກອນ Kubernetes - ຕົວຢ່າງ, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - ໃຊ້ສໍາລັບການຜູກມັດ Role и ClusterRole ໃຫ້ກັບຜູ້ໃຊ້, ກຸ່ມຜູ້ໃຊ້ ຫຼືບັນຊີບໍລິການ.

ຫນ່ວຍງານພາລະບົດບາດແລະ RoleBinding ໄດ້ຖືກຈໍາກັດໂດຍ namespace, i.e. ຕ້ອງຢູ່ໃນ namespace ດຽວກັນ. ແນວໃດກໍ່ຕາມ, RoleBinding ສາມາດອ້າງອີງ ClusterRole, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສ້າງຊຸດການອະນຸຍາດທົ່ວໄປ ແລະຄວບຄຸມການເຂົ້າເຖິງໂດຍໃຊ້ພວກມັນ.

ພາລະບົດບາດອະທິບາຍສິດທິໂດຍໃຊ້ຊຸດຂອງກົດລະບຽບປະກອບມີ:

• ກຸ່ມ API - ເບິ່ງ ເອກະສານທາງການ ໂດຍ apiGroups ແລະຜົນຜະລິດ kubectl api-resources;
• ຊັບ​ພະ​ຍາ​ກອນ (ຊັບ​ພະ​ຍາ​ກອນ: pod, namespace, deployment ແລະ ອື່ນໆ.);
• ຄຳກິລິຍາ (ຄຳ ກິລິຍາ: set, update ແລະອື່ນໆ.).
• ຊື່ຊັບພະຍາກອນ (resourceNames) - ສໍາລັບກໍລະນີໃນເວລາທີ່ທ່ານຕ້ອງການສະຫນອງການເຂົ້າເຖິງຊັບພະຍາກອນສະເພາະໃດຫນຶ່ງ, ແລະບໍ່ແມ່ນຊັບພະຍາກອນທັງຫມົດຂອງປະເພດນີ້.

ການວິເຄາະລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການອະນຸຍາດໃນ Kubernetes ສາມາດພົບໄດ້ຢູ່ໃນຫນ້າ ເອກະສານທາງການ. ແທນທີ່ຈະ (ຫຼືແທນທີ່ຈະ, ນອກເຫນືອຈາກນີ້), ຂ້າພະເຈົ້າຈະໃຫ້ຕົວຢ່າງທີ່ສະແດງໃຫ້ເຫັນເຖິງການເຮັດວຽກຂອງນາງ.

ຕົວຢ່າງຂອງຫົວໜ່ວຍ RBAC

ງ່າຍດາຍ Role, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບບັນຊີລາຍຊື່ແລະສະຖານະພາບຂອງຝັກແລະຕິດຕາມກວດກາໃຫ້ເຂົາເຈົ້າຢູ່ໃນ 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"]

ຕົວຢ່າງ: 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 "ອ່ານ" pods ໃນ namespace 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-ເຊີບເວີ. ການດໍາເນີນງານທັງຫມົດໃນກຸ່ມຜ່ານມັນ. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບກົນໄກພາຍໃນເຫຼົ່ານີ້ໃນບົດຄວາມ "ຈະເກີດຫຍັງຂຶ້ນໃນ Kubernetes ເມື່ອທ່ານແລ່ນ kubectl run?".

ການກວດສອບລະບົບເປັນລັກສະນະທີ່ຫນ້າສົນໃຈໃນ Kubernetes, ເຊິ່ງຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ. ມັນອະນຸຍາດໃຫ້ທ່ານສາມາດບັນທຶກການໂທທັງຫມົດໄປຫາ Kubernetes API. ດັ່ງທີ່ເຈົ້າອາດຈະເດົາໄດ້, ການກະທຳທັງໝົດທີ່ກ່ຽວຂ້ອງກັບການຕິດຕາມ ແລະ ການປ່ຽນສະຖານະຂອງກຸ່ມແມ່ນດຳເນີນຜ່ານ API ນີ້. ຄໍາອະທິບາຍທີ່ດີຂອງຄວາມສາມາດຂອງມັນສາມາດ (ຕາມປົກກະຕິ) ຢູ່ໃນ ເອກະສານທາງການ K8s. ຕໍ່ໄປ, ຂ້າພະເຈົ້າຈະພະຍາຍາມນໍາສະເຫນີຫົວຂໍ້ໃນພາສາທີ່ງ່າຍດາຍກວ່າ.

ດັ່ງ​ນັ້ນ ເພື່ອເປີດໃຊ້ການກວດສອບ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຜ່ານສາມຕົວກໍານົດການທີ່ກໍານົດໄວ້ກັບ container ໃນ api-server, ເຊິ່ງໄດ້ອະທິບາຍໃນລາຍລະອຽດເພີ່ມເຕີມຂ້າງລຸ່ມນີ້:

• --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.

ດັ່ງທີ່ໄດ້ກ່າວມາແລ້ວ, ພາລາມິເຕີທັງຫມົດຖືກຕັ້ງຢູ່ໃນ manifest ດ້ວຍການຕັ້ງຄ່າ api-server (ໂດຍຄ່າເລີ່ມຕົ້ນ /etc/kubernetes/manifests/kube-apiserver.yaml), ໃນພາກ command. ໃຫ້ກັບຄືນໄປຫາ 3 ຕົວກໍານົດການທີ່ຕ້ອງການແລະວິເຄາະພວກມັນ:

1. audit-policy-file — ເສັ້ນທາງໄປຫາໄຟລ໌ YAML ທີ່ອະທິບາຍນະໂຍບາຍການກວດສອບ. ພວກເຮົາຈະກັບຄືນໄປຫາເນື້ອໃນຂອງມັນຕໍ່ມາ, ແຕ່ສໍາລັບຕອນນີ້ຂ້ອຍຈະສັງເກດວ່າໄຟລ໌ຕ້ອງຖືກອ່ານໄດ້ໂດຍຂະບວນການ api-server. ດັ່ງນັ້ນ, ມັນຈໍາເປັນຕ້ອງຕິດມັນຢູ່ໃນຖັງ, ທີ່ທ່ານສາມາດເພີ່ມລະຫັດຕໍ່ໄປນີ້ໃສ່ສ່ວນທີ່ເຫມາະສົມຂອງການຕັ້ງຄ່າ:

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

2. audit-log-path - ເສັ້ນທາງໄປຫາໄຟລ໌ບັນທຶກ. ເສັ້ນທາງດັ່ງກ່າວຍັງຕ້ອງສາມາດເຂົ້າເຖິງຂະບວນການ api-server, ດັ່ງນັ້ນພວກເຮົາອະທິບາຍການຕິດຕັ້ງຂອງມັນໃນທາງດຽວກັນ:

     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​, ແລະ​ອື່ນໆ​)​, ປະ​ເພດ​ການ​ປະ​ຕິ​ບັດ (verb​)​, ແລະ​ອື່ນໆ​;
• Request — ບັນທຶກ metadata ແລະຮ່າງກາຍຮ້ອງຂໍ;
• RequestResponse — ເຂົ້າ​ສູ່​ລະ​ບົບ metadata​, ຮ່າງ​ກາຍ​ຮ້ອງ​ຂໍ​ແລະ​ຮ່າງ​ກາຍ​ຕອບ​ສະ​ຫນອງ​.

ສອງ​ຂັ້ນ​ສຸດ​ທ້າຍ (Request и RequestResponse) ບໍ່ບັນທຶກການຮ້ອງຂໍທີ່ບໍ່ເຂົ້າເຖິງຊັບພະຍາກອນ (ການເຂົ້າເຖິງອັນທີ່ເອີ້ນວ່າ urls ທີ່ບໍ່ແມ່ນຊັບພະຍາກອນ).

ນອກຈາກນີ້, ການຮ້ອງຂໍທັງຫມົດໄປໂດຍຜ່ານການ ຫຼາຍຂັ້ນຕອນ:

• RequestReceived — ຂັ້ນຕອນໃນເວລາທີ່ການຮ້ອງຂໍໄດ້ຮັບໂດຍໂຮງງານຜະລິດແລະຍັງບໍ່ທັນໄດ້ສົ່ງຕໍ່ໄປອີກຕາມລະບົບຕ່ອງໂສ້ຂອງໂຮງງານຜະລິດ;
• ResponseStarted — ຫົວ​ຕອບ​ຖືກ​ສົ່ງ​ໄປ​, ແຕ່​ກ່ອນ​ທີ່​ຮ່າງ​ກາຍ​ຕອບ​ສະ​ຫນອງ​ຈະ​ຖືກ​ສົ່ງ​. ສ້າງຂຶ້ນສໍາລັບການສອບຖາມທີ່ຍາວນານ (ຕົວຢ່າງ: watch);
• ResponseComplete — ໜ່ວຍ​ງານ​ຕອບ​ສະ​ໜອງ​ໄດ້​ຖືກ​ສົ່ງ​ໄປ​ແລ້ວ, ບໍ່​ມີ​ຂໍ້​ມູນ​ເພີ່ມ​ເຕີມ​ຈະ​ຖືກ​ສົ່ງ;
• Panic — ເຫດການຈະເກີດຂຶ້ນເມື່ອກວດພົບສະຖານະການຜິດປົກກະຕິ.

ເພື່ອຂ້າມຂັ້ນຕອນໃດໆທີ່ທ່ານສາມາດນໍາໃຊ້ omitStages.

ໃນເອກະສານນະໂຍບາຍ, ພວກເຮົາສາມາດອະທິບາຍຫຼາຍພາກສ່ວນທີ່ມີລະດັບການບັນທຶກທີ່ແຕກຕ່າງກັນ. ກົດລະບຽບການຈັບຄູ່ທໍາອິດທີ່ພົບໃນຄໍາອະທິບາຍນະໂຍບາຍຈະຖືກໃຊ້.

kubelet daemon ຕິດຕາມການປ່ຽນແປງໃນ manifest ດ້ວຍການຕັ້ງຄ່າ api-server ແລະ, ຖ້າມີກວດພົບ, restart container ກັບ api-server. ແຕ່ມີລາຍລະອຽດທີ່ສໍາຄັນ: ການປ່ຽນແປງໃນໄຟລ໌ນະໂຍບາຍຈະຖືກລະເລີຍໂດຍມັນ. ຫຼັງຈາກເຮັດການປ່ຽນແປງໄຟລ໌ນະໂຍບາຍ, ທ່ານຈະຕ້ອງປິດເປີດ api-server ດ້ວຍຕົນເອງ. ເນື່ອງຈາກ api-server ແມ່ນເລີ່ມຕົ້ນເປັນ ຝັກສະຖິດ, ທີມງານ 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 (namespaces);
• ຄຳກິລິຍາ (ຄຳ ກິລິຍາ: get, update, delete ແລະ​ອື່ນໆ);
• ຊັບ​ພະ​ຍາ​ກອນ (ຊັບ​ພະ​ຍາ​ກອນ, ຄື: pod, configmaps ແລະອື່ນໆ) ແລະກຸ່ມຊັບພະຍາກອນ (apiGroups).

ຈ່າຍເອົາໃຈໃສ່! ຊັບພະຍາກອນແລະກຸ່ມຊັບພະຍາກອນ (ກຸ່ມ API, i.e. 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, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສ້າງບັນຊີຜູ້ໃຊ້ສ່ວນບຸກຄົນ, ແຍກສິດຂອງເຂົາເຈົ້າ, ແລະບັນທຶກການກະທໍາຂອງເຂົາເຈົ້າ. ຂ້າພະເຈົ້າຫວັງວ່າມັນຈະເປັນປະໂຫຍດສໍາລັບຜູ້ທີ່ປະເຊີນກັບບັນຫາດັ່ງກ່າວໃນທາງທິດສະດີຫຼືໃນການປະຕິບັດ. ຂ້າພະເຈົ້າຍັງແນະນໍາໃຫ້ທ່ານອ່ານບັນຊີລາຍຊື່ຂອງອຸປະກອນອື່ນໆກ່ຽວກັບຫົວຂໍ້ຄວາມປອດໄພໃນ Kubernetes, ເຊິ່ງໄດ້ຖືກມອບໃຫ້ຢູ່ໃນ "PS" - ບາງທີໃນນັ້ນເຈົ້າຈະພົບເຫັນລາຍລະອຽດທີ່ຈໍາເປັນກ່ຽວກັບບັນຫາທີ່ກ່ຽວຂ້ອງກັບທ່ານ.

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «33+ ເຄື່ອງມືຄວາມປອດໄພ Kubernetes"
• «ການແນະນໍາກ່ຽວກັບນະໂຍບາຍເຄືອຂ່າຍ Kubernetes ສໍາລັບຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພ"
• «ຄວາມເຂົ້າໃຈ RBAC ໃນ Kubernetes"
• «9 ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບຄວາມປອດໄພ Kubernetes"
• «11 ວິທີທີ່ຈະ (ບໍ່) ຕົກເປັນເຫຍື່ອຂອງການ Hack Kubernetes".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com