Անվտանգության ABC-ն Kubernetes-ում. վավերացում, լիազորում, աուդիտ

Վաղ թե ուշ ցանկացած համակարգի գործարկման ժամանակ առաջանում է անվտանգության խնդիր՝ վավերացման ապահովում, իրավունքների տարանջատում, աուդիտ և այլ առաջադրանքներ։ Արդեն ստեղծված է Kubernetes-ի համար բազմաթիվ լուծումներ, որոնք թույլ են տալիս հասնել ստանդարտների համապատասխանության նույնիսկ շատ պահանջկոտ միջավայրերում... Նույն նյութը նվիրված է անվտանգության հիմնական ասպեկտներին, որոնք իրականացվում են K8-ների ներկառուցված մեխանիզմներում: Առաջին հերթին, դա օգտակար կլինի նրանց համար, ովքեր սկսում են ծանոթանալ Kubernetes-ի հետ՝ որպես անվտանգության հետ կապված խնդիրների ուսումնասիրման ելակետ:

Նույնականացմանը

Kubernetes-ում կան երկու տեսակի օգտատերեր.

• Ծառայությունների հաշիվներ — Kubernetes API-ի կողմից կառավարվող հաշիվներ.
• Users — «սովորական» օգտվողներ, որոնք կառավարվում են արտաքին, անկախ ծառայությունների կողմից:

Այս տեսակների հիմնական տարբերությունն այն է, որ սպասարկման հաշիվների համար Kubernetes API-ում կան հատուկ օբյեկտներ (դրանք կոչվում են այսպես. ServiceAccounts), որոնք կապված են անունների տարածության և թույլտվության տվյալների մի շարքի հետ, որոնք պահվում են կլաստերում գաղտնի տիպի օբյեկտներում: Նման օգտվողները (Ծառայության հաշիվները) հիմնականում նախատեսված են Kubernetes կլաստերում աշխատող գործընթացների Kubernetes API-ի մուտքի իրավունքները կառավարելու համար:

Սովորական օգտատերերը Kubernetes API-ում գրառումներ չունեն. դրանք պետք է կառավարվեն արտաքին մեխանիզմներով: Դրանք նախատեսված են կլաստերից դուրս ապրող մարդկանց կամ գործընթացների համար։

Յուրաքանչյուր API հարցում կապված է կամ ծառայության հաշվի, օգտագործողի հետ կամ համարվում է անանուն:

Օգտագործողի նույնականացման տվյալները ներառում են.

