🖱️ 🕵🏻 🎊 कुबेरनेट्स में सुरक्षा के एबीसी: प्रमाणीकरण, प्राधिकरण, लेखा परीक्षा 👩🏿‍💼 🌛 ↔️

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

प्रमाणीकरण

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

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

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

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

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

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

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

Kubernetes बड़ी संख्या में प्रमाणीकरण तंत्र का उपयोग कर सकते हैं: 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"

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 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 के साथ प्रमाण पत्र

Kubernetes 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 वातावरण KUBECONFIG में निर्दिष्ट फ़ाइल में सहेजा जाना चाहिए।

गहरा खोदो

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

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

प्राधिकरण

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

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

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

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

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

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

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

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

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

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

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: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]

उदाहरण RoleBinding , जो उपयोगकर्ता mynewuser my-namespace में "पठन" mynewuser अनुमति देता है:

 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 API पर सभी कॉल लॉग करने की अनुमति देता है। जैसा कि आप आसानी से अनुमान लगा सकते हैं, इस एपीआई के माध्यम से क्लस्टर की स्थिति की निगरानी और बदलने से संबंधित सभी क्रियाएं की जाती हैं। इसकी विशेषताओं का एक अच्छा विवरण (सामान्य रूप से) आधिकारिक 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

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

जैसा कि पहले ही उल्लेख किया गया है, सभी पैरामीटर command अनुभाग में एपीआई-सर्वर कॉन्फ़िगरेशन (डिफ़ॉल्ट रूप से /etc/kubernetes/manifests/kube-apiserver.yaml ) के साथ प्रकट होते हैं। आइए 3 आवश्यक मापदंडों पर वापस जाएं और उनका विश्लेषण करें:

audit-policy-file - ऑडिट पॉलिसी के विवरण के साथ YAML फ़ाइल का पथ। हम इसकी सामग्री पर लौट आएंगे, लेकिन अब मैं ध्यान देता हूं कि फ़ाइल एपीआई सर्वर प्रक्रिया द्वारा पढ़ने के लिए सुलभ होनी चाहिए। इसलिए, कंटेनर के अंदर इसे माउंट करना आवश्यक है, जिसके लिए आप निम्न कोड को कॉन्फ़िगर के उपयुक्त अनुभागों में जोड़ सकते हैं:
```
  volumeMounts: - mountPath: /etc/kubernetes/policies name: policies readOnly: true volumes: - hostPath: path: /etc/kubernetes/policies type: DirectoryOrCreate name: policies 
```
audit-log-path - लॉग फाइल का पथ। पथ को एपीआई सर्वर प्रक्रिया के लिए भी सुलभ होना चाहिए, इसलिए, हम इसी तरह से इसके बढ़ते का वर्णन करते हैं:
```
  volumeMounts: - mountPath: /var/log/kube-audit name: logs readOnly: false volumes: - hostPath: path: /var/log/kube-audit type: DirectoryOrCreate name: logs 
```
audit-log-format - ऑडिट लॉग का प्रारूप। डिफ़ॉल्ट रूप से, यह json , लेकिन विरासत पाठ प्रारूप भी उपलब्ध है।

ऑडिट नीति

अब लॉगिंग पॉलिसी के विवरण के साथ उल्लिखित फ़ाइल के बारे में। ऑडिट पॉलिसी की पहली अवधारणा level , लॉगिंग का स्तर है । वे इस प्रकार हैं:

None - लॉग न करें;
Metadata - लॉग अनुरोध मेटाडेटा: उपयोगकर्ता, अनुरोध समय, लक्ष्य संसाधन (पॉड, नेमस्पेस, आदि), एक्शन प्रकार (क्रिया), आदि;
Request - लॉग मेटाडेटा और अनुरोध निकाय;
RequestResponse - RequestResponse मेटाडेटा, अनुरोध निकाय और प्रतिक्रिया निकाय।

पिछले दो स्तर ( Request और Request ) उन अनुरोधों को लॉग नहीं करते हैं, जो संसाधनों तक नहीं RequestResponse (तथाकथित गैर-संसाधन आग्रह को कहते हैं)।

इसके अलावा, सभी अनुरोध कई चरणों से गुजरते हैं:

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

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

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

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

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

जब आप ऑडिटिंग को सक्षम करते हैं, तो यह याद रखना महत्वपूर्ण है कि क्यूब-अपीज़र का भार अधिक होता है । विशेष रूप से, अनुरोधों के संदर्भ को संग्रहीत करने के लिए मेमोरी की खपत बढ़ रही है। प्रतिक्रिया शीर्षलेख भेजने के बाद ही लॉगिंग शुरू होती है। इसके अलावा, लोड ऑडिट पॉलिसी के कॉन्फ़िगरेशन पर निर्भर करता है।

नीति उदाहरण

आइए उदाहरणों का उपयोग करते हुए नीति फ़ाइलों की संरचना का विश्लेषण करें।

Metadata स्तर पर सब कुछ लॉग करने के लिए यहां एक सरल policy फ़ाइल है:

 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 )।

ध्यान दो! संसाधन और संसाधन समूह (एपीआई समूह, यानी एपीग्रुप), साथ ही साथ क्लस्टर में स्थापित उनके संस्करण, कमांड का उपयोग करके प्राप्त किए जा सकते हैं:

 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

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

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

परिणाम

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

पुनश्च

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

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