ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಎಬಿಸಿ ಆಫ್ ಸೆಕ್ಯುರಿಟಿ: ದೃಢೀಕರಣ, ದೃಢೀಕರಣ, ಆಡಿಟಿಂಗ್

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಎಬಿಸಿ ಆಫ್ ಸೆಕ್ಯುರಿಟಿ: ದೃಢೀಕರಣ, ದೃಢೀಕರಣ, ಆಡಿಟಿಂಗ್

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಎಬಿಸಿ ಆಫ್ ಸೆಕ್ಯುರಿಟಿ: ದೃಢೀಕರಣ, ದೃಢೀಕರಣ, ಆಡಿಟಿಂಗ್

ಶೀಘ್ರದಲ್ಲೇ ಅಥವಾ ನಂತರ, ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ, ಭದ್ರತೆಯ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ: ದೃಢೀಕರಣವನ್ನು ಖಚಿತಪಡಿಸುವುದು, ಹಕ್ಕುಗಳ ಪ್ರತ್ಯೇಕತೆ, ಲೆಕ್ಕಪರಿಶೋಧನೆ ಮತ್ತು ಇತರ ಕಾರ್ಯಗಳು. ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಈಗಾಗಲೇ ರಚಿಸಲಾಗಿದೆ ಅನೇಕ ಪರಿಹಾರಗಳು, ಇದು ತುಂಬಾ ಬೇಡಿಕೆಯ ಪರಿಸರದಲ್ಲಿಯೂ ಸಹ ಮಾನದಂಡಗಳ ಅನುಸರಣೆಯನ್ನು ಸಾಧಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ ... ಅದೇ ವಸ್ತುವು K8 ಗಳ ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿ ಅಳವಡಿಸಲಾದ ಭದ್ರತೆಯ ಮೂಲಭೂತ ಅಂಶಗಳಿಗೆ ಮೀಸಲಾಗಿರುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಪರಿಚಯವಾಗಲು ಪ್ರಾರಂಭಿಸುವವರಿಗೆ ಇದು ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ - ಭದ್ರತೆಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ಆರಂಭಿಕ ಹಂತವಾಗಿ.

ದೃ ation ೀಕರಣ

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಎರಡು ರೀತಿಯ ಬಳಕೆದಾರರಿದ್ದಾರೆ:

  • ಸೇವಾ ಖಾತೆಗಳು - ಕುಬರ್ನೆಟ್ಸ್ API ನಿರ್ವಹಿಸುವ ಖಾತೆಗಳು;
  • ಬಳಕೆದಾರರು - ಬಾಹ್ಯ, ಸ್ವತಂತ್ರ ಸೇವೆಗಳಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುವ "ಸಾಮಾನ್ಯ" ಬಳಕೆದಾರರು.

ಈ ಪ್ರಕಾರಗಳ ನಡುವಿನ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಸೇವಾ ಖಾತೆಗಳಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ API ನಲ್ಲಿ ವಿಶೇಷ ವಸ್ತುಗಳು ಇವೆ (ಅವುಗಳನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ - ServiceAccounts), ಇವುಗಳನ್ನು ನೇಮ್‌ಸ್ಪೇಸ್ ಮತ್ತು ಸೀಕ್ರೆಟ್ಸ್ ಪ್ರಕಾರದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಅಧಿಕೃತ ಡೇಟಾದ ಸೆಟ್‌ಗೆ ಜೋಡಿಸಲಾಗಿದೆ. ಅಂತಹ ಬಳಕೆದಾರರು (ಸೇವಾ ಖಾತೆಗಳು) ಪ್ರಾಥಮಿಕವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗಳ ಕುಬರ್ನೆಟ್ಸ್ API ಗೆ ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಉದ್ದೇಶಿಸಲಾಗಿದೆ.

ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರು ಕುಬರ್ನೆಟ್ಸ್ API ನಲ್ಲಿ ನಮೂದುಗಳನ್ನು ಹೊಂದಿಲ್ಲ: ಅವುಗಳನ್ನು ಬಾಹ್ಯ ಕಾರ್ಯವಿಧಾನಗಳಿಂದ ನಿರ್ವಹಿಸಬೇಕು. ಅವರು ಕ್ಲಸ್ಟರ್ ಹೊರಗೆ ವಾಸಿಸುವ ಜನರು ಅಥವಾ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ.

