কুবারনেটসে নিরাপত্তার এবিসি: প্রমাণীকরণ, অনুমোদন, অডিটিং

শীঘ্রই বা পরে, যে কোনও সিস্টেমের ক্রিয়াকলাপে, সুরক্ষার সমস্যা দেখা দেয়: প্রমাণীকরণ, অধিকার পৃথকীকরণ, অডিটিং এবং অন্যান্য কাজগুলি প্রদান করা। ইতিমধ্যে Kubernetes জন্য নির্মিত অনেক সমাধান, যা আপনাকে খুব চাহিদাপূর্ণ পরিবেশেও মান সম্মতি অর্জন করতে দেয়... একই উপাদান বিল্ট-ইন K8s মেকানিজমের মধ্যে বাস্তবায়িত মৌলিক নিরাপত্তা দিকগুলির জন্য উত্সর্গীকৃত। প্রথমত, এটি তাদের জন্য উপযোগী হবে যারা কুবারনেটসের সাথে পরিচিত হতে শুরু করছেন - নিরাপত্তা সম্পর্কিত সমস্যাগুলি অধ্যয়নের জন্য একটি সূচনা পয়েন্ট হিসাবে।

প্রমাণীকরণ

কুবারনেটসে দুই ধরনের ব্যবহারকারী রয়েছে:

• পরিষেবা অ্যাকাউন্ট - Kubernetes API দ্বারা পরিচালিত অ্যাকাউন্টগুলি;
• ব্যবহারকারীরা - "স্বাভাবিক" ব্যবহারকারীরা বাহ্যিক, স্বাধীন পরিষেবা দ্বারা পরিচালিত৷

এই ধরনের মধ্যে প্রধান পার্থক্য হল যে Kubernetes API-তে পরিষেবা অ্যাকাউন্টগুলির জন্য বিশেষ বস্তু রয়েছে (এগুলিকে এভাবে বলা হয় - ServiceAccounts) যেগুলি একটি নামস্থানে আবদ্ধ এবং গোপনীয় টাইপের বস্তুগুলিতে ক্লাস্টারে সংরক্ষিত অনুমোদন ডেটার একটি সেট। এই ধরনের ব্যবহারকারীরা (পরিষেবা অ্যাকাউন্ট) মূলত একটি Kubernetes ক্লাস্টারে চলমান প্রক্রিয়াগুলির Kubernetes API-এর অ্যাক্সেস অধিকারগুলি পরিচালনা করার উদ্দেশ্যে।

অন্যদিকে, সাধারণ ব্যবহারকারীদের Kubernetes API-তে এন্ট্রি নেই: তাদের অবশ্যই বাহ্যিক প্রক্রিয়া দ্বারা পরিচালিত হতে হবে। এগুলি ক্লাস্টারের বাইরে বসবাসকারী ব্যক্তি বা প্রক্রিয়াগুলির জন্য উদ্দিষ্ট৷

প্রতিটি API অনুরোধ একটি পরিষেবা অ্যাকাউন্ট বা একটি ব্যবহারকারীর সাথে সংযুক্ত থাকে, অথবা বেনামী হিসাবে বিবেচিত হয়৷

ব্যবহারকারীর প্রমাণীকরণ ডেটা অন্তর্ভুক্ত:

• ব্যবহারকারীর নাম — ব্যবহারকারীর নাম (কেস সংবেদনশীল!);
• ইউআইডি - একটি মেশিন-পাঠযোগ্য ব্যবহারকারী শনাক্তকরণ স্ট্রিং যা "একটি ব্যবহারকারীর নামের চেয়ে আরও সামঞ্জস্যপূর্ণ এবং অনন্য";
• গ্রুপ — ব্যবহারকারীর অন্তর্গত গ্রুপগুলির তালিকা;
• অতিরিক্ত - অতিরিক্ত ক্ষেত্র যা অনুমোদন প্রক্রিয়া দ্বারা ব্যবহার করা যেতে পারে।

