په Kubernetes کې د امنیت ABC: تصدیق، واک ورکول، پلټنه

ژر یا وروسته، د هر سیسټم په عملیاتو کې، د امنیت مسله راپورته کیږي: د تصدیق تصدیق، د حقونو جلا کول، تفتیش او نورې دندې. دمخه د Kubernetes لپاره جوړ شوی ډیری حلونه، کوم چې تاسو ته اجازه درکوي د معیارونو سره موافقت ترلاسه کړئ حتی په خورا سخت چاپیریال کې ... ورته مواد د K8s جوړ شوي میکانیزمونو کې پلي شوي امنیت لومړني اړخونو ته وقف شوي. تر ټولو لومړی، دا به د هغو کسانو لپاره ګټور وي چې د کوبرنیټس سره آشنا پیل کوي - د امنیت پورې اړوند مسلو مطالعې لپاره د پیل ټکي په توګه.

تصدیق کول

په Kubernetes کې دوه ډوله کاروونکي شتون لري:

• د خدماتو حسابونه - حسابونه چې د Kubernetes API لخوا اداره کیږي؛
• کارنان - "عادي" کارونکي چې د بهرني، خپلواک خدماتو لخوا اداره کیږي.

د دې ډولونو تر مینځ اصلي توپیر دا دی چې د خدماتو حسابونو لپاره په کوبرنیټس API کې ځانګړي توکي شتون لري (دوی ورته ویل کیږي - ServiceAccounts)، کوم چې د نوم ځای سره تړل شوي او د اختیار کولو ډیټا سیټ په کلستر کې د راز ډول ډول شیانو کې زیرمه شوي. دا ډول کاروونکي (خدمت حسابونه) ​​په اصل کې د Kubernetes کلستر کې د پروسو د Kubernetes API ته د لاسرسي حقونه اداره کول دي.

عادي کارونکي په کوبرنیټس API کې ننوتل نه لري: دوی باید د بهرني میکانیزمونو لخوا اداره شي. دوی د هغو خلکو یا پروسو لپاره دي چې د کلستر څخه بهر ژوند کوي.

د هر API غوښتنه یا د خدماتو حساب، یو کارن سره تړاو لري، یا نامعلوم ګڼل کیږي.

د کارونکي تصدیق معلوماتو کې شامل دي:

• نوم - کارن نوم (د قضیې حساس!)؛
• UID - د ماشین د لوستلو وړ کارونکي پیژندنې تار چې "د کارن نوم څخه ډیر ثابت او ځانګړی" دی؛
• ډلو - د هغو ګروپونو لیست چې کاروونکي ورسره تړاو لري؛
• اضافي - اضافي ساحې چې د واک ورکولو میکانیزم لخوا کارول کیدی شي.

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"

