Kubernetes RBAC उपयोगकर्ता और प्राधिकरण

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

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

( सीएनसीएफ ब्लॉग से लिया गया चित्रण - लगभग। अनुवाद।)

यह आलेख X.509 क्लाइंट प्रमाणपत्रों का उपयोग करने वाले उपयोगकर्ताओं को कैसे बनाया जाए, और कुबेरनेट्स में मूल आरबीएसी एपीआई का उपयोग करके प्राधिकरण का प्रबंधन कैसे करें। हम कुछ ओपन सोर्स प्रोजेक्ट्स के बारे में भी बात करेंगे, जो क्लस्टर एडमिनिस्ट्रेशन को सरल बनाते हैं: रक्केस, कुब्लेट-जो-कैन, आरबैक-लुकअप और आरबीएसी मैनेजर।

पूर्वधारणाएँ और मान्यताएँ

सबसे पहले, कई धारणाएं बनाना आवश्यक है:

• कम से कम आप कल्पना कर सकते हैं कि कुबेरनेट कैसे काम करता है ।
• आपके पास एक काम करने वाला कुबेरनेट्स या मिनिक्यूब क्लस्टर है ।
• आपके पास kubectl CLI उपयोगिता स्थापित है ।
• आपके पास ओपनएसएसएल पैकेज स्थापित है।

यदि आपके पास एक तैयार कुबेरनेट्स क्लस्टर नहीं है, तो मेरा सुझाव है कि आप एक सहकर्मी के लेख (आर्थर BUSSER) का उल्लेख करें जिसमें वह वैग्रांट का उपयोग करके CentOS 7 पर कुबेरनेट्स स्थापित करने के बारे में बात करता है।

हमारे क्लस्टर में 4 नोड हैं: एक मास्टर और 3 श्रमिक। विज़ार्ड का उपयोग क्लस्टर के साथ बातचीत करने के लिए एज नोड के रूप में भी किया जाएगा।

RBAC API

भूमिका-आधारित अभिगम नियंत्रण (RBAC) एक कंपनी में व्यक्तिगत उपयोगकर्ताओं की भूमिकाओं के आधार पर कंप्यूटर और नेटवर्क संसाधनों तक पहुंच को नियंत्रित करने की एक विधि है। RBAC का उपयोग उन सभी कुबेरनेट संसाधनों के साथ किया जा सकता है जो CRUD (क्रिएट, रीड, अपडेट, डिलीट) का समर्थन करते हैं। ऐसे संसाधनों के उदाहरण:

• नाम स्थान;
• Pod'y;
• Deployment'y;
• लगातार वॉल्यूम (PersistentVolumes);
• ConfigMap'y।

और यहां उनके साथ संभावित संचालन के उदाहरण हैं:

• create ;
• get (स्वागत);
• delete (हटाना) ;
• list ( list दृश्य) ;
• update ।

कुबेरनेट्स में RBAC का प्रबंधन करने के लिए, हमें घोषणा करने की आवश्यकता है:

• Role और ClusterRole । ये केवल अनुमतियों के एक सेट का प्रतिनिधित्व करने वाले नियम सेट हैं। Role उपयोग केवल नामस्थानों के भीतर संसाधनों तक पहुंच प्रदान करने के लिए किया जा सकता है। ClusterRole Role रूप में एक ही अनुमतियाँ प्रदान कर सकता है, और पूरे क्लस्टर के भीतर उपलब्ध संसाधनों तक भी पहुँच प्रदान करता है, और तथाकथित गैर-संसाधन समापन बिंदु (जैसे /healthz - लगभग। अनुवाद) ।
• Subjects । विषय एक इकाई है जो एक क्लस्टर में संचालन करेगा। यह उपयोगकर्ता, सेवाएँ या समूह भी हो सकते हैं।
• RoleBinding और ClusterRoleBinding । जैसा कि नाम से ही स्पष्ट है, यह केवल एक भूमिका या क्लस्टरस्टर के अधीन है।

कुबेरनेट्स की डिफ़ॉल्ट भूमिकाएँ हैं:

• view : रीड-ओनली एक्सेस, रहस्यों को छोड़कर;
• edit : उपरोक्त + अधिकांश संसाधनों को संपादित करने की क्षमता, भूमिकाओं और भूमिका बंधनों को छोड़कर;
• admin : उपरोक्त + नामस्थान स्तर पर भूमिकाओं और रोल मैपिंग को प्रबंधित करने की क्षमता;
• cluster-admin : सभी संभावित विशेषाधिकार।