ಪ್ರತಿಯೊಂದು API ವಿನಂತಿಯು ಸೇವಾ ಖಾತೆ, ಬಳಕೆದಾರ, ಅಥವಾ ಅನಾಮಧೇಯ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಬಳಕೆದಾರರ ದೃಢೀಕರಣ ಡೇಟಾ ಒಳಗೊಂಡಿದೆ:

  • ಬಳಕೆದಾರ ಹೆಸರು - ಬಳಕೆದಾರಹೆಸರು (ಕೇಸ್ ಸೆನ್ಸಿಟಿವ್!);
  • ಯುಐಡಿ - "ಬಳಕೆದಾರಹೆಸರಿಗಿಂತಲೂ ಹೆಚ್ಚು ಸ್ಥಿರವಾದ ಮತ್ತು ವಿಶಿಷ್ಟವಾದ" ಯಂತ್ರ-ಓದಬಲ್ಲ ಬಳಕೆದಾರ ಗುರುತಿನ ಸ್ಟ್ರಿಂಗ್;
  • ಗುಂಪುಗಳು - ಬಳಕೆದಾರರು ಸೇರಿರುವ ಗುಂಪುಗಳ ಪಟ್ಟಿ;
  • ಎಕ್ಸ್ಟ್ರಾ - ದೃಢೀಕರಣ ಕಾರ್ಯವಿಧಾನದಿಂದ ಬಳಸಬಹುದಾದ ಹೆಚ್ಚುವರಿ ಕ್ಷೇತ್ರಗಳು.