• Օգտագործողի անունը — օգտվողի անուն (գործի զգայուն!);
• uID - մեքենայական ընթեռնելի օգտվողի նույնականացման տող, որը «ավելի հետևողական և եզակի է, քան օգտվողի անունը»;
• Խմբեր - խմբերի ցանկ, որոնց պատկանում է օգտվողը.
• հավելյալ — լրացուցիչ դաշտեր, որոնք կարող են օգտագործվել լիազորման մեխանիզմի կողմից:

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 ստեղները, ստանալ օգտատիրոջ վկայական (վկայական ստանալու համար դուք պետք է օգտագործեք հաշիվ, որն ունի մուտք դեպի 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-ը չի ստուգի կլաստերի 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

Դա անելու համար դուք կարող եք կոդավորել դրանցում նշված ֆայլերը՝ օգտագործելով base64-ը և գրանցել դրանք կոնֆիգուրում՝ ավելացնելով ստեղների անվան վերջածանցը։ -data, այսինքն. ստանալով 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-ը կիրառում է թույլտվության մեխանիզմ:

Մինչև 1.6 տարբերակը, Kubernetes-ը օգտագործում էր թույլտվության տեսակ, որը կոչվում էր 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 միավորներն օգտագործվում են Kubernetes-ում RBAC-ի միջոցով մուտքը վերահսկելու համար.

• Role и ClusterRole — դերեր, որոնք ծառայում են մուտքի իրավունքները նկարագրելու համար.
• Role թույլ է տալիս նկարագրել իրավունքները անունների տարածքում.
• ClusterRole - կլաստերի ներսում, ներառյալ կլաստերի հատուկ օբյեկտները, ինչպիսիք են հանգույցները, ոչ ռեսուրսների url-ները (այսինքն՝ կապված չեն Kubernetes-ի ռեսուրսների հետ, օրինակ. /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - օգտագործվում է կապելու համար Role и ClusterRole օգտատիրոջ, օգտատերերի խմբի կամ ծառայության հաշվին:

Role և RoleBinding սուբյեկտները սահմանափակված են անվանատարածքով, այսինքն. պետք է լինի նույն անվանատարածքում: Այնուամենայնիվ, 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

Միջոցառումների աուդիտ

Սխեմատիկորեն Kubernetes ճարտարապետությունը կարող է ներկայացվել հետևյալ կերպ.

Հարցումների մշակման համար պատասխանատու Kubernetes-ի հիմնական բաղադրիչն է api-սերվեր. Կլաստերի բոլոր գործողությունները անցնում են դրա միջով: Այս ներքին մեխանիզմների մասին ավելին կարող եք կարդալ հոդվածում «Ի՞նչ է տեղի ունենում Kubernetes-ում, երբ աշխատում եք kubectl run-ում:.

Համակարգի աուդիտը հետաքրքիր հատկություն է 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

Բացի այս երեք անհրաժեշտ պարամետրերից, կան բազմաթիվ լրացուցիչ կարգավորումներ՝ կապված աուդիտի հետ՝ մատյանների ռոտացիայից մինչև վեբ-կապիկի նկարագրություններ: Գրանցամատյանի ռոտացիայի պարամետրերի օրինակ.

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

Բայց մենք ավելի մանրամասն չենք խոսի դրանց մասին, դուք կարող եք գտնել բոլոր մանրամասները kube-apiserver փաստաթղթեր.

Ինչպես արդեն նշվեց, բոլոր պարամետրերը դրված են մանիֆեստում api-server-ի կազմաձևով (լռելյայն /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 — տեղեկամատյան հարցումների մետատվյալներ՝ օգտատեր, հարցման ժամանակ, թիրախային ռեսուրս (pod, namespace և այլն), գործողության տեսակ (բայ) և այլն;
• Request — գրանցամատյան մետատվյալներ և հարցումների մարմին;
• RequestResponse — գրանցամատյանի մետատվյալներ, հարցման մարմին և պատասխան մարմին:

Վերջին երկու մակարդակները (Request и RequestResponse) մի գրանցեք հարցումներ, որոնք մուտք չեն գործել ռեսուրսներ (մուտքեր, այսպես կոչված, ոչ ռեսուրսային url-ներին):

Նաև բոլոր հարցումներն անցնում են մի քանի փուլ:

• RequestReceived - այն փուլը, երբ հարցումը ստացվել է պրոցեսորի կողմից և դեռ չի փոխանցվել վերամշակողների շղթայի երկայնքով.
• ResponseStarted — պատասխանների վերնագրերն ուղարկվում են, բայց նախքան պատասխան մարմնի ուղարկումը: Ստեղծվել է երկարատև հարցումների համար (օրինակ, watch);
• ResponseComplete — պատասխան մարմինն ուղարկվել է, այլ տեղեկություն չի ուղարկվի.
• Panic — իրադարձություններ են առաջանում, երբ հայտնաբերվում է աննորմալ իրավիճակ:

Բաց թողնելու ցանկացած քայլ, որը կարող եք օգտագործել omitStages.

Քաղաքականության ֆայլում մենք կարող ենք նկարագրել մի քանի բաժիններ՝ գրանցման տարբեր մակարդակներով: Կկիրառվի քաղաքականության նկարագրության մեջ հայտնաբերված առաջին համապատասխանող կանոնը:

Kubelet daemon-ը վերահսկում է մանիֆեստի փոփոխությունները api-սերվերի կազմաձևով և, եթե դրանք հայտնաբերվեն, վերագործարկում է կոնտեյները api-սերվերով: Բայց կա մի կարևոր դետալ. քաղաքականության ֆայլի փոփոխությունները անտեսվելու են դրա կողմից. Քաղաքականության ֆայլում փոփոխություններ կատարելուց հետո ձեզ հարկավոր է ձեռքով վերագործարկել api-սերվերը: Քանի որ api-սերվերը գործարկվում է որպես ստատիկ պատիճ, թիմ 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).

Ուշադրություն դարձրեք. Ռեսուրսները և ռեսուրսների խմբերը (API խմբեր, այսինքն՝ apiGroups), ինչպես նաև կլաստերում տեղադրված դրանց տարբերակները կարելի է ձեռք բերել՝ օգտագործելով հրամանները.

kubectl api-resources
kubectl api-versions

Հետևյալ աուդիտի քաղաքականությունը տրամադրվում է որպես լավագույն փորձի ցուցադրում Alibaba Cloud-ի փաստաթղթեր:

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-ում.

Աուդիտի իրադարձություններին արագ արձագանքելու համար հնարավոր է նկարագրել webhook-ը. Այս հարցը լուսաբանված է պաշտոնական փաստաթղթեր, ես այն կթողնեմ այս հոդվածի շրջանակներից դուրս։

Արդյունքները

Հոդվածում ներկայացված են Kubernetes կլաստերներում անվտանգության հիմնական մեխանիզմների ակնարկ, որոնք թույլ են տալիս ստեղծել անհատականացված օգտատերերի հաշիվներ, առանձնացնել նրանց իրավունքները և գրանցել նրանց գործողությունները: Հուսով եմ, որ այն օգտակար կլինի նրանց, ովքեր տեսականորեն կամ գործնականում բախվում են նման խնդիրների։ Ես նաև խորհուրդ եմ տալիս կարդալ Kubernetes-ում անվտանգության թեմայի վերաբերյալ այլ նյութերի ցանկը, որը տրված է «PS»-ում, միգուցե դրանց մեջ դուք կգտնեք անհրաժեշտ մանրամասներ ձեզ համար առնչվող խնդիրների վերաբերյալ:

PS

Կարդացեք նաև մեր բլոգում.

• «33+ Kubernetes անվտանգության գործիքներ";
• «Անվտանգության մասնագետների համար Kubernetes ցանցային քաղաքականության ներածություն";
• «Հասկանալով RBAC-ը Kubernetes-ում";
• «9 Kubernetes անվտանգության լավագույն փորձ";
• «Kubernetes-ի հաքի զոհ (չ) դառնալու 11 եղանակ.

Source: www.habr.com