बेशक, आप अपने स्वयं के Roles और ClusterRoles बना सकते हैं, लेकिन हम अनुशंसा करते हैं कि आप यथासंभव यथासंभव डिफ़ॉल्ट भूमिकाओं का उपयोग करें। अन्यथा, आप जल्दी से इस सब में भ्रमित हो सकते हैं।

उदाहरण का उपयोग करें

हम दो नामस्थान बनायेंगे: my-project-dev और my-project-prod , - साथ ही दो उपयोगकर्ता: jean और sarah - इन नामस्थानों में अलग-अलग भूमिकाओं के साथ:

• मेरी परियोजना-देव:
  
  • जीन: संपादित करें
• मेरी परियोजना-prod:
  
  • जीन: देखें
  • सारा: संपादित करें

X.509 क्लाइंट प्रमाणपत्रों का उपयोग करके उपयोगकर्ताओं को बनाएं और प्रमाणित करें

आमतौर पर, दो प्रकार के उपयोगकर्ता होते हैं: कुबेरनेट्स, और नियमित उपयोगकर्ताओं द्वारा प्रबंधित सेवा खाते । हम बाद पर ध्यान केंद्रित करेंगे। यहां बताया गया है कि उन्हें आधिकारिक दस्तावेज में कैसे वर्णित किया गया है:

यह माना जाता है कि नियमित उपयोगकर्ता एक बाहरी, स्वतंत्र सेवा द्वारा प्रबंधित होते हैं। भूमिका निजी कुंजी, एक उपयोगकर्ता रिपॉजिटरी जैसे किस्टोन या Google खाते, या यहां तक ​​कि उपयोगकर्ता नाम और पासवर्ड की एक सूची के साथ एक वितरण वितरित करने वाले व्यवस्थापक द्वारा निभाई जा सकती है। इस संबंध में, कुबेरनेट्स के पास सामान्य उपयोगकर्ताओं का प्रतिनिधित्व करने वाली कोई वस्तु नहीं है। API कॉल के माध्यम से साधारण उपयोगकर्ताओं को क्लस्टर में नहीं जोड़ा जा सकता है।

नियमित उपयोगकर्ताओं को प्रबंधित करने के कई तरीके हैं:

• मूल प्रामाणिक :
  • निम्नलिखित (या समान) सामग्री के साथ एपीआई सर्वर में कॉन्फ़िगरेशन को स्थानांतरित करना: पासवर्ड, उपयोगकर्ता नाम, यूआईडी, समूह;
• X.509 ग्राहक प्रमाणपत्र:
  • उपयोगकर्ता की गुप्त कुंजी और प्रमाणपत्र हस्ताक्षर अनुरोध का निर्माण;
  • उपयोगकर्ता प्रमाणपत्र प्राप्त करने के लिए प्रमाणन प्राधिकरण (कुबेरनेट्स सीए) में प्रमाणीकरण;
• बियरर टोकन (JSON वेब कैम, JWT):
  • ओपेनआईडी कनेक्ट
  • OAuth 2.0 के शीर्ष पर प्रमाणीकरण परत;
  • वेब हुक (webhooks)।

इस लेख में, हम उनकी सरलता के कारण X.509 और ओपनएसएसएल प्रमाणपत्रों का उपयोग करेंगे। उपयोगकर्ता बनाना कई चरणों में होता है - हम उन सभी के माध्यम से जाएंगे। क्लस्टर (क्लस्टर-व्यवस्थापक) के व्यवस्थापक विशेषाधिकारों के साथ उपयोगकर्ता खाते के तहत संचालन किया जाना चाहिए। यहां उपयोगकर्ता बनाने के लिए सभी चरण दिए गए हैं (उदाहरण के रूप में jean का उपयोग करते हुए):

• विज़ार्ड पर एक उपयोगकर्ता बनाएं, और फिर शेष चरणों को पूरा करने के लिए उसके घर निर्देशिका पर जाएं:
  
  

   useradd jean && cd /home/jean 

• एक निजी कुंजी बनाएँ:
  
  

   openssl genrsa -out jean.key 2048 

• प्रमाणपत्र हस्ताक्षर अनुरोध (CSR) बनाएं। CN उपयोगकर्ता नाम है, O समूह है। आप समूह द्वारा अनुमतियाँ सेट कर सकते हैं। यह कार्य को सरल करेगा यदि, उदाहरण के लिए, आपके पास एक ही अनुमति वाले कई उपयोगकर्ता हैं:
  
  

   #   openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean" #     $group openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group" #       openssl req -new -key jean.key \ -out jean.csr \ -subj "/CN=jean/O=$group1/O=$group2/O=$group3" 

• Kubernetes CA में CSR साइन करें। हमें CA प्रमाणपत्र और कुंजी का उपयोग करना चाहिए, जो आमतौर पर /etc/kubernetes/pki । प्रमाणपत्र 500 दिनों के लिए मान्य होगा:
  
  

   openssl x509 -req -in jean.csr \ -CA /etc/kubernetes/pki/ca.crt \ -CAkey /etc/kubernetes/pki/ca.key \ -CAcreateserial \ -out jean.crt -days 500 

• .certs निर्देशिका बनाएँ। इसमें हम उपयोगकर्ता की सार्वजनिक और निजी कुंजी संग्रहीत करेंगे:
  
  

   mkdir .certs && mv jean.crt jean.key .certs 

• कुबेरनेट्स के अंदर एक उपयोगकर्ता बनाएं:
  
  

   kubectl config set-credentials jean \ --client-certificate=/home/jean/.certs/jean.crt \ --client-key=/home/jean/.certs/jean.key 

• उपयोगकर्ता के लिए संदर्भ सेट करें:
  
  

   kubectl config set-context jean-context \ --cluster=kubernetes --user=jean 

• उपयोगकर्ता कॉन्फ़िगरेशन फ़ाइल संपादित करें। इसमें क्लस्टर में प्रमाणीकरण के लिए आवश्यक जानकारी है। आप क्लस्टर कॉन्फ़िगरेशन फ़ाइल का उपयोग कर सकते हैं, जो आमतौर पर /etc/kubernetes में निहित /etc/kubernetes : certificate-authority-data और server चर उसी तरह होना चाहिए जैसा कि उल्लेखित फ़ाइल में है:
  
  

   apiVersion: v1 clusters: - cluster: certificate-authority-data: {  } server: {  } name: kubernetes contexts: - context: cluster: kubernetes user: jean name: jean-context current-context: jean-context kind: Config preferences: {} users: - name: jean user: client-certificate: /home/jean/.certs/jean.cert client-key: /home/jean/.certs/jean.key 

  
  अब आपको .kube निर्देशिका में उपरोक्त कॉन्फिग कॉपी करने की आवश्यकता है:
  
  

   mkdir .kube && vi .kube/config 

• यह उपयोगकर्ता को सभी बनाई गई फ़ाइलों और निर्देशिकाओं का स्वामी बना देता है:
  
  

   chown -R jean: /home/jean/ 

उपयोगकर्ता jean सफलतापूर्वक बनाया jean । हम sarah लिए भी ऐसा ही करेंगे। काफी कुछ चरण हैं, और बड़ी संख्या में उपयोगकर्ताओं को बनाने में लंबा समय लग सकता है। इसलिए, मैंने बैश स्क्रिप्ट लिखी जो प्रक्रिया को स्वचालित करती है: उन्हें गिटहब पर भंडार में पाया जा सकता है ।

लगभग। ट्रांस। : जैसा कि हमने अपने हालिया लेख में लिखा है, इस प्रक्रिया को कुबेरनेट्स में अधिक "देशी" तरीके से सरल बनाया जा सकता है - कुबेडम कंसोल उपयोगिता में नई सुविधाओं के माध्यम से। हालाँकि, याद रखें कि इस अनुवाद के प्रकाशन के समय, वे अल्फा रूप में उपलब्ध हैं। एक उपयोगकर्ता बनाने के लिए एक कमांड का एक उदाहरण kubeadm alpha kubeconfig user ।

अब हमारे पास उपयोगकर्ता हैं, और हम दो नाम स्थान बनाने के लिए आगे बढ़ सकते हैं:

 kubectl create namespace my-project-dev kubectl create namespace my-project-prod 

चूंकि हमने अभी तक उपयोगकर्ता प्राधिकरण निर्धारित नहीं किया है, इसलिए उन्हें क्लस्टर संसाधनों तक पहुंच नहीं होनी चाहिए:

 User: Jean kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "jean" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "jean" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

 User: Sarah kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "sarah" cannot list resource "nodes" in API group "" at the cluster scope kubectl get pods -n default Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "default" kubectl get pods -n my-project-prod Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-prod" kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" 

रोल और क्लस्टर का निर्माण

हम डिफ़ॉल्ट रूप से उपलब्ध ClusterRole का उपयोग करेंगे। हालाँकि, हम यह भी दिखाते हैं कि अपना Role और ClusterRole कैसे बनाएं। संक्षेप में, Role और ClusterRole केवल क्रियाओं का एक सेट है (जिसे verbs कहा जाता verbs , ClusterRole , शब्दशः - क्रिया) जो कुछ संसाधनों और नामस्थानों के लिए अनुमत हैं। यहाँ एक उदाहरण YAML फ़ाइल है:

 apiVersion: rbac.authorization.k8s.io/v1beta1 kind: Role metadata: name: list-deployments namespace: my-project-dev rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] --------------------------------- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: list-deployments rules: - apiGroups: [ apps ] resources: [ deployments ] verbs: [ get, list ] 

उन्हें बनाने के लिए, कमांड चलाएँ:

 kubectl create -f /path/to/your/yaml/file 

उपयोगकर्ताओं को बाध्यकारी भूमिका या क्लस्टर

अब हमारे उपयोगकर्ताओं के लिए डिफ़ॉल्ट ClusterRole ( edit और view ) को इस प्रकार से ClusterRole :

• jean :
  • edit - नामस्थान में my-project-dev ;
  • view - नामस्थान में my-project-prod ;
• sarah :
  • edit - my-project-prod नामस्थान में।

रोलबाइंडिंग नामस्थानों द्वारा निर्दिष्ट होनी चाहिए, उपयोगकर्ताओं द्वारा नहीं। दूसरे शब्दों में, jean को अधिकृत करने के लिए हम दो रोलबिन्डिंग बनाएंगे। एक YAML फ़ाइल का एक उदाहरण जो jean लिए रोलबिन्डिंग को परिभाषित करता है:

 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-dev subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: edit apiGroup: rbac.authorization.k8s.io --------------------------------- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: jean namespace: my-project-prod subjects: - kind: User name: jean apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io 

हम jean को my-project-prod को view और my-project-dev संपादित करने की अनुमति देते हैं। वही sarah लिए प्राधिकरणों के साथ किया जाना चाहिए। उन्हें सक्रिय करने के लिए, कमांड चलाएँ:

 kubectl apply -f /path/to/your/yaml/file 

इस मामले में, kubectl create बजाय kubectl apply का उपयोग किया गया था। दोनों के बीच अंतर यह है कि create वस्तु बनाता है और कुछ और नहीं करता है, और apply - न केवल ऑब्जेक्ट बनाता है (यदि यह मौजूद नहीं है), लेकिन आवश्यक होने पर भी अपडेट करता है।

आइए देखें कि क्या हमारे उपयोगकर्ताओं को आवश्यक अनुमति मिली है।

• उपयोगकर्ता: sarah ( my-project-prod में edit )
  • my-project-prod
    • फली (1) को सूचीबद्ध कर सकते हैं;
    • तैनाती (2) बना सकते हैं।
  • my-project-dev
    • पॉड्स (4) को सूचीबद्ध नहीं किया जा सकता है;
    • तैनाती (5) नहीं बना सकते।

 (1) kubectl get pods -n my-project-prod No resources found. (2) kubectl run nginx --image=nginx --replicas=1 -n my-project-prod deployment.apps/nginx created (3) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 4s (4) kubectl get pods -n my-project-dev Error from server (Forbidden): pods is forbidden: User "sarah" cannot list resource "pods" in API group "" in the namespace "my-project-dev" (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev Error from server (Forbidden): deployments.apps is forbidden: User "sarah" cannot create resource "deployments" in API group "apps" in the namespace "my-project-dev" 

• उपयोगकर्ता: jean ( my-project-prod और my-project-dev में edit )
  • my-project-prod
    • फली (1) को सूचीबद्ध कर सकते हैं;
    • तैनाती को सूचीबद्ध कर सकते हैं '(2);
    • तैनाती (3) को हटा नहीं सकते।
  • मेरी परियोजना-देव:
    • फली (4) को सूचीबद्ध कर सकते हैं;
    • तैनाती (5) बना सकते हैं;
    • तैनाती को सूचीबद्ध कर सकते हैं '(6);
    • तैनाती (7) निकाल सकते हैं।

 (1) kubectl get pods -n my-project-prod NAME READY STATUS RESTARTS AGE nginx-7db9fccd9b-t14qw 1/1 Running 0 101s (2) kubectl get deploy -n my-project-prod NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 110s (3) kubectl delete deploy/nginx -n my-project-prod Error from server (Forbidden): deployments.extensions "nginx" is forbidden: User "jean" cannot delete resource "deployments" in API group "extensions" in the namespace "my-project-prod" (4) kubectl get pods -n my-project-dev No resources found. (5) kubectl run nginx --image=nginx --replicas=1 -n my-project-dev deployment.apps/nginx created (6) kubectl get deploy -n my-project-dev NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 1 0 13s (7) kubectl delete deploy/nginx -n my-project-dev deployment.extensions "nginx" deleted (8) kubectl get deploy -n my-project-dev No resources found. 

उपयोगकर्ता प्रबंधन और प्राधिकरण

इसलिए, हमने विभिन्न भूमिकाओं और उपयोगकर्ता प्राधिकरणों को सफलतापूर्वक निर्धारित किया है। सवाल उठता है: अब यह सब कैसे प्रबंधित करें? मुझे कैसे पता चलेगा कि किसी विशिष्ट उपयोगकर्ता के लिए अनुमतियाँ सही तरीके से सेट की गई हैं? मुझे कैसे पता चलेगा कि किसी विशिष्ट कार्य को करने का अधिकार किसके पास है? उपयोगकर्ता की अनुमति का एक सामान्य चित्र कैसे प्राप्त करें?

हमें क्लस्टर सुरक्षा सुनिश्चित करने के लिए इन सभी सवालों के जवाब चाहिए। kubectl auth can-i कमांड आपको यह पता लगाने की अनुमति देता है कि क्या कोई उपयोगकर्ता एक विशिष्ट कार्रवाई कर सकता है:

 # kubectl auth can-i $action $resource --as $subject (1) kubectl auth can-i list pods (2) kubectl auth can-i list pods --as jean 

पहला कमांड (1) उपयोगकर्ता को यह पता लगाने की अनुमति देता है कि क्या वह कुछ कार्रवाई कर सकता है। दूसरा (2) - व्यवस्थापक को उपयोगकर्ता को यह पता लगाने के लिए अनुमति देता है कि क्या वह एक निश्चित कार्रवाई कर सकता है। यह "पुनर्जन्म" केवल क्लस्टर व्यवस्थापक विशेषाधिकारों वाले उपयोगकर्ताओं के लिए अनुमत है।

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

स्थापना जाओ

गो एक ओपन सोर्स प्रोग्रामिंग भाषा है जो आपको सरल, विश्वसनीय और कुशल सॉफ्टवेयर बनाने की अनुमति देती है। यह Google द्वारा C और पास्कल की प्रेरणा के तहत रॉबर्ट ग्रिसेमर , रॉब पाइक और केन थॉम्पसन की मूल अवधारणाओं के आधार पर विकसित किया गया था।

 wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.12.5.linux-amd64.tar.gz export PATH=$PATH:/usr/local/go/bin 

क्रू स्थापना

क्रू एक ऐसा उपकरण है जो कुब्लेट प्लगइन्स के उपयोग को सरल करता है। Krew आपको प्लगइन्स ढूंढने, इंस्टॉल करने और प्रबंधित करने में मदद करता है। फ़ंक्शंस के संदर्भ में, यह apt, dnf या काढ़ा जैसे टूल से मिलता जुलता है। क्रू केवल kubectl संस्करण 1.12 और उच्चतर के साथ संगत है।

 set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH" 

rakkess

यह परियोजना आपको उन सभी अनुमतियों को देखने की अनुमति देती है जो उपयोगकर्ता को दी गई हैं। उदाहरण के लिए, यह इस सवाल का जवाब देने में मदद करता है कि jean क्या कर सकता है। सबसे पहले, आइए इसे स्थापित करें:

 kubectl krew install access-matrix 

परियोजना प्रलेखन GitHub पर भंडार में पाया जा सकता है । यहाँ उनके काम का एक उदाहरण है:

 kubectl access-matrix -n my-project-dev --as jean 

kubect-कौन-कर सकते हैं

यह परियोजना हमें यह पता लगाने की अनुमति देती है कि कौन से उपयोगकर्ता एक विशिष्ट कार्रवाई कर सकते हैं। यह प्रश्न का उत्तर देने में मदद करता है: "यह कौन कर सकता है?" स्थापना:

 go get -v github.com/aquasecurity/kubectl-who-can 

दस्तावेज GitHub रिपॉजिटरी में है । कार्य उदाहरण:

 kubectl-who-can list pods -n default No subjects found with permissions to list pods assigned through RoleBindings CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group rbac-manager rbac-manager ServiceAccount rbac-manager system:controller:attachdetach-controller attachdetach-controller ServiceAccount kube-system system:controller:clusterrole-aggregation-controller clusterrole-aggregation-controller ServiceAccount kube-system system:controller:cronjob-controller cronjob-controller ServiceAccount kube-system system:controller:daemon-set-controller daemon-set-controller ServiceAccount kube-system system:controller:deployment-controller deployment-controller ServiceAccount kube-system system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system system:controller:horizontal-pod-autoscaler horizontal-pod-autoscaler ServiceAccount kube-system system:controller:job-controller job-controller ServiceAccount kube-system system:controller:namespace-controller namespace-controller ServiceAccount kube-system system:controller:node-controller node-controller ServiceAccount kube-system system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system system:controller:pod-garbage-collector pod-garbage-collector ServiceAccount kube-system system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system system:controller:replicaset-controller replicaset-controller ServiceAccount kube-system system:controller:replication-controller replication-controller ServiceAccount kube-system system:controller:resourcequota-controller resourcequota-controller ServiceAccount kube-system system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system system:coredns coredns ServiceAccount kube-system system:kube-controller-manager system:kube-controller-manager User system:kube-scheduler system:kube-scheduler User 

RBAC-देखने

यह परियोजना RBAC नियमों का अवलोकन प्रदान करती है। यह सवालों के जवाब देने में मदद करता है: " jean और sarah क्या भूमिका है?", "सभी उपयोगकर्ता किस भूमिका से संबंधित हैं?", "पूरे समूह की क्या भूमिका है?"। स्थापित करने के लिए, कमांड चलाएँ:

 kubectl krew install rbac-lookup 

दस्तावेज GitHub रिपॉजिटरी में है । यहाँ काम का एक उदाहरण है:

 kubectl-rbac_lookup jean SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view kubectl-rbac_lookup sarah SUBJECT SCOPE ROLE sarah my-project-prod ClusterRole/edit kubectl-rbac_lookup --kind user SUBJECT SCOPE ROLE jean my-project-dev ClusterRole/edit jean my-project-prod ClusterRole/view sarah my-project-prod ClusterRole/edit system:anonymous kube-public Role/kubeadm:bootstrap-signer-clusterinfo system:kube-controller-manager kube-system Role/extension-apiserver-authentication-reader system:kube-controller-manager kube-system Role/system::leader-locking-kube-controller-manager system:kube-controller-manager cluster-wide ClusterRole/system:kube-controller-manager system:kube-proxy cluster-wide ClusterRole/system:node-proxier system:kube-scheduler kube-system Role/extension-apiserver-authentication-reader system:kube-scheduler kube-system Role/system::leader-locking-kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:kube-scheduler system:kube-scheduler cluster-wide ClusterRole/system:volume-scheduler kubectl-rbac_lookup --kind group SUBJECT SCOPE ROLE system:authenticated cluster-wide ClusterRole/system:basic-user system:authenticated cluster-wide ClusterRole/system:discovery system:authenticated cluster-wide ClusterRole/system:public-info-viewer system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:node-bootstrapper system:bootstrappers:kubeadm:default-node-token cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient system:bootstrappers:kubeadm:default-node-token kube-system Role/kube-proxy system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:kubelet-config-1.14 system:bootstrappers:kubeadm:default-node-token kube-system Role/kubeadm:nodes-kubeadm-config system:masters cluster-wide ClusterRole/cluster-admin system:nodes kube-system Role/kubeadm:kubelet-config-1.14 system:nodes kube-system Role/kubeadm:nodes-kubeadm-config system:nodes cluster-wide ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer 

RBAC प्रबंधक

जैसा कि इस परियोजना का नाम जाहिर है, वह आरबीएसी का प्रबंधक है। यह कई आवश्यक जोड़तोड़ को सरल करता है। शायद सबसे महत्वपूर्ण भूमिकाबिंदुओं का निर्माण है। हमने पहले देखा था कि उपयोगकर्ता के लिए अलग-अलग भूमिकाएँ बनाते समय, अलग-अलग रोलबिन्डिंग बनाना आवश्यक है। RBAC प्रबंधक आपको एक बार में सभी प्राधिकरण के साथ केवल एक रोलबाइंडिंग बनाने की अनुमति देकर मदद करता है। स्थापित करने के लिए, आपको GitHub पर रिपॉजिटरी से YAML फ़ाइल डाउनलोड करनी होगी:

 kubectl apply -f /path/to/rbac/manager/yaml/file 

आधिकारिक दस्तावेज GitHub रिपॉजिटरी में है । कार्य उदाहरण:

 apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: jose rbacBindings: - name: jose subjects: - kind: User name: jose roleBindings: - namespace: my-project-prod clusterRole: edit - namespace: my-project-dev clusterRole: edit 

निष्कर्ष

हमने ओपनएएसएल के साथ X.509 क्लाइंट सर्टिफिकेट का उपयोग करके कुबेरनेट्स क्लस्टर में उपयोगकर्ताओं को बनाया और उन्हें सशक्त बनाया। आसान उपयोगकर्ता निर्माण के लिए, आप GitHub पर मेरी रिपॉजिटरी में उपलब्ध स्क्रिप्ट का उपयोग कर सकते हैं (या प्रयोगात्मक kubeadm कमांड - लगभग। ट्रांसलेशन ।) । क्लस्टर प्रशासन के लिए, आप लेख में प्रस्तुत ओपन सोर्स-प्रोजेक्ट का उपयोग कर सकते हैं:

• kubectl Cort can-i : यह पता करें कि क्या उपयोगकर्ता कुछ क्रिया कर सकता है;
• rakkess : उपयोगकर्ता द्वारा किए जा सकने वाले सभी कार्यों का पता लगाएं;
• kubectl-who-can : यह निर्धारित करें कि कौन से उपयोगकर्ता कुछ क्रिया कर सकते हैं;
• आरबैक-लुकिंग : आरबीएसी का एक सामान्य अवलोकन प्राप्त करें;
• आरबीएसी मैनेजर : राइट्स बाइंडिंग के संयोजन द्वारा कॉन्फ़िगरेशन को सरल बनाएं, राइट्स असाइन करने के लिए चयनकर्ताओं के रूप में लेबल का उपयोग करके आरबीएसी में परिवर्तन को स्वचालित करें।

उपयोगकर्ता बनाना बहुत समय लेने वाले कार्य में बदल सकता है, खासकर यदि आपको एक बार में बड़ी संख्या में उपयोगकर्ताओं को सेट करने की आवश्यकता होती है (या उन्हें अक्सर बनाते हैं)। स्थिति को कम करने के लिए कॉरपोरेट LDAP को Kubernetes क्लस्टर से जोड़ सकते हैं। कुछ ओपन सोर्स प्रोजेक्ट्स ( Kismatic [ ऑब्जेक्ट परित्यक्त जैसा दिखता है] और ObjectifLibre ) Kubernetes webhooks प्रदान करते हैं जो LDAP के माध्यम से प्रत्यक्ष प्रमाणीकरण की अनुमति देते हैं। एक अन्य संभावित समाधान एक ओपनआईडी सर्वर को कॉर्पोरेट एलडीएपी के साथ बैकेंड के रूप में कॉन्फ़िगर करना है।

अनुवादक से पी.एस.

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

• " कुबेरनेट्स में सुरक्षा के एबीसी: प्रमाणीकरण, प्राधिकरण, ऑडिट ";
• " कुबेरनेट्स पर आरबीएसी को समझना ";
• " 33+ कुबेरनेट सुरक्षा उपकरण ";
• " 9 कुबेरनेट्स सुरक्षा सर्वोत्तम अभ्यास ।"