ಕುಬರ್ನೆಟ್‌ಗಳು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ದೃಢೀಕರಣ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದು: X509 ಪ್ರಮಾಣಪತ್ರಗಳು, ಬೇರರ್ ಟೋಕನ್‌ಗಳು, ದೃಢೀಕರಿಸುವ ಪ್ರಾಕ್ಸಿ, HTTP ಮೂಲ ದೃಢೀಕರಣ. ಈ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ದೃಢೀಕರಣ ಯೋಜನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು: ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಸ್ಥಿರ ಫೈಲ್‌ನಿಂದ 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"
  • ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಸಿಎ ಕೀಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಮಾಣಪತ್ರ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು, ಬಳಕೆದಾರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಡೆಯುವುದು (ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಡೆಯಲು, ನೀವು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಇರುವ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಸಿಎ ಕೀಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುವ ಖಾತೆಯನ್ನು ಬಳಸಬೇಕು. /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

ಇದನ್ನು ಮಾಡಲು, ನೀವು ಬೇಸ್ 64 ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಫೈಲ್‌ಗಳನ್ನು ಎನ್ಕೋಡ್ ಮಾಡಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಸಂರಚನೆಯಲ್ಲಿ ನೋಂದಾಯಿಸಿ, ಕೀಗಳ ಹೆಸರಿಗೆ ಪ್ರತ್ಯಯವನ್ನು ಸೇರಿಸಬಹುದು. -data, ಅಂದರೆ ಪಡೆದ ನಂತರ 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.

ಪರಿಣಾಮವಾಗಿ ಸಂರಚನೆಯು stdout ಗೆ ಔಟ್‌ಪುಟ್ ಆಗಿರುತ್ತದೆ. ಅದನ್ನು ಉಳಿಸಬೇಕಾಗಿದೆ ~/.kube/config ಬಳಕೆದಾರ ಖಾತೆ ಅಥವಾ ಪರಿಸರ ವೇರಿಯಬಲ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಫೈಲ್‌ಗೆ KUBECONFIG.

ಆಳವಾಗಿ ಅಗೆಯಿರಿ

ವಿವರಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಹೆಚ್ಚು ಕೂಲಂಕಷವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸುವವರಿಗೆ:

ಅಧಿಕಾರ

ಡೀಫಾಲ್ಟ್ ಅಧಿಕೃತ ಖಾತೆಯು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಅನುಮತಿಗಳನ್ನು ನೀಡಲು, ಕುಬರ್ನೆಟ್ಸ್ ದೃಢೀಕರಣ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅಳವಡಿಸುತ್ತದೆ.

ಆವೃತ್ತಿ 1.6 ಕ್ಕಿಂತ ಮೊದಲು, ಕುಬರ್ನೆಟ್ಸ್ ಎಂಬ ಅಧಿಕೃತ ಪ್ರಕಾರವನ್ನು ಬಳಸಿದರು 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 ಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ತತ್ವಗಳು ಮತ್ತು ವೈಶಿಷ್ಟ್ಯಗಳ ಸಾಕಷ್ಟು ವಿವರವಾದ ವಿವರಣೆಯೊಂದಿಗೆ, ನಾನು ಮೂಲಭೂತ ಮತ್ತು ಉದಾಹರಣೆಗಳ ಸಂಕ್ಷಿಪ್ತ ಪಟ್ಟಿಗೆ ನನ್ನನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತೇನೆ.

RBAC ಮೂಲಕ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸಲು ಕೆಳಗಿನ API ಘಟಕಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ:

  • Role и ClusterRole - ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ವಿವರಿಸಲು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪಾತ್ರಗಳು:
  • Role ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಹಕ್ಕುಗಳನ್ನು ವಿವರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ;
  • ClusterRole - ಕ್ಲಸ್ಟರ್‌ನೊಳಗೆ, ನೋಡ್‌ಗಳು, ಸಂಪನ್ಮೂಲಗಳಲ್ಲದ url ಗಳಂತಹ ಕ್ಲಸ್ಟರ್-ನಿರ್ದಿಷ್ಟ ವಸ್ತುಗಳನ್ನು ಒಳಗೊಂಡಂತೆ (ಅಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ - ಉದಾಹರಣೆಗೆ, /version, /logs, /api*);
  • RoleBinding и ClusterRoleBinding - ಬಂಧಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ Role и ClusterRole ಬಳಕೆದಾರ, ಬಳಕೆದಾರ ಗುಂಪು ಅಥವಾ ಸೇವಾ ಖಾತೆಗೆ.

ರೋಲ್ ಮತ್ತು ರೋಲ್‌ಬೈಂಡಿಂಗ್ ಘಟಕಗಳು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಿಂದ ಸೀಮಿತವಾಗಿವೆ, ಅಂದರೆ. ಅದೇ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಇರಬೇಕು. ಆದಾಗ್ಯೂ, ರೋಲ್‌ಬೈಂಡಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ರೋಲ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದು, ಇದು ಸಾರ್ವತ್ರಿಕ ಅನುಮತಿಗಳ ಗುಂಪನ್ನು ರಚಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಪಾತ್ರಗಳು ಒಳಗೊಂಡಿರುವ ನಿಯಮಗಳ ಸೆಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಹಕ್ಕುಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ:

  • API ಗುಂಪುಗಳು - ನೋಡಿ ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು apiGroups ಮತ್ತು ಔಟ್‌ಪುಟ್ ಮೂಲಕ kubectl api-resources;
  • ಸಂಪನ್ಮೂಲಗಳು (ಸಂಪನ್ಮೂಲಗಳು: pod, namespace, deployment ಮತ್ತು ಇತ್ಯಾದಿ.);
  • ಕ್ರಿಯಾಪದಗಳು (ಕ್ರಿಯಾಪದಗಳು: set, update ಇತ್ಯಾದಿ).
  • ಸಂಪನ್ಮೂಲ ಹೆಸರುಗಳು (resourceNames) - ನೀವು ನಿರ್ದಿಷ್ಟ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಬೇಕಾದಾಗ ಮತ್ತು ಈ ಪ್ರಕಾರದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಅಲ್ಲ.

ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅಧಿಕಾರದ ಹೆಚ್ಚು ವಿವರವಾದ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಪುಟದಲ್ಲಿ ಕಾಣಬಹುದು ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು. ಬದಲಿಗೆ (ಅಥವಾ ಬದಲಿಗೆ, ಇದರ ಜೊತೆಗೆ), ನಾನು ಅವಳ ಕೆಲಸವನ್ನು ವಿವರಿಸುವ ಉದಾಹರಣೆಗಳನ್ನು ನೀಡುತ್ತೇನೆ.

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

ಈವೆಂಟ್ ಆಡಿಟ್

ಕ್ರಮಬದ್ಧವಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಪ್ರತಿನಿಧಿಸಬಹುದು:

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಎಬಿಸಿ ಆಫ್ ಸೆಕ್ಯುರಿಟಿ: ದೃಢೀಕರಣ, ದೃಢೀಕರಣ, ಆಡಿಟಿಂಗ್

ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಪ್ರಮುಖ ಕುಬರ್ನೆಟ್ಸ್ ಘಟಕವಾಗಿದೆ api-ಸರ್ವರ್. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳು ಅದರ ಮೂಲಕ ಹೋಗುತ್ತವೆ. ಲೇಖನದಲ್ಲಿ ಈ ಆಂತರಿಕ ಕಾರ್ಯವಿಧಾನಗಳ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು "ನೀವು kubectl ರನ್ ರನ್ ಮಾಡಿದಾಗ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಏನಾಗುತ್ತದೆ?».

ಸಿಸ್ಟಮ್ ಲೆಕ್ಕಪರಿಶೋಧನೆಯು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ, ಇದನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ 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

ಈ ಮೂರು ಅಗತ್ಯ ನಿಯತಾಂಕಗಳ ಜೊತೆಗೆ, ಲೆಕ್ಕಪರಿಶೋಧನೆಗೆ ಸಂಬಂಧಿಸಿದ ಹಲವು ಹೆಚ್ಚುವರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ: ಲಾಗ್ ತಿರುಗುವಿಕೆಯಿಂದ ವೆಬ್‌ಹೂಕ್ ವಿವರಣೆಗಳವರೆಗೆ. ಲಾಗ್ ತಿರುಗುವಿಕೆಯ ನಿಯತಾಂಕಗಳ ಉದಾಹರಣೆ:

  • --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 ಫೈಲ್‌ಗೆ ಮಾರ್ಗ. ನಾವು ನಂತರ ಅದರ ವಿಷಯಗಳಿಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ, ಆದರೆ ಈಗ ನಾನು ಫೈಲ್ ಅನ್ನು ಎಪಿಐ-ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಓದಬಹುದು ಎಂದು ಗಮನಿಸುತ್ತೇನೆ. ಆದ್ದರಿಂದ, ಕಂಟೇನರ್ ಒಳಗೆ ಅದನ್ನು ಆರೋಹಿಸಲು ಅವಶ್ಯಕವಾಗಿದೆ, ಇದಕ್ಕಾಗಿ ನೀವು ಈ ಕೆಳಗಿನ ಕೋಡ್ ಅನ್ನು ಸಂರಚನೆಯ ಸೂಕ್ತ ವಿಭಾಗಗಳಿಗೆ ಸೇರಿಸಬಹುದು: 
      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 — ಲಾಗ್ ವಿನಂತಿ ಮೆಟಾಡೇಟಾ: ಬಳಕೆದಾರ, ವಿನಂತಿಯ ಸಮಯ, ಗುರಿ ಸಂಪನ್ಮೂಲ (ಪಾಡ್, ನೇಮ್‌ಸ್ಪೇಸ್, ​​ಇತ್ಯಾದಿ), ಕ್ರಿಯೆಯ ಪ್ರಕಾರ (ಕ್ರಿಯಾಪದ), ಇತ್ಯಾದಿ;
  • Request - ಲಾಗ್ ಮೆಟಾಡೇಟಾ ಮತ್ತು ವಿನಂತಿಯ ದೇಹ;
  • RequestResponse - ಲಾಗ್ ಮೆಟಾಡೇಟಾ, ವಿನಂತಿಯ ದೇಹ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ದೇಹ.

ಕೊನೆಯ ಎರಡು ಹಂತಗಳು (Request и RequestResponse) ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರವೇಶಿಸದ ವಿನಂತಿಗಳನ್ನು ಲಾಗ್ ಮಾಡಬೇಡಿ (ಸಂಪನ್ಮೂಲವಲ್ಲದ url ಎಂದು ಕರೆಯಲ್ಪಡುವ ಪ್ರವೇಶಗಳು).

ಅಲ್ಲದೆ ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಹಾದು ಹೋಗುತ್ತವೆ ಹಲವಾರು ಹಂತಗಳು:

  • RequestReceived - ಪ್ರೊಸೆಸರ್‌ನಿಂದ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ಹಂತ ಮತ್ತು ಪ್ರೊಸೆಸರ್‌ಗಳ ಸರಪಳಿಯ ಉದ್ದಕ್ಕೂ ಇನ್ನೂ ರವಾನಿಸಲಾಗಿಲ್ಲ;
  • ResponseStarted - ಪ್ರತಿಕ್ರಿಯೆ ಶೀರ್ಷಿಕೆಗಳನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಕ್ರಿಯೆಯ ದೇಹವನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು. ದೀರ್ಘಾವಧಿಯ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ ರಚಿಸಲಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, watch);
  • ResponseComplete - ಪ್ರತಿಕ್ರಿಯೆ ದೇಹವನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ, ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ;
  • Panic - ಅಸಹಜ ಪರಿಸ್ಥಿತಿ ಪತ್ತೆಯಾದಾಗ ಘಟನೆಗಳು ಉತ್ಪತ್ತಿಯಾಗುತ್ತವೆ.

