कुबेरनेट्स में सुरक्षा का एबीसी: प्रमाणीकरण, प्राधिकरण, लेखा परीक्षा

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

प्रमाणीकरण

कुबेरनेट्स में दो प्रकार के उपयोगकर्ता हैं:

• सेवा खाते - कुबेरनेट्स एपीआई द्वारा प्रबंधित खाते;
• उपयोगकर्ता - बाहरी, स्वतंत्र सेवाओं द्वारा प्रबंधित "सामान्य" उपयोगकर्ता।

इन प्रकारों के बीच मुख्य अंतर यह है कि सेवा खातों के लिए कुबेरनेट्स एपीआई में विशेष ऑब्जेक्ट हैं (उन्हें कहा जाता है - ServiceAccounts), जो कि नेमस्पेस और सीक्रेट प्रकार की वस्तुओं में क्लस्टर में संग्रहीत प्राधिकरण डेटा के एक सेट से बंधे हैं। ऐसे उपयोगकर्ताओं (सेवा खाते) का उद्देश्य मुख्य रूप से कुबेरनेट्स क्लस्टर में चल रही प्रक्रियाओं के कुबेरनेट्स एपीआई तक पहुंच अधिकारों का प्रबंधन करना है।

सामान्य उपयोगकर्ताओं के पास कुबेरनेट्स एपीआई में प्रविष्टियाँ नहीं हैं: उन्हें बाहरी तंत्र द्वारा प्रबंधित किया जाना चाहिए। वे क्लस्टर के बाहर रहने वाले लोगों या प्रक्रियाओं के लिए अभिप्रेत हैं।

प्रत्येक एपीआई अनुरोध या तो एक सेवा खाते, एक उपयोगकर्ता से जुड़ा होता है, या गुमनाम माना जाता है।

उपयोगकर्ता प्रमाणीकरण डेटा में शामिल हैं:

• उपयोगकर्ता नाम — उपयोक्तानाम (केस संवेदनशील!);
• यूआईडी - एक मशीन-पठनीय उपयोगकर्ता पहचान स्ट्रिंग जो "उपयोगकर्ता नाम से अधिक सुसंगत और अद्वितीय" है;
• समूह - उन समूहों की सूची जिनसे उपयोगकर्ता संबंधित है;
• अतिरिक्त - अतिरिक्त फ़ील्ड जिनका उपयोग प्राधिकरण तंत्र द्वारा किया जा सकता है।

कुबेरनेट्स बड़ी संख्या में प्रमाणीकरण तंत्र का उपयोग कर सकते हैं: X509 प्रमाणपत्र, बियरर टोकन, प्रमाणीकरण प्रॉक्सी, HTTP बेसिक ऑथ। इन तंत्रों का उपयोग करके, आप बड़ी संख्या में प्राधिकरण योजनाओं को कार्यान्वित कर सकते हैं: पासवर्ड वाली एक स्थिर फ़ाइल से लेकर OpenID OAuth2 तक।

इसके अलावा, एक साथ कई प्राधिकरण योजनाओं का उपयोग करना संभव है। डिफ़ॉल्ट रूप से, क्लस्टर उपयोग करता है:

• सेवा खाता टोकन - सेवा खातों के लिए;
• X509 - उपयोगकर्ताओं के लिए.

ServiceAccounts के प्रबंधन के बारे में प्रश्न इस लेख के दायरे से परे है, लेकिन जो लोग इस मुद्दे से अधिक विस्तार से परिचित होना चाहते हैं, मैं उनसे शुरुआत करने की सलाह देता हूं। आधिकारिक दस्तावेज़ीकरण पृष्ठ. हम इस मुद्दे पर करीब से नज़र डालेंगे कि 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 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.

गहरी खुदाई

उन लोगों के लिए जो वर्णित मुद्दों को अधिक गहनता से समझना चाहते हैं:

• अलग लेख आधिकारिक कुबेरनेट्स दस्तावेज़ीकरण में प्रमाणपत्रों के साथ काम करने पर;
• बिटनामी का अच्छा लेख, जिसमें प्रमाणपत्रों के मुद्दे को व्यावहारिक दृष्टिकोण से छुआ गया है।
• सामान्य दस्तावेज़ीकरण कुबेरनेट्स में प्रमाणीकरण पर।

प्राधिकरण

डिफ़ॉल्ट अधिकृत खाते के पास क्लस्टर पर संचालन का अधिकार नहीं है। अनुमतियाँ देने के लिए, कुबेरनेट्स एक प्राधिकरण तंत्र लागू करता है।

संस्करण 1.6 से पहले, कुबेरनेट्स नामक प्राधिकरण प्रकार का उपयोग करता था एबीएसी (विशेषता-आधारित अभिगम नियंत्रण)। इसके बारे में विवरण यहां पाया जा सकता है आधिकारिक दस्तावेज. इस दृष्टिकोण को वर्तमान में विरासत माना जाता है, लेकिन आप अभी भी इसे अन्य प्रमाणीकरण प्रकारों के साथ उपयोग कर सकते हैं।

क्लस्टर तक पहुंच अधिकारों को विभाजित करने का वर्तमान (और अधिक लचीला) तरीका कहा जाता है RBAC (भूमिका आधारित अभिगम नियंत्रण). संस्करण से इसे स्थिर घोषित किया गया है कुबेरनेट्स 1.8. आरबीएसी एक अधिकार मॉडल लागू करता है जिसमें वह सब कुछ निषिद्ध है जिसकी स्पष्ट रूप से अनुमति नहीं है।
आरबीएसी को सक्षम करने के लिए, आपको पैरामीटर के साथ कुबेरनेट्स एपीआई-सर्वर शुरू करने की आवश्यकता है --authorization-mode=RBAC. पैरामीटर मैनिफ़ेस्ट में एपीआई-सर्वर कॉन्फ़िगरेशन के साथ सेट किए गए हैं, जो डिफ़ॉल्ट रूप से पथ के साथ स्थित है /etc/kubernetes/manifests/kube-apiserver.yaml, अनुभाग में command. हालाँकि, आरबीएसी पहले से ही डिफ़ॉल्ट रूप से सक्षम है, इसलिए सबसे अधिक संभावना है कि आपको इसके बारे में चिंता नहीं करनी चाहिए: आप इसे मूल्य से सत्यापित कर सकते हैं authorization-mode (पहले से ही उल्लेखित में kube-apiserver.yaml). वैसे, इसके अर्थों में प्राधिकरण के अन्य प्रकार भी हो सकते हैं (node, webhook, always allow), लेकिन हम उनके विचार को सामग्री के दायरे से बाहर छोड़ देंगे।

वैसे, हम पहले ही प्रकाशित कर चुके हैं लेख आरबीएसी के साथ काम करने के सिद्धांतों और विशेषताओं का काफी विस्तृत विवरण के साथ, इसलिए आगे मैं खुद को बुनियादी बातों और उदाहरणों की एक संक्षिप्त सूची तक सीमित रखूंगा।

आरबीएसी के माध्यम से कुबेरनेट्स में पहुंच को नियंत्रित करने के लिए निम्नलिखित एपीआई इकाइयों का उपयोग किया जाता है:

• Role и ClusterRole - भूमिकाएँ जो पहुँच अधिकारों का वर्णन करने का काम करती हैं:
• Role आपको नामस्थान के भीतर अधिकारों का वर्णन करने की अनुमति देता है;
• ClusterRole - क्लस्टर के भीतर, क्लस्टर-विशिष्ट ऑब्जेक्ट जैसे नोड्स, गैर-संसाधन यूआरएल (यानी कुबेरनेट्स संसाधनों से संबंधित नहीं - उदाहरण के लिए, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - बाइंडिंग के लिए उपयोग किया जाता है Role и ClusterRole किसी उपयोगकर्ता, उपयोगकर्ता समूह या सेवा खाते के लिए।

भूमिका और भूमिकाबाइंडिंग इकाइयाँ नामस्थान द्वारा सीमित हैं, अर्थात। समान नामस्थान में होना चाहिए. हालाँकि, एक रोलबाइंडिंग एक क्लस्टररोल को संदर्भित कर सकता है, जो आपको सामान्य अनुमतियों का एक सेट बनाने और उनका उपयोग करके पहुंच को नियंत्रित करने की अनुमति देता है।

भूमिकाएँ नियमों के सेट का उपयोग करके अधिकारों का वर्णन करती हैं:

• एपीआई समूह - देखें आधिकारिक दस्तावेज एपीआईग्रुप्स और आउटपुट द्वारा kubectl api-resources;
• संसाधन (संसाधन: pod, namespace, deployment और इसी तरह।);
• क्रिया (verbs के: set, update आदि).
• संसाधन नाम (resourceNames) - उस स्थिति के लिए जब आपको किसी विशिष्ट संसाधन तक पहुंच प्रदान करने की आवश्यकता होती है, न कि इस प्रकार के सभी संसाधनों तक।

कुबेरनेट्स में प्राधिकरण का अधिक विस्तृत विश्लेषण पृष्ठ पर पाया जा सकता है आधिकारिक दस्तावेज. इसके बजाय (या इसके अतिरिक्त), मैं ऐसे उदाहरण दूंगा जो उसके काम को दर्शाते हैं।

आरबीएसी संस्थाओं के उदाहरण

सरल 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

इवेंट ऑडिट

योजनाबद्ध रूप से, कुबेरनेट्स वास्तुकला को निम्नानुसार दर्शाया जा सकता है:

अनुरोधों को संसाधित करने के लिए जिम्मेदार कुबेरनेट्स घटक प्रमुख है एपीआई-सर्वर. क्लस्टर पर सभी ऑपरेशन इसके माध्यम से चलते हैं। आप इन आंतरिक तंत्रों के बारे में लेख में अधिक पढ़ सकते हैं "जब आप कुबेक्टल रन चलाते हैं तो कुबेरनेट्स में क्या होता है?'.

कुबेरनेट्स में सिस्टम ऑडिटिंग एक दिलचस्प सुविधा है, जो डिफ़ॉल्ट रूप से अक्षम है। यह आपको कुबेरनेट्स एपीआई में सभी कॉल लॉग करने की अनुमति देता है। जैसा कि आप अनुमान लगा सकते हैं, क्लस्टर की स्थिति की निगरानी और परिवर्तन से संबंधित सभी क्रियाएं इस एपीआई के माध्यम से की जाती हैं। इसकी क्षमताओं का एक अच्छा विवरण (हमेशा की तरह) इसमें पाया जा सकता है आधिकारिक दस्तावेज K8s. आगे मैं विषय को सरल भाषा में प्रस्तुत करने का प्रयास करूँगा।

इस प्रकार, ऑडिटिंग सक्षम करने के लिए, हमें एपीआई-सर्वर में कंटेनर में तीन आवश्यक पैरामीटर पास करने की आवश्यकता है, जिनका नीचे अधिक विवरण में वर्णन किया गया है:

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

लेकिन हम उन पर अधिक विस्तार से ध्यान नहीं देंगे - आप सभी विवरण यहां पा सकते हैं क्यूब-एपिसर्वर दस्तावेज़ीकरण.

जैसा कि पहले ही उल्लेख किया गया है, सभी पैरामीटर मैनिफ़ेस्ट में एपीआई-सर्वर कॉन्फ़िगरेशन (डिफ़ॉल्ट रूप से) के साथ सेट किए गए हैं /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) उन अनुरोधों को लॉग न करें जिनमें संसाधनों (तथाकथित गैर-संसाधन यूआरएल तक पहुंच) तक पहुंच नहीं है।

साथ ही सभी अनुरोध पूरे हो जाते हैं कई चरण:

• RequestReceived - वह चरण जब अनुरोध प्रोसेसर द्वारा प्राप्त किया जाता है और अभी तक प्रोसेसर की श्रृंखला के साथ आगे प्रेषित नहीं किया गया है;
• ResponseStarted - प्रतिक्रिया शीर्षलेख भेजे जाते हैं, लेकिन प्रतिक्रिया निकाय भेजे जाने से पहले। लंबे समय तक चलने वाली क्वेरीज़ के लिए जेनरेट किया गया (उदाहरण के लिए, watch);
• ResponseComplete - प्रतिक्रिया निकाय भेज दिया गया है, कोई और जानकारी नहीं भेजी जाएगी;
• Panic - असामान्य स्थिति का पता चलने पर घटनाएँ उत्पन्न होती हैं।

किसी भी चरण को छोड़ने के लिए आप इसका उपयोग कर सकते हैं omitStages.

एक नीति फ़ाइल में, हम विभिन्न लॉगिंग स्तरों के साथ कई अनुभागों का वर्णन कर सकते हैं। पॉलिसी विवरण में पाया गया पहला मिलान नियम लागू किया जाएगा।

क्यूबलेट डेमॉन एपीआई-सर्वर कॉन्फ़िगरेशन के साथ मैनिफ़ेस्ट में परिवर्तनों की निगरानी करता है और, यदि कोई पता चलता है, तो एपीआई-सर्वर के साथ कंटेनर को पुनरारंभ करता है। लेकिन एक महत्वपूर्ण विवरण है: नीति फ़ाइल में परिवर्तनों को इसके द्वारा अनदेखा कर दिया जाएगा. पॉलिसी फ़ाइल में बदलाव करने के बाद, आपको एपीआई-सर्वर को मैन्युअल रूप से पुनरारंभ करना होगा। चूंकि एपीआई-सर्वर के रूप में शुरू किया गया है स्थैतिक फली, टीम kubectl delete इसे पुनः आरंभ करने का कारण नहीं बनेगा. आपको इसे मैन्युअल रूप से करना होगा docker stop क्यूब-मास्टर्स पर, जहां ऑडिट नीति बदल दी गई है:

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);
• क्रिया (verbs के: get, update, delete और दूसरे);
• संसाधन (संसाधनके रूप में निम्नानुसार है: pod, configmaps आदि) और संसाधन समूह (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

ऑडिट नीति का एक और अच्छा उदाहरण है जीसीई में प्रयुक्त प्रोफ़ाइल.

ऑडिट घटनाओं पर तुरंत प्रतिक्रिया देना संभव है वेबहुक का वर्णन करें. इस मुद्दे को शामिल किया गया है आधिकारिक दस्तावेज, मैं इसे इस लेख के दायरे से बाहर छोड़ दूँगा।

परिणाम

लेख कुबेरनेट्स क्लस्टर में बुनियादी सुरक्षा तंत्र का अवलोकन प्रदान करता है, जो आपको वैयक्तिकृत उपयोगकर्ता खाते बनाने, उनके अधिकारों को अलग करने और उनके कार्यों को रिकॉर्ड करने की अनुमति देता है। मुझे आशा है कि यह उन लोगों के लिए उपयोगी होगा जो सिद्धांत या व्यवहार में ऐसे मुद्दों का सामना करते हैं। मैं यह भी अनुशंसा करता हूं कि आप कुबेरनेट्स में सुरक्षा के विषय पर अन्य सामग्रियों की सूची पढ़ें, जो "पीएस" में दी गई है - शायद उनमें से आपको उन समस्याओं पर आवश्यक विवरण मिलेंगे जो आपके लिए प्रासंगिक हैं।

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

• «33+ कुबेरनेट्स सुरक्षा उपकरण";
• «सुरक्षा पेशेवरों के लिए कुबेरनेट्स नेटवर्क नीतियों का परिचय";
• «कुबेरनेट्स में आरबीएसी को समझना";
• «कुबेरनेट्स सुरक्षा के लिए 9 सर्वोत्तम अभ्यास";
• «कुबेरनेट्स हैक का शिकार बनने (नहीं) के 11 तरीके'.

स्रोत: www.habr.com