குபெர்னெட்டஸில் பாதுகாப்பு ஏபிசி: அங்கீகாரம், அங்கீகாரம், தணிக்கை

விரைவில் அல்லது பின்னர், எந்தவொரு அமைப்பின் செயல்பாட்டிலும், பாதுகாப்பு பிரச்சினை எழுகிறது: அங்கீகாரத்தை உறுதி செய்தல், உரிமைகளைப் பிரித்தல், தணிக்கை மற்றும் பிற பணிகள். குபெர்னெட்டஸுக்காக ஏற்கனவே உருவாக்கப்பட்டது பல தீர்வுகள், இது மிகவும் கோரும் சூழல்களிலும் தரநிலைகளுடன் இணக்கத்தை அடைய உங்களை அனுமதிக்கிறது... அதே பொருள் K8s இன் உள்ளமைக்கப்பட்ட வழிமுறைகளுக்குள் செயல்படுத்தப்படும் பாதுகாப்பின் அடிப்படை அம்சங்களுக்கு அர்ப்பணிக்கப்பட்டுள்ளது. முதலாவதாக, குபர்னெட்ஸுடன் பழகத் தொடங்குபவர்களுக்கு இது பயனுள்ளதாக இருக்கும் - பாதுகாப்பு தொடர்பான சிக்கல்களைப் படிப்பதற்கான தொடக்க புள்ளியாக.

அங்கீகார

குபெர்னெட்டஸில் இரண்டு வகையான பயனர்கள் உள்ளனர்:

• சேவை கணக்குகள் - Kubernetes API ஆல் நிர்வகிக்கப்படும் கணக்குகள்;
• பயனர்கள் - வெளிப்புற, சுயாதீன சேவைகளால் நிர்வகிக்கப்படும் "சாதாரண" பயனர்கள்.

இந்த வகைகளுக்கு இடையிலான முக்கிய வேறுபாடு என்னவென்றால், சேவை கணக்குகளுக்கு குபெர்னெட்ஸ் API இல் சிறப்புப் பொருள்கள் உள்ளன (அவை என்று அழைக்கப்படுகின்றன - ServiceAccounts), இது ஒரு பெயர்வெளி மற்றும் இரகசிய வகையின் பொருள்களில் கிளஸ்டரில் சேமிக்கப்பட்ட அங்கீகார தரவுகளின் தொகுப்புடன் இணைக்கப்பட்டுள்ளது. இத்தகைய பயனர்கள் (சேவை கணக்குகள்) முதன்மையாக குபெர்னெட்ஸ் கிளஸ்டரில் இயங்கும் செயல்முறைகளின் குபெர்னெட்ஸ் ஏபிஐக்கான அணுகல் உரிமைகளை நிர்வகிப்பதை நோக்கமாகக் கொண்டுள்ளனர்.

சாதாரண பயனர்களுக்கு Kubernetes 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"

• 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

இதைச் செய்ய, அவற்றில் குறிப்பிடப்பட்டுள்ள கோப்புகளை பேஸ் 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.

ஆழமாக தோண்டு

விவரிக்கப்பட்டுள்ள சிக்கல்களை இன்னும் முழுமையாகப் புரிந்துகொள்ள விரும்புவோருக்கு:

• தனி கட்டுரை அதிகாரப்பூர்வ குபெர்னெட்ஸ் ஆவணத்தில் சான்றிதழ்களுடன் பணிபுரிவது;
• பிட்னாமியின் நல்ல கட்டுரை, இதில் சான்றிதழ்கள் வழங்குவது நடைமுறைக் கண்ணோட்டத்தில் தொட்டது.
• பொதுவான ஆவணங்கள் Kubernetes இல் அங்கீகாரம்.

அங்கீகாரம்

இயல்புநிலை அங்கீகரிக்கப்பட்ட கணக்கிற்கு கிளஸ்டரில் செயல்பட உரிமை இல்லை. அனுமதிகளை வழங்க, Kubernetes ஒரு அங்கீகார பொறிமுறையை செயல்படுத்துகிறது.

பதிப்பு 1.6க்கு முன், குபெர்னெட்டஸ் அங்கீகார வகையைப் பயன்படுத்தினார் ABAC (பண்பு அடிப்படையிலான அணுகல் கட்டுப்பாடு). அது பற்றிய விவரங்களை இதில் காணலாம் அதிகாரப்பூர்வ ஆவணங்கள். இந்த அணுகுமுறை தற்போது மரபுவழியாகக் கருதப்படுகிறது, ஆனால் நீங்கள் இன்னும் பிற அங்கீகார வகைகளுடன் இதைப் பயன்படுத்தலாம்.

ஒரு கிளஸ்டருக்கான அணுகல் உரிமைகளைப் பிரிப்பதற்கான தற்போதைய (மேலும் நெகிழ்வான) வழி அழைக்கப்படுகிறது RBAC (பங்கு அடிப்படையிலான அணுகல் கட்டுப்பாடு) இது பதிப்பிலிருந்து நிலையானதாக அறிவிக்கப்பட்டுள்ளது குபர்னெட்டஸ் 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 வழியாக Kubernetes இல் அணுகலைக் கட்டுப்படுத்த பின்வரும் API உட்பொருள்கள் பயன்படுத்தப்படுகின்றன:

• Role и ClusterRole - அணுகல் உரிமைகளை விவரிக்க உதவும் பாத்திரங்கள்:
• Role பெயர்வெளியில் உரிமைகளை விவரிக்க உங்களை அனுமதிக்கிறது;
• ClusterRole - கிளஸ்டருக்குள், கணுக்கள், வளங்கள் அல்லாத urlகள் போன்ற கிளஸ்டர்-குறிப்பிட்ட பொருள்கள் உட்பட (அதாவது குபெர்னெட்ஸ் ஆதாரங்களுடன் தொடர்புடையது அல்ல - எடுத்துக்காட்டாக, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - பிணைக்கப் பயன்படுகிறது Role и ClusterRole ஒரு பயனர், பயனர் குழு அல்லது சேவைக் கணக்கு.

ரோல் மற்றும் ரோல்பைண்டிங் நிறுவனங்கள் பெயர்வெளியால் வரையறுக்கப்பட்டுள்ளன, அதாவது. அதே பெயர்வெளிக்குள் இருக்க வேண்டும். இருப்பினும், RoleBinding ஆனது 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 ரன் இயக்கும்போது குபெர்னெட்டஸில் என்ன நடக்கிறது?".

சிஸ்டம் தணிக்கை என்பது குபெர்னெட்டஸில் உள்ள ஒரு சுவாரஸ்யமான அம்சமாகும், இது இயல்பாகவே முடக்கப்பட்டுள்ளது. அனைத்து அழைப்புகளையும் 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-apiserver ஆவணங்கள்.

ஏற்கனவே குறிப்பிட்டுள்ளபடி, அனைத்து அளவுருக்கள் மேனிஃபெஸ்டில் 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 - பதிவு கோப்பிற்கான பாதை. ஏபி-சர்வர் செயல்முறைக்கு பாதை அணுகக்கூடியதாக இருக்க வேண்டும், எனவே அதன் மவுண்டிங்கை நாங்கள் அதே வழியில் விவரிக்கிறோம்:

     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 டீமான், 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

பின்வரும் தணிக்கைக் கொள்கை சிறந்த நடைமுறைகளின் விளக்கமாக வழங்கப்படுகிறது அலிபாபா கிளவுட் ஆவணங்கள்:

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

தணிக்கைக் கொள்கையின் மற்றொரு சிறந்த எடுத்துக்காட்டு க.பொ.த.

தணிக்கை நிகழ்வுகளுக்கு விரைவாக பதிலளிக்க, அது சாத்தியமாகும் வெப்ஹூக்கை விவரிக்கவும். இந்த பிரச்சினை உள்ளடக்கப்பட்டுள்ளது அதிகாரப்பூர்வ ஆவணங்கள், இந்தக் கட்டுரையின் எல்லைக்கு வெளியே விட்டுவிடுகிறேன்.

முடிவுகளை

தனிப்பயனாக்கப்பட்ட பயனர் கணக்குகளை உருவாக்கவும், அவர்களின் உரிமைகளைப் பிரிக்கவும் மற்றும் அவர்களின் செயல்களைப் பதிவு செய்யவும் உங்களை அனுமதிக்கும் குபெர்னெட்ஸ் கிளஸ்டர்களில் உள்ள அடிப்படை பாதுகாப்பு வழிமுறைகளின் மேலோட்டத்தை கட்டுரை வழங்குகிறது. கோட்பாடாக அல்லது நடைமுறையில் இதுபோன்ற பிரச்சினைகளை எதிர்கொள்பவர்களுக்கு இது பயனுள்ளதாக இருக்கும் என்று நம்புகிறேன். "PS" இல் கொடுக்கப்பட்டுள்ள குபெர்னெட்ஸில் பாதுகாப்பு என்ற தலைப்பில் மற்ற பொருட்களின் பட்டியலைப் படிக்கவும் நான் பரிந்துரைக்கிறேன் - ஒருவேளை அவற்றில் உங்களுக்குத் தொடர்புடைய சிக்கல்கள் குறித்த தேவையான விவரங்களை நீங்கள் காணலாம்.

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• «33+ குபெர்னெட்ஸ் பாதுகாப்பு கருவிகள்";
• «பாதுகாப்பு நிபுணர்களுக்கான குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகளுக்கு ஒரு அறிமுகம்";
• «குபெர்னெட்டஸில் RBAC ஐப் புரிந்துகொள்வது";
• «குபெர்னெட்ஸ் பாதுகாப்பிற்கான 9 சிறந்த நடைமுறைகள்";
• «குபெர்னெட்ஸ் ஹேக்கின் பலியாக (இல்லை) 11 வழிகள்".

ஆதாரம்: www.habr.com