ನೀವು ಬಳಸಬಹುದಾದ ಯಾವುದೇ ಹಂತಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಲು omitStages.

ನೀತಿ ಫೈಲ್‌ನಲ್ಲಿ, ವಿವಿಧ ಲಾಗಿಂಗ್ ಹಂತಗಳೊಂದಿಗೆ ನಾವು ಹಲವಾರು ವಿಭಾಗಗಳನ್ನು ವಿವರಿಸಬಹುದು. ನೀತಿ ವಿವರಣೆಯಲ್ಲಿ ಕಂಡುಬರುವ ಮೊದಲ ಹೊಂದಾಣಿಕೆಯ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.

ಕುಬೆಲೆಟ್ ಡೀಮನ್ ಎಪಿಐ-ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಯಾವುದಾದರೂ ಪತ್ತೆಯಾದರೆ, ಎಪಿಐ-ಸರ್ವರ್‌ನೊಂದಿಗೆ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆದರೆ ಒಂದು ಪ್ರಮುಖ ವಿವರವಿದೆ: ನೀತಿ ಫೈಲ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಅದು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ನೀತಿ ಫೈಲ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ ನಂತರ, ನೀವು api-ಸರ್ವರ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮರುಪ್ರಾರಂಭಿಸಬೇಕಾಗುತ್ತದೆ. ಎಪಿ-ಸರ್ವರ್ ಅನ್ನು ಹೀಗೆ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಸ್ಥಿರ ಪಾಡ್, ತಂಡ kubectl delete ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಕಾರಣವಾಗುವುದಿಲ್ಲ. ನೀವು ಅದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡಬೇಕಾಗುತ್ತದೆ docker stop kube-masters ನಲ್ಲಿ, ಆಡಿಟ್ ನೀತಿಯನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ:

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