• د کوبرنیټس کلستر CA کیلي په کارولو سره د سند غوښتنې پروسس کول ، د کارونکي سند ترلاسه کول (د سند ترلاسه کولو لپاره ، تاسو باید داسې حساب وکاروئ چې د کوبرنیټس کلسټر 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

  • یا څنګه نهوړاندیز شوی اختیار - تاسو اړتیا نلرئ د روټ سند مشخص کړئ (بیا کیوبکټل به د کلستر د API-سرور درستیت ونه ګوري):

    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, i.e. ترلاسه کول certificate-authority-data او داسې نور.

د kubeadm سره سندونه

د خوشې کیدو سره کوبرنیټ 1.15 د سندونو سره کار کول خورا اسانه شوي دي د دې ملاتړ الفا نسخه څخه مننه kubeadm افادیت. د مثال په توګه، دا هغه څه دي چې د کاروونکي کیلي سره د ترتیب فایل رامینځته کول ممکن اوس داسې ښکاري:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: اړین دی ادرس اعلان کړئ د api-server config کې موندل کیدی شي، کوم چې په ډیفالټ کې موقعیت لري /etc/kubernetes/manifests/kube-apiserver.yaml.

پایله لرونکی تشکیل به stdout ته محصول شي. دا باید خوندي شي ~/.kube/config د کارونکي حساب یا د چاپیریال متغیر کې مشخص شوي فایل ته KUBECONFIG.

ژور وخورئ

د هغو کسانو لپاره چې غواړي په تفصیل سره تشریح شوي مسلې پوه شي:

• جلا مقاله په رسمي Kubernetes اسنادو کې د سندونو سره کار کول؛
• د Bitnami څخه ښه مقالهپه کوم کې چې د سندونو مسله له عملي لید څخه تماس نیول کیږي.
• عمومي اسناد په Kubernetes کې د تصدیق په اړه.

واکمنۍ

ډیفالټ مجاز حساب په کلستر کې د کار کولو حق نلري. د اجازې ورکولو لپاره، Kubernetes د واک ورکولو میکانیزم پلي کوي.

د 1.6 نسخه دمخه، کوبرنیټس د اختیار ډول کارولی و ABAC (د خاصیت پر بنسټ د لاسرسي کنټرول). په اړه یې جزیات په کې موندلی شئ رسمي اسناد. دا طریقه اوس مهال میراث ګڼل کیږي، مګر تاسو کولی شئ دا د نورو تصدیق ډولونو سره وکاروئ.

کلستر ته د لاسرسي حقونو ویشلو اوسنۍ (او ډیر انعطاف وړ) لاره ویل کیږي RBAC (د رول پر بنسټ د لاسرسي کنټرول). دا د نسخې راهیسې مستحکم اعلان شوی کوبرنیټ 1.8. RBAC د حقونو ماډل پلي کوي په کوم کې چې هر هغه څه چې په ښکاره ډول اجازه نلري منع دي.
د RBAC فعالولو لپاره، تاسو اړتیا لرئ د پیرامیټر سره Kubernetes api-server پیل کړئ --authorization-mode=RBAC. پیرامیټرې په منشور کې د api-سرور ترتیب سره تنظیم شوي ، کوم چې په ډیفالټ ډول د لارې په اوږدو کې موقعیت لري /etc/kubernetes/manifests/kube-apiserver.yamlپه برخه کې command. په هرصورت، RBAC لا دمخه د ډیفالټ لخوا فعال شوی، نو ډیری احتمال تاسو باید د هغې په اړه اندیښنه ونلرئ: تاسو کولی شئ دا د ارزښت لخوا تایید کړئ authorization-mode (په مخکې ذکر شوي kube-apiserver.yaml). په هرصورت، د دې معنی په منځ کې ممکن د واک نور ډولونه وي (node, webhook, always allow)، مګر موږ به د دوی پام د موادو له ساحې بهر پریږدو.

په هرصورت، موږ دمخه خپور کړی دی مقاله د RBAC سره د کار کولو اصولو او ځانګړتیاو په کافي توضیحي توضیحاتو سره ، نو نور به زه خپل ځان د اساساتو او مثالونو لنډ لیست پورې محدود کړم.

لاندې API ادارې د RBAC له لارې په Kubernetes کې د لاسرسي کنټرول لپاره کارول کیږي:

• Role и ClusterRole - هغه رولونه چې د لاسرسي حقونه تشریح کوي:
• Role تاسو ته اجازه درکوي په نوم ځای کې حقونه بیان کړئ؛
• ClusterRole - د کلستر دننه، په شمول د کلستر ځانګړي شیانو لکه نوډونه، غیر منابع urls (د مثال په توګه، د 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 جوړښت په لاندې ډول استازیتوب کیدی شي:

د Kubernetes کلیدي برخه ده چې د غوښتنو پروسس کولو مسولیت لري api-سرور. په کلستر کې ټول عملیات له هغې څخه تیریږي. تاسو کولی شئ پدې مقاله کې د دې داخلي میکانیزمونو په اړه نور ولولئ "په Kubernetes کې څه پیښیږي کله چې تاسو د کیوبیکیل چلول کوئ؟".

د سیسټم پلټنه په Kubernetes کې یوه زړه پورې ځانګړتیا ده، کوم چې د ډیفالټ لخوا غیر فعال دی. دا تاسو ته اجازه درکوي چې ټول زنګونه Kubernetes API ته ننوځي. لکه څنګه چې تاسو اټکل کولی شئ، د کلستر حالت څارنه او بدلولو پورې اړوند ټولې کړنې د دې API له لارې ترسره کیږي. د دې وړتیاو ښه توضیحات (د معمول په څیر) کې موندل کیدی شي رسمي اسناد K8s. بیا به هڅه وکړم چې موضوع په ساده ژبه وړاندې کړم.

او همداسې، د پلټنې فعالولو لپاره، موږ اړتیا لرو چې په api-server کې کانټینر ته درې اړین پیرامیټونه انتقال کړو ، کوم چې په لاندې توضیحاتو کې تشریح شوي:

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

د دې دریو اړینو پیرامیټونو سربیره، د پلټنې پورې اړوند ډیری اضافي ترتیبات شتون لري: د لاګ گردش څخه د ویب هک توضیحاتو پورې. د log گردش پیرامیټرو بیلګه:

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

مګر موږ به په دوی باندې ډیر تفصیل ونه ګورو - تاسو کولی شئ ټول توضیحات په کې ومومئ kube-apiserver اسناد.

لکه څنګه چې مخکې یادونه وشوه، ټول پیرامیټونه د API-سرور ترتیب سره په مینی فیسټ کې تنظیم شوي (د ډیفالټ په واسطه /etc/kubernetes/manifests/kube-apiserver.yamlپه برخه کې command. راځئ چې 3 اړین پیرامیټرو ته راستون شو او تحلیل یې کړو:

1. audit-policy-file - د YAML فایل ته لاره چې د پلټنې پالیسي بیانوي. موږ به وروسته د هغې مینځپانګې ته راستون شو ، مګر د اوس لپاره زه به یادونه وکړم چې فایل باید د api-server پروسې لخوا د لوستلو وړ وي. له همدې امله ، دا اړینه ده چې دا په کانټینر کې دننه کړئ ، د دې لپاره چې تاسو کولی شئ لاندې کوډ د ترتیب مناسب برخو ته اضافه کړئ:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - د لاګ فایل ته لاره. لاره باید د api-server پروسې ته هم د لاسرسي وړ وي، نو موږ په ورته ډول د هغې نصب کول تشریح کوو:

     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.

د پالیسۍ په فایل کې، موږ کولی شو څو برخې تشریح کړو چې د مختلف ننوتلو کچو سره. د پالیسي په تفصیل کې موندل شوي لومړی مطابقت قاعده به پلي شي.

کوبیلټ ډیمون د api-server ترتیب سره په مینی فیسټ کې بدلونونه څاري او که چیرې کوم وموندل شي نو کانټینر د api-server سره بیا پیل کوي. مګر یو مهم تفصیل شتون لري: د پالیسۍ فایل کې بدلونونه به د هغې لخوا له پامه غورځول شي. د پالیسۍ فایل کې د بدلونونو کولو وروسته، تاسو به اړتیا ولرئ چې د API-سرور په لاسي ډول بیا پیل کړئ. ځکه چې د api-سرور په توګه پیل شوی جامد پوډ، ټیم 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 کلسترونو کې د لومړني امنیتي میکانیزمونو عمومي کتنه وړاندې کوي، کوم چې تاسو ته اجازه درکوي شخصي کاروونکي حسابونه جوړ کړئ، د دوی حقونه جلا کړئ، او د دوی کړنې ثبت کړئ. زه امید لرم چې دا به د هغو کسانو لپاره ګټور وي څوک چې په تیوري یا عمل کې د ورته مسلو سره مخ دي. زه دا هم وړاندیز کوم چې تاسو په Kubernetes کې د امنیت په اړه د نورو موادو لیست ولولئ، کوم چې په "PS" کې ورکړل شوی - شاید تاسو به د هغو ستونزو په اړه اړین توضیحات ومومئ چې ستاسو سره تړاو لري.

PS

زموږ په بلاګ کې هم ولولئ:

• «33+ د Kubernetes امنیتي وسیلې»
• «د امنیتي مسلکیانو لپاره د کوبرنیټس شبکې پالیسیو پیژندنه»
• «په Kubernetes کې د RBAC پوهیدل»
• «د Kubernetes امنیت لپاره 9 غوره کړنې»
• «د کبرنیټس هیک قرباني کیدو لپاره (نه) 11 لارې".

سرچینه: www.habr.com