কুবারনেটস প্রচুর সংখ্যক প্রমাণীকরণ প্রক্রিয়া ব্যবহার করতে পারে: 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 কীগুলি ব্যবহার করে একটি শংসাপত্রের অনুরোধ প্রক্রিয়াকরণ, একটি ব্যবহারকারীর শংসাপত্র প্রাপ্ত করা (একটি শংসাপত্র পাওয়ার জন্য, আপনাকে একটি অ্যাকাউন্ট ব্যবহার করতে হবে যার অ্যাক্সেস আছে 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.

গভীরে খনন

যারা বর্ণিত বিষয়গুলি ঘনিষ্ঠভাবে দেখতে চান তাদের জন্য:

• পৃথক নিবন্ধ অফিসিয়াল কুবারনেটস ডকুমেন্টেশনে শংসাপত্রের সাথে কাজ করার বিষয়ে;
• Bitnami থেকে ভাল নিবন্ধ, যেখানে শংসাপত্রের বিষয়টি ব্যবহারিক দৃষ্টিকোণ থেকে স্পর্শ করা হয়।
• সাধারণ ডকুমেন্টেশন Kubernetes-এ প্রমাণীকরণের জন্য।

অনুমোদন

একটি অনুমোদিত অ্যাকাউন্ট, ডিফল্টরূপে, ক্লাস্টারে কাজ করার অধিকার নেই৷ অনুমতি প্রদানের জন্য, Kubernetes একটি অনুমোদন প্রক্রিয়া প্রয়োগ করে।

সংস্করণ 1.6 এর আগে, কুবারনেটস একটি অনুমোদনের ধরন ব্যবহার করত এব্যাক (অ্যাট্রিবিউট-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ)। এ সম্পর্কে বিস্তারিত পাওয়া যাবে অফিসিয়াল ডকুমেন্টেশন. এই পদ্ধতিটি বর্তমানে উত্তরাধিকার হিসাবে বিবেচিত, তবে আপনি এখনও এটিকে অন্যান্য অনুমোদনের প্রকারের মতো একই সময়ে ব্যবহার করতে পারেন।

একটি ক্লাস্টারে অ্যাক্সেস অধিকার আলাদা করার প্রকৃত (এবং আরও নমনীয়) উপায় বলা হয় আরবিএসি (ভূমিকা ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ) এটি সংস্করণ থেকে স্থিতিশীল ঘোষণা করা হয়েছে কুবারনেটস 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 - ক্লাস্টারের মধ্যে, ক্লাস্টার-নির্দিষ্ট বস্তু যেমন নোড, নন-রিসোর্স ইউআরএল সহ (অর্থাৎ, কুবারনেটস সংস্থানগুলির সাথে সম্পর্কিত নয় - উদাহরণস্বরূপ, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - বাঁধাই জন্য ব্যবহৃত Role и ClusterRole একটি ব্যবহারকারী, ব্যবহারকারী গোষ্ঠী বা পরিষেবা অ্যাকাউন্টে।

ভূমিকা এবং ভূমিকা বাইন্ডিং সত্তাগুলি নামস্থান আবদ্ধ, যেমন একই নামস্থানের মধ্যে হতে হবে। যাইহোক, একটি RoleBinding একটি 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

ইভেন্ট অডিট

পরিকল্পিতভাবে, কুবারনেটসের স্থাপত্যকে নিম্নরূপ উপস্থাপন করা যেতে পারে:

অনুরোধ প্রক্রিয়াকরণের জন্য দায়ী কুবারনেটসের মূল উপাদান হল − api-সার্ভার. ক্লাস্টারে সমস্ত ক্রিয়াকলাপ এটির মধ্য দিয়ে যায়। আপনি নিবন্ধে এই অভ্যন্তরীণ প্রক্রিয়া সম্পর্কে আরও পড়তে পারেন "আপনি যখন kubectl রান চালান তখন কুবারনেটসে কী ঘটে?».

সিস্টেম অডিটিং হল 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

তবে আমরা তাদের সম্পর্কে আরও বিশদে থাকব না - আপনি এর মধ্যে সমস্ত বিবরণ খুঁজে পেতে পারেন কুবে-এপিসার্ভার ডকুমেন্টেশন.

ইতিমধ্যে উল্লিখিত হিসাবে, সমস্ত পরামিতিগুলি এপিআই-সার্ভার কনফিগারেশনের সাথে ম্যানিফেস্টে সেট করা আছে (ডিফল্টরূপে /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 kube-masters-এ যেখানে অডিট নীতি পরিবর্তন করা হয়েছে:

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);
• ক্রিয়াপদ (ক্রিয়া: 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" এ দেওয়া হয়েছে, সম্ভবত তাদের মধ্যে আপনি আপনার প্রাসঙ্গিক সমস্যাগুলির প্রয়োজনীয় বিবরণ পাবেন।

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

• «33+ কুবারনেটস নিরাপত্তা সরঞ্জাম";
• «নিরাপত্তা পেশাদারদের জন্য Kubernetes নেটওয়ার্ক নীতির একটি ভূমিকা";
• «কুবারনেটসে RBAC বোঝা";
• «9 Kubernetes নিরাপত্তা সর্বোত্তম অভ্যাস";
• «কুবারনেটসে হ্যাক হওয়ার 11টি উপায় (না)».

উত্স: www.habr.com