द एबीसी ऑफ सिक्युरिटी इन कुबर्नेट्स: ऑथेंटिकेशन, ऑथरायझेशन, ऑडिटिंग

लवकरच किंवा नंतर, कोणत्याही सिस्टमच्या ऑपरेशनमध्ये, सुरक्षिततेचा प्रश्न उद्भवतो: प्रमाणीकरण सुनिश्चित करणे, अधिकारांचे पृथक्करण, ऑडिटिंग आणि इतर कार्ये. Kubernetes साठी आधीच तयार केले आहे अनेक उपाय, जे तुम्हाला अत्यंत मागणी असलेल्या वातावरणातही मानकांचे पालन करण्यास अनुमती देते... समान सामग्री K8 च्या अंगभूत यंत्रणांमध्ये लागू केलेल्या सुरक्षिततेच्या मूलभूत पैलूंसाठी समर्पित आहे. सर्वप्रथम, जे कुबर्नेट्सशी परिचित होण्यास सुरुवात करत आहेत त्यांच्यासाठी ते उपयुक्त ठरेल - सुरक्षा-संबंधित समस्यांचा अभ्यास करण्यासाठी एक प्रारंभिक बिंदू म्हणून.

प्रमाणीकरण

कुबर्नेट्समध्ये दोन प्रकारचे वापरकर्ते आहेत:

• सेवा खाती — Kubernetes API द्वारे व्यवस्थापित केलेली खाती;
• वापरकर्ते - बाह्य, स्वतंत्र सेवांद्वारे व्यवस्थापित केलेले "सामान्य" वापरकर्ते.

या प्रकारांमधील मुख्य फरक असा आहे की सेवा खात्यांसाठी कुबर्नेट्स API मध्ये विशेष वस्तू आहेत (त्यांना असे म्हणतात - ServiceAccounts), जे नेमस्पेसशी जोडलेले आहेत आणि सीक्रेट्स प्रकारातील ऑब्जेक्ट्समध्ये क्लस्टरमध्ये संग्रहित केलेल्या अधिकृत डेटाच्या संचाला. असे वापरकर्ते (सेवा खाती) प्रामुख्याने Kubernetes क्लस्टरमध्ये चालणार्‍या प्रक्रियांच्या Kubernetes API मधील प्रवेश अधिकार व्यवस्थापित करण्यासाठी असतात.

सामान्य वापरकर्त्यांकडे Kubernetes API मध्ये नोंदी नसतात: त्या बाह्य यंत्रणेद्वारे व्यवस्थापित केल्या पाहिजेत. ते क्लस्टरच्या बाहेर राहणाऱ्या लोकांसाठी किंवा प्रक्रियांसाठी आहेत.

प्रत्येक API विनंती एकतर सेवा खाते, वापरकर्त्याशी संबंधित आहे किंवा निनावी मानली जाते.

वापरकर्ता प्रमाणीकरण डेटामध्ये हे समाविष्ट आहे:

• वापरकर्तानाव — वापरकर्तानाव (केस संवेदनशील!);
• यूआयडी - एक मशीन-वाचनीय वापरकर्ता ओळख स्ट्रिंग जी "वापरकर्तानावापेक्षा अधिक सुसंगत आणि अद्वितीय" आहे;
• गट — वापरकर्ता ज्या गटांशी संबंधित आहे त्यांची यादी;
• अतिरिक्त — अधिकृतता यंत्रणेद्वारे वापरले जाऊ शकणारे अतिरिक्त फील्ड.

Kubernetes मोठ्या प्रमाणात प्रमाणीकरण यंत्रणा वापरू शकतात: 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 क्लस्टर CA की वापरून प्रमाणपत्र विनंतीवर प्रक्रिया करणे, वापरकर्ता प्रमाणपत्र प्राप्त करणे (प्रमाणपत्र प्राप्त करण्यासाठी, तुम्ही कुबर्नेट्स क्लस्टर 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 क्लस्टरच्या एपीआय-सर्व्हरची शुद्धता तपासणार नाही):

    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: आवश्यक पत्ता जाहिरात करा एपीआय-सर्व्हर कॉन्फिगरेशनमध्ये आढळू शकते, जे डीफॉल्टनुसार स्थित आहे /etc/kubernetes/manifests/kube-apiserver.yaml.