ಲೆಕ್ಕಪರಿಶೋಧನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವಾಗ, ಅದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ ಕ್ಯೂಬ್-ಎಪಿಸರ್ವರ್‌ನಲ್ಲಿನ ಹೊರೆ ಹೆಚ್ಚಾಗುತ್ತದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ವಿನಂತಿಯ ಸಂದರ್ಭವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮೆಮೊರಿ ಬಳಕೆ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆ ಹೆಡರ್ ಕಳುಹಿಸಿದ ನಂತರವೇ ಲಾಗಿಂಗ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಲೋಡ್ ಕೂಡ ಆಡಿಟ್ ನೀತಿ ಸಂರಚನೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.

ನೀತಿಗಳ ಉದಾಹರಣೆಗಳು

ಉದಾಹರಣೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೀತಿ ಫೈಲ್‌ಗಳ ರಚನೆಯನ್ನು ನೋಡೋಣ.

ಇಲ್ಲಿ ಸರಳವಾದ ಫೈಲ್ ಇದೆ 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

ಕೆಳಗಿನ ಆಡಿಟ್ ನೀತಿಯನ್ನು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳ ಪ್ರದರ್ಶನವಾಗಿ ಒದಗಿಸಲಾಗಿದೆ ಅಲಿಬಾಬಾ ಕ್ಲೌಡ್ ದಸ್ತಾವೇಜನ್ನು:

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 ನಲ್ಲಿ ಬಳಸಿದ ಪ್ರೊಫೈಲ್.

ಆಡಿಟ್ ಘಟನೆಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು, ಅದು ಸಾಧ್ಯ ವೆಬ್ಹೂಕ್ ಅನ್ನು ವಿವರಿಸಿ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಒಳಗೊಂಡಿದೆ ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು, ನಾನು ಅದನ್ನು ಈ ಲೇಖನದ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ ಬಿಡುತ್ತೇನೆ.

ಫಲಿತಾಂಶಗಳು

ಲೇಖನವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿನ ಮೂಲಭೂತ ಭದ್ರತಾ ಕಾರ್ಯವಿಧಾನಗಳ ಅವಲೋಕನವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದು ನಿಮಗೆ ವೈಯಕ್ತಿಕಗೊಳಿಸಿದ ಬಳಕೆದಾರ ಖಾತೆಗಳನ್ನು ರಚಿಸಲು, ಅವರ ಹಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಮತ್ತು ಅವರ ಕ್ರಿಯೆಗಳನ್ನು ದಾಖಲಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಅಥವಾ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿರುವವರಿಗೆ ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. "ಪಿಎಸ್" ನಲ್ಲಿ ನೀಡಲಾದ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಭದ್ರತೆಯ ವಿಷಯದ ಕುರಿತು ಇತರ ವಸ್ತುಗಳ ಪಟ್ಟಿಯನ್ನು ನೀವು ಓದಬೇಕೆಂದು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ - ಬಹುಶಃ ಅವುಗಳಲ್ಲಿ ನಿಮಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳ ಕುರಿತು ಅಗತ್ಯ ವಿವರಗಳನ್ನು ನೀವು ಕಾಣಬಹುದು.

ಪಿಎಸ್

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