कुबेरनेटमा सुरक्षाको एबीसी: प्रमाणीकरण, प्राधिकरण, अडिटिङ

ढिलो वा पछि, कुनै पनि प्रणालीको सञ्चालनमा, सुरक्षाको मुद्दा उठ्छ: प्रमाणीकरण, अधिकारको विभाजन, लेखा परीक्षण र अन्य कार्यहरू सुनिश्चित गर्ने। Kubernetes को लागि पहिले नै सिर्जना गरियो धेरै समाधान, जसले तपाईंलाई धेरै माग वातावरणमा पनि मापदण्डहरूको अनुपालन प्राप्त गर्न अनुमति दिन्छ... समान सामग्री K8s को निर्मित संयन्त्र भित्र लागू गरिएको सुरक्षाको आधारभूत पक्षहरूमा समर्पित छ। सबैभन्दा पहिले, यो सुरक्षा सम्बन्धी मुद्दाहरू अध्ययन गर्नको लागि एक सुरूवात बिन्दुको रूपमा - Kubernetes सँग परिचित हुन सुरु गर्नेहरूका लागि उपयोगी हुनेछ।

प्रमाणीकरण

Kubernetes मा दुई प्रकारका प्रयोगकर्ताहरू छन्:

• सेवा खाताहरू - Kubernetes API द्वारा व्यवस्थित खाताहरू;
• प्रयोगकर्ता - बाह्य, स्वतन्त्र सेवाहरू द्वारा व्यवस्थित "सामान्य" प्रयोगकर्ताहरू।

यी प्रकारहरू बीचको मुख्य भिन्नता यो हो कि सेवा खाताहरूका लागि Kubernetes 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 कुञ्जीहरू प्रयोग गरेर प्रमाणपत्र अनुरोध प्रशोधन गर्दै, प्रयोगकर्ता प्रमाणपत्र प्राप्त गर्दै (प्रमाणपत्र प्राप्त गर्न, तपाईंले 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 ले क्लस्टरको एपीआई-सर्भरको शुद्धता जाँच गर्दैन):

    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 कागजात मा प्रमाणपत्र संग काम मा;
• Bitnami बाट राम्रो लेख, जसमा प्रमाणपत्रको मुद्दालाई व्यावहारिक परिप्रेक्ष्यमा छोइन्छ।
• सामान्य दस्तावेज Kubernetes मा प्रमाणीकरण मा।

प्राधिकरण

पूर्वनिर्धारित अधिकृत खातासँग क्लस्टरमा सञ्चालन गर्ने अधिकार छैन। अनुमतिहरू प्रदान गर्न, Kubernetes ले प्राधिकरण संयन्त्र लागू गर्दछ।

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

क्लस्टरमा पहुँच अधिकारहरू विभाजन गर्ने हालको (र थप लचिलो) तरिका भनिन्छ RBAC (भूमिका आधारित पहुँच नियन्त्रण)। यो संस्करण देखि स्थिर घोषित गरिएको छ कुबर्नेट १.१1.8। RBAC ले अधिकारको मोडेल लागू गर्दछ जसमा स्पष्ट रूपमा अनुमति नभएको सबै कुरालाई निषेध गरिएको छ।
RBAC सक्षम गर्न, तपाईंले प्यारामिटरको साथ Kubernetes api-सर्भर सुरु गर्न आवश्यक छ --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हरू (अर्थात Kubernetes स्रोतहरूसँग सम्बन्धित छैन - उदाहरणका लागि, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - बन्धन को लागी प्रयोग गरिन्छ Role и ClusterRole प्रयोगकर्ता, प्रयोगकर्ता समूह वा सेवा खातामा।

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

भूमिकाहरूले नियमहरूको सेट प्रयोग गरेर अधिकारहरू वर्णन गर्दछ:

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

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

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

घटना लेखापरीक्षण

योजनाबद्ध रूपमा, Kubernetes वास्तुकला निम्न रूपमा प्रतिनिधित्व गर्न सकिन्छ:

अनुरोधहरू प्रशोधन गर्नको लागि जिम्मेवार कुबर्नेट्स कम्पोनेन्ट हो api-सर्भर। क्लस्टरमा भएका सबै कार्यहरू यसबाटै जान्छन्। तपाईले लेखमा यी आन्तरिक संयन्त्रहरूको बारेमा थप पढ्न सक्नुहुन्छ "कुबेरनेटमा के हुन्छ जब तपाइँ कुबेक्टल रन चलाउनुहुन्छ?"।

प्रणाली अडिटिङ Kubernetes मा एक रोचक सुविधा हो, जुन पूर्वनिर्धारित रूपमा असक्षम गरिएको छ। यसले तपाईंलाई Kubernetes API मा सबै कलहरू लग गर्न अनुमति दिन्छ। तपाईले अनुमान गर्न सक्नुहुन्छ, क्लस्टरको स्थिति निगरानी र परिवर्तनसँग सम्बन्धित सबै कार्यहरू यस 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

तर हामी तिनीहरूलाई थप विवरणमा बस्ने छैनौं - तपाईले सबै विवरणहरू पाउन सक्नुहुन्छ 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).

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

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" मा दिइएको Kubernetes मा सुरक्षा को बिषय मा अन्य सामाग्री को सूची पढ्न पनि सिफारिस गर्दछु - सायद ती मध्ये तपाइँसँग सान्दर्भिक समस्याहरु मा आवश्यक विवरण पाउनुहुनेछ।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «33+ Kubernetes सुरक्षा उपकरणहरू»;
• «सुरक्षा पेशेवरहरूको लागि Kubernetes नेटवर्क नीतिहरूको परिचय»;
• «Kubernetes मा RBAC बुझ्दै»;
• «9 Kubernetes सुरक्षा उत्तम अभ्यासहरू»;
• «11 तरिकाहरू (होइन) कुबेरनेट ह्याकको शिकार बन्ने"।

स्रोत: www.habr.com