परिणामी कॉन्फिगरेशन stdout वर आउटपुट होईल. मध्ये जतन करणे आवश्यक आहे ~/.kube/config वापरकर्ता खाते किंवा पर्यावरण व्हेरिएबलमध्ये निर्दिष्ट केलेल्या फाइलवर KUBECONFIG.

खोल खोदा

ज्यांना अधिक तपशीलवार वर्णन केलेल्या समस्या समजून घ्यायच्या आहेत त्यांच्यासाठी:

• स्वतंत्र लेख अधिकृत Kubernetes दस्तऐवजात प्रमाणपत्रांसह काम करताना;
• बिटनामीचा चांगला लेख, ज्यामध्ये प्रमाणपत्रांच्या मुद्द्याला व्यावहारिक दृष्टीकोनातून स्पर्श केला जातो.
• सामान्य दस्तऐवजीकरण Kubernetes मध्ये प्रमाणीकरण वर.

अधिकृतता

डीफॉल्ट अधिकृत खात्याला क्लस्टरवर ऑपरेट करण्याचे अधिकार नाहीत. परवानग्या देण्यासाठी, Kubernetes अधिकृतता यंत्रणा लागू करते.

आवृत्ती १.६ च्या आधी, कुबर्नेट्स नावाचा अधिकृत प्रकार वापरत असे ABAC (विशेषता-आधारित प्रवेश नियंत्रण). त्याबद्दलचे तपशील यामध्ये मिळू शकतात अधिकृत दस्तऐवजीकरण. हा दृष्टिकोन सध्या वारसा मानला जातो, परंतु तरीही तुम्ही इतर प्रमाणीकरण प्रकारांसोबत वापरू शकता.

क्लस्टरमध्ये प्रवेश अधिकार विभाजित करण्याचा वर्तमान (आणि अधिक लवचिक) मार्ग म्हणतात RBAC (भूमिका-आधारित प्रवेश नियंत्रण). आवृत्तीपासून ते स्थिर घोषित केले गेले आहे कुबर्नेट्स 1.8. RBAC एक हक्क मॉडेल लागू करते ज्यामध्ये स्पष्टपणे परवानगी नसलेली प्रत्येक गोष्ट प्रतिबंधित आहे.
RBAC सक्षम करण्यासाठी, तुम्हाला पॅरामीटरसह Kubernetes api-server सुरू करणे आवश्यक आहे --authorization-mode=RBAC. पॅरामीटर्स मॅनिफेस्टमध्ये एपीआय-सर्व्हर कॉन्फिगरेशनसह सेट केले जातात, जे डीफॉल्टनुसार मार्गावर स्थित असतात /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 वापरकर्ता, वापरकर्ता गट किंवा सेवा खाते.

भूमिका आणि रोलबाइंडिंग संस्था नेमस्पेसद्वारे मर्यादित आहेत, उदा. त्याच नेमस्पेसमध्ये असणे आवश्यक आहे. तथापि, रोलबाइंडिंग क्लस्टररोलचा संदर्भ देऊ शकते, जे तुम्हाला जेनेरिक परवानग्यांचा संच तयार करण्यास आणि त्यांचा वापर करून प्रवेश नियंत्रित करण्यास अनुमती देते.

भूमिका खालील नियमांचे संच वापरून अधिकारांचे वर्णन करतात:

• 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 मध्ये काय होते?».

सिस्टम ऑडिटिंग हे Kubernetes मधील एक मनोरंजक वैशिष्ट्य आहे, जे डीफॉल्टनुसार अक्षम केलेले आहे. हे तुम्हाला सर्व कॉल्स Kubernetes API वर लॉग करण्याची परवानगी देते. तुम्ही अंदाज लावू शकता, क्लस्टरची स्थिती निरीक्षण आणि बदलण्याशी संबंधित सर्व क्रिया या API द्वारे केल्या जातात. त्याच्या क्षमतांचे चांगले वर्णन (नेहमीप्रमाणे) मध्ये आढळू शकते अधिकृत दस्तऐवजीकरण K8s. पुढे मी विषय सोप्या भाषेत मांडण्याचा प्रयत्न करेन.

त्यामुळे ऑडिटिंग सक्षम करण्यासाठी, आम्हाला api-server मधील कंटेनरमध्ये तीन आवश्यक पॅरामीटर्स पास करणे आवश्यक आहे, ज्याचे खाली अधिक तपशीलवार वर्णन केले आहे:

• --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-apiserver दस्तऐवजीकरण.

आधीच नमूद केल्याप्रमाणे, सर्व पॅरामीटर्स मॅनिफेस्टमध्ये एपीआय-सर्व्हर कॉन्फिगरेशनसह सेट केले आहेत (डीफॉल्टनुसार /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 — लॉग फाइलचा मार्ग. पथ एपीआय-सर्व्हर प्रक्रियेसाठी देखील प्रवेशयोग्य असणे आवश्यक आहे, म्हणून आम्ही त्याच प्रकारे माउंटिंगचे वर्णन करतो:

     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.

पॉलिसी फाइलमध्ये, आम्ही वेगवेगळ्या लॉगिंग स्तरांसह अनेक विभागांचे वर्णन करू शकतो. पॉलिसी वर्णनात आढळणारा पहिला जुळणारा नियम लागू केला जाईल.

क्युबेलेट डिमन मॅनिफेस्टमधील बदलांचे एपीआय-सर्व्हर कॉन्फिगरेशनसह निरीक्षण करते आणि, जर काही आढळले तर, एपीआय-सर्व्हरसह कंटेनर रीस्टार्ट करते. परंतु एक महत्त्वाचा तपशील आहे: पॉलिसी फाइलमधील बदलांकडे दुर्लक्ष केले जाईल. पॉलिसी फाइलमध्ये बदल केल्यानंतर, तुम्हाला एपीआय-सर्व्हर मॅन्युअली रीस्टार्ट करावे लागेल. एपीआय-सर्व्हर म्हणून सुरू केले आहे स्थिर पॉड, संघ 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

ऑडिट पॉलिसीचे आणखी एक चांगले उदाहरण आहे GCE मध्ये वापरलेले प्रोफाइल.

ऑडिट इव्हेंट्सना त्वरित प्रतिसाद देण्यासाठी, हे शक्य आहे वेबहुकचे वर्णन करा. हा मुद्दा अंतर्भूत आहे अधिकृत दस्तऐवजीकरण, मी या लेखाच्या व्याप्तीच्या बाहेर सोडेन.

परिणाम

लेख Kubernetes क्लस्टर्समधील मूलभूत सुरक्षा यंत्रणेचे विहंगावलोकन प्रदान करतो, जे तुम्हाला वैयक्तिकृत वापरकर्ता खाती तयार करण्यास, त्यांचे अधिकार वेगळे करण्यास आणि त्यांच्या क्रिया रेकॉर्ड करण्यास अनुमती देतात. मला आशा आहे की ज्यांना सिद्धांत किंवा व्यवहारात अशा समस्यांचा सामना करावा लागतो त्यांच्यासाठी ते उपयुक्त ठरेल. मी अशी शिफारस देखील करतो की तुम्ही कुबर्नेट्समधील सुरक्षिततेच्या विषयावरील इतर सामग्रीची यादी वाचा, जी “PS” मध्ये दिली आहे - कदाचित त्यापैकी तुम्हाला तुमच्याशी संबंधित समस्यांबद्दल आवश्यक तपशील सापडतील.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «33+ Kubernetes सुरक्षा साधने";
• «सुरक्षा व्यावसायिकांसाठी कुबर्नेट्स नेटवर्क धोरणांचा परिचय";
• «कुबर्नेट्समध्ये आरबीएसी समजून घेणे";
• «कुबर्नेट्स सुरक्षिततेसाठी 9 सर्वोत्तम पद्धती";
• «कुबर्नेट्स हॅकचा बळी बनण्याचे (नाही) 11 मार्ग».

स्त्रोत: www.habr.com