ABC öryggis í Kubernetes: Auðkenning, heimild, endurskoðun

Fyrr eða síðar, í rekstri hvers kerfis, kemur öryggisvandamálið upp: að tryggja auðkenningu, aðskilnað réttinda, endurskoðun og önnur verkefni. Þegar búið til fyrir Kubernetes margar lausnir, sem gerir þér kleift að ná samræmi við staðla jafnvel í mjög krefjandi umhverfi... Sama efni er varið til grunnþátta öryggis sem er útfært innan innbyggðu kerfisins í K8s. Í fyrsta lagi mun það nýtast þeim sem eru að byrja að kynnast Kubernetes - sem upphafspunktur til að kynna sér öryggistengd málefni.

Auðkenning

Það eru tvær tegundir af notendum í Kubernetes:

• Þjónustureikningar — reikningum stjórnað af Kubernetes API;
• Notendur — „venjulegir“ notendur sem stjórnað er af utanaðkomandi, óháðri þjónustu.

Helsti munurinn á þessum gerðum er að fyrir þjónustureikninga eru sérstakir hlutir í Kubernetes API (þeir eru kallaðir það - ServiceAccounts), sem eru bundin við nafnrými og safn heimildagagna sem eru geymd í þyrpingunni í hlutum af gerðinni Secrets. Slíkum notendum (þjónustureikningum) er fyrst og fremst ætlað að stjórna aðgangsréttindum að Kubernetes API af ferlum sem keyra í Kubernetes klasanum.

Venjulegir notendur hafa ekki færslur í Kubernetes API: þeim verður að stjórna af utanaðkomandi aðferðum. Þau eru ætluð fólki eða ferlum sem búa utan klasans.

Hver API beiðni er tengd við annað hvort þjónustureikning, notanda eða er talin nafnlaus.

Notendavottunargögn innihalda:

• Notandanafn - notendanafn (hástafaviðkvæmur!);
• UID - véllesanlegur notendaauðkenningarstrengur sem er „samkvæmari og einstakari en notendanafnið“;
• hópar — listi yfir hópa sem notandinn tilheyrir;
• Extra — viðbótarreitir sem leyfisveitingarkerfið getur notað.

Kubernetes getur notað fjölda auðkenningaraðferða: X509 vottorð, burðartákn, auðkenningarumboð, HTTP Basic Auth. Með því að nota þessar aðferðir geturðu innleitt fjölda heimildakerfa: allt frá kyrrstæðri skrá með lykilorðum til OpenID OAuth2.

Þar að auki er hægt að nota mörg leyfiskerfi samtímis. Sjálfgefið er að klasinn notar:

• þjónustureikningamerki - fyrir þjónustureikninga;
• X509 - fyrir notendur.

Spurningin um stjórnun ServiceAccounts er utan viðfangsefnis þessarar greinar, en fyrir þá sem vilja kynna sér þetta mál nánar mæli ég með því að byrja með opinberar skjalasíður. Við munum skoða nánar hvernig X509 vottorð virka.

Vottorð fyrir notendur (X.509)

Klassískt vinnulag með skírteini felur í sér:

• lykil kynslóð:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• búa til vottorðsbeiðni:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• vinna úr vottorðsbeiðni með því að nota Kubernetes klasa CA lykla, fá notendaskírteini (til að fá vottorð verður þú að nota reikning sem hefur aðgang að Kubernetes klasa CA lyklinum, sem er sjálfgefið staðsettur í /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

• búa til stillingarskrá:
  • klasalýsing (tilgreindu heimilisfang og staðsetningu CA vottorðsskrárinnar fyrir tiltekna klasauppsetningu):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • eða hvernig ekkiráðlagður valkostur - þú þarft ekki að tilgreina rótarvottorðið (þá mun kubectl ekki athuga réttmæti api-þjóns klasans):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • að bæta notanda við stillingarskrána:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • bæta við samhengi:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • sjálfgefið samhengisúthlutun:

    kubectl config use-context mynewuser-context

Eftir ofangreindar meðhöndlun, í skránni .kube/config stilling eins og þessi verður búin til:

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

Til að auðvelda að flytja stillingarnar á milli reikninga og netþjóna er gagnlegt að breyta gildum eftirfarandi lykla:

• certificate-authority
• client-certificate
• client-key

Til að gera þetta geturðu umritað skrárnar sem tilgreindar eru í þeim með því að nota base64 og skrá þær í stillinguna og bæta viðskeytinu við nafn lyklanna -data, þ.e. að hafa fengið certificate-authority-data o.fl.

Vottorð með kubeadm

Með útgáfunni Kubernetes 1.15 vinna með skírteini hefur orðið miklu auðveldara þökk sé alfa útgáfu af stuðningi þess í kubeadm gagnsemi. Til dæmis gæti það nú litið út þannig að búa til stillingarskrá með notendalyklum:

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

NB: Nauðsynlegt auglýsa heimilisfang er að finna í api-server config, sem sjálfgefið er staðsett í /etc/kubernetes/manifests/kube-apiserver.yaml.

Stillingin sem myndast verður send út í stdout. Það þarf að vista það inn ~/.kube/config notandareikningi eða í skrá sem tilgreind er í umhverfisbreytu KUBECONFIG.

Grafðu dýpra

Fyrir þá sem vilja skilja þau mál sem lýst er nánar:

• sérstök grein um að vinna með vottorð í opinberum Kubernetes skjölum;
• góð grein frá Bitnami, þar sem fjallað er um útgáfu skírteina frá hagnýtu sjónarhorni.
• almenn skjöl um auðkenningu í Kubernetes.

Innskráning

Sjálfgefinn leyfilegur reikningur hefur ekki réttindi til að starfa á klasanum. Til að veita heimildir innleiðir Kubernetes heimildarkerfi.

Fyrir útgáfu 1.6 notaði Kubernetes heimildartegund sem kallast ABAC (Eiginleikamiðuð aðgangsstýring). Upplýsingar um það má finna í opinber skjöl. Þessi aðferð er nú talin arfleifð, en þú getur samt notað hana ásamt öðrum auðkenningartegundum.

Núverandi (og sveigjanlegri) leiðin til að skipta aðgangsrétti að klasa er kölluð RBAC (Hlutverkamiðuð aðgangsstýring). Það hefur verið lýst stöðugt frá útgáfu Kubernetes 1.8. RBAC innleiðir réttindalíkan þar sem allt sem ekki er beinlínis leyfilegt er bannað.
Til að virkja RBAC, þú þarft að ræsa Kubernetes api-þjóninn með færibreytunni --authorization-mode=RBAC. Færibreyturnar eru stilltar í upplýsingaskránni með api-miðlara stillingum, sem sjálfgefið er staðsett meðfram slóðinni /etc/kubernetes/manifests/kube-apiserver.yaml, í kafla command. Hins vegar er RBAC nú þegar virkt sjálfgefið, svo líklega ættir þú ekki að hafa áhyggjur af því: þú getur staðfest þetta með gildinu authorization-mode (í áðurnefndu kube-apiserver.yaml). Við the vegur, meðal merkingar þess geta verið aðrar tegundir leyfis (node, webhook, always allow), en við munum skilja umfjöllun þeirra utan efnissviðs.

Við the vegur, við höfum þegar birt grein með nokkuð ítarlegri lýsingu á meginreglum og eiginleikum þess að vinna með RBAC, svo frekar mun ég takmarka mig við stutta upptalningu á grunnatriðum og dæmum.

Eftirfarandi API einingar eru notaðar til að stjórna aðgangi í Kubernetes í gegnum RBAC:

• Role и ClusterRole — hlutverk sem þjóna til að lýsa aðgangsrétti:
• Role gerir þér kleift að lýsa réttindum innan nafnrýmis;
• ClusterRole - innan klasans, þar með talið til hópsértækra hluta eins og hnúta, vefslóða sem ekki eru tilföng (þ.e. ekki tengd Kubernetes tilföngum - til dæmis, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - notað til að binda Role и ClusterRole til notanda, notendahóps eða þjónustureiknings.

Hlutverk og Hlutverkabindandi einingarnar takmarkast af nafnrými, þ.e. verður að vera innan sama nafnrýmis. Hins vegar getur hlutverkabinding vísað til ClusterRole, sem gerir þér kleift að búa til safn almennra heimilda og stjórna aðgangi með því að nota þær.

Hlutverk lýsa réttindum með því að nota sett af reglum sem innihalda:

• API hópar - sjá opinber skjöl eftir apiGroups og úttak kubectl api-resources;
• auðlindir (auðlindir: pod, namespace, deployment og svo framvegis.);
• Sagnir (sagnir: set, update og þess háttar).
• auðlindaheiti (resourceNames) - fyrir tilvikið þegar þú þarft að veita aðgang að tiltekinni auðlind, en ekki öllum auðlindum af þessari gerð.

Nánari greiningu á heimildum í Kubernetes er að finna á síðunni opinber skjöl. Í staðinn (eða réttara sagt, til viðbótar þessu) mun ég gefa dæmi sem lýsa verkum hennar.

Dæmi um RBAC einingar

Einfalt Role, sem gerir þér kleift að fá lista og stöðu yfir belg og fylgjast með þeim í nafnarýminu 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"]

Dæmi ClusterRole, sem gerir þér kleift að fá lista og stöðu yfir belg og fylgjast með þeim um allan klasann:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Dæmi RoleBinding, sem gerir notandanum kleift mynewuser „lesa“ hólf í nafnrými 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

Viðburðarúttekt

Skipulega er hægt að tákna Kubernetes arkitektúrinn sem hér segir:

Lykill Kubernetes hluti sem ber ábyrgð á vinnslu beiðna er api-þjónn. Allar aðgerðir á klasanum fara í gegnum hann. Þú getur lesið meira um þessar innri leiðir í greininni “Hvað gerist í Kubernetes þegar þú keyrir kubectl run?'.

Kerfisendurskoðun er áhugaverður eiginleiki í Kubernetes, sem er sjálfgefið óvirkur. Það gerir þér kleift að skrá öll símtöl í Kubernetes API. Eins og þú gætir giskað á, eru allar aðgerðir sem tengjast eftirliti og breytingu á ástandi klasans framkvæmdar í gegnum þetta API. Góða lýsingu á getu þess er (eins og venjulega) að finna í opinber skjöl K8s. Næst mun ég reyna að kynna efnið á einfaldara máli.

Svo, til að gera endurskoðun kleift, við þurfum að senda þrjár nauðsynlegar breytur í gáminn í api-þjóninum, sem er lýst nánar hér að neðan:

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

Til viðbótar við þessar þrjár nauðsynlegu færibreytur eru margar viðbótarstillingar sem tengjast endurskoðun: frá snúningi annála til lýsinga á vefkrókum. Dæmi um snúningsfæribreytur logs:

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

En við munum ekki fjalla nánar um þau - þú getur fundið allar upplýsingar í kube-apiserver skjöl.

Eins og áður hefur komið fram eru allar breytur stilltar í upplýsingaskránni með uppsetningu API-þjónsins (sjálfgefið /etc/kubernetes/manifests/kube-apiserver.yaml), í kafla command. Við skulum fara aftur í 3 nauðsynlegar færibreytur og greina þær:

1. audit-policy-file — slóð að YAML skránni sem lýsir endurskoðunarstefnunni. Við munum fara aftur að innihaldi hennar síðar, en í bili mun ég taka fram að skráin verður að vera læsileg af api-þjónsferlinu. Þess vegna er nauðsynlegt að festa það inni í ílátinu, þar sem þú getur bætt eftirfarandi kóða við viðeigandi hluta stillingarinnar:

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

2. audit-log-path — slóð að annálaskránni. Slóðin verður einnig að vera aðgengileg fyrir api-miðlara ferlið, svo við lýsum uppsetningu þess á sama hátt:

     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 — snið endurskoðunarskrár. Sjálfgefið er json, en gamalt textasnið er einnig fáanlegt (legacy).

Endurskoðunarstefna

Nú um nefnda skrá sem lýsir skógarhöggsstefnunni. Fyrsta hugtakið um endurskoðunarstefnu er level, skógarhöggsstig. Þau eru sem hér segir:

• None - ekki skrá þig;
• Metadata — lýsigögn skráningarbeiðni: notandi, beiðni um tíma, miðatilföng (belg, nafnrými, osfrv.), gerð aðgerða (sögn), osfrv.;
• Request — skráðu lýsigögn og beiðni meginmáls;
• RequestResponse - skrá lýsigögn, beiðni meginmál og svar meginmál.

Síðustu tvö stigin (Request и RequestResponse) ekki skrá beiðnir sem fengu ekki aðgang að auðlindum (aðgangur að svokölluðum slóðum sem ekki eru auðlindir).

Einnig fara allar beiðnir í gegn nokkrum stigum:

• RequestReceived — stigið þegar beiðnin berst vinnsluaðila og hefur ekki enn verið send lengra eftir keðju vinnsluaðila;
• ResponseStarted — svarhausar eru sendir, en áður en svarmálið er sent. Búið til fyrir langvarandi fyrirspurnir (til dæmis, watch);
• ResponseComplete — svaraðalinn hefur verið sendur, engar frekari upplýsingar verða sendar;
• Panic — atburðir myndast þegar óeðlilegt ástand greinist.

Til að sleppa öllum skrefum sem þú getur notað omitStages.

Í stefnuskrá getum við lýst nokkrum hlutum með mismunandi skráningarstigum. Fyrsta samsvörunarreglan sem er að finna í stefnulýsingunni verður notuð.

Kubelet púkinn fylgist með breytingum á upplýsingaskránni með uppsetningu API-þjónsins og, ef einhver finnast, endurræsir hann ílátið með API-þjóninum. En það er mikilvægt smáatriði: breytingar á stefnuskránni verða hunsaðar af henni. Eftir að hafa gert breytingar á stefnuskránni þarftu að endurræsa API-þjóninn handvirkt. Þar sem api-þjónn er byrjaður sem kyrrstæður belg, lið kubectl delete mun ekki valda því að það endurræsist. Þú verður að gera það handvirkt docker stop á kube-masters, þar sem endurskoðunarstefnunni hefur verið breytt:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

Þegar endurskoðun er virkjað er mikilvægt að muna það álagið á kube-apiserver eykst. Einkum eykst minnisnotkun til að geyma beiðnisamhengi. Skráning hefst aðeins eftir að svarhausinn er sendur. Álagið fer einnig eftir uppsetningu endurskoðunarstefnunnar.

Dæmi um stefnur

Við skulum skoða uppbyggingu stefnuskráa með því að nota dæmi.

Hér er einföld skrá policyað skrá allt á stigi Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Í stefnu er hægt að tilgreina lista yfir notendur (Users и ServiceAccounts) og notendahópa. Til dæmis, þetta er hvernig við munum hunsa kerfisnotendur, en skrá allt annað á stigi 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

Einnig er hægt að lýsa markmiðunum:

• nafnarými (namespaces);
• Sagnir (sagnir: get, update, delete og aðrir);
• auðlindir (auðlindir, nefnilega: pod, configmaps o.s.frv.) og auðlindahópa (apiGroups).

Borga eftirtekt! Auðlindir og auðlindahópar (API hópar, þ.e. apiGroups), sem og útgáfur þeirra uppsettar í þyrpingunni, er hægt að fá með skipunum:

kubectl api-resources
kubectl api-versions

Eftirfarandi endurskoðunarstefna er sýnd sem sýning á bestu starfsvenjum í Fjarvistarsönnun skýjaskjöl:

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

Annað gott dæmi um endurskoðunarstefnu er prófíl notað í GCE.

Til að bregðast fljótt við endurskoðunaratburðum er mögulegt lýstu webhook. Um þetta mál er fjallað í opinber skjöl, Ég mun skilja það eftir utan gildissviðs þessarar greinar.

Niðurstöður

Greinin veitir yfirlit yfir helstu öryggiskerfi í Kubernetes klösum, sem gerir þér kleift að búa til sérsniðna notendareikninga, aðgreina réttindi þeirra og skrá aðgerðir þeirra. Ég vona að það nýtist þeim sem standa frammi fyrir slíkum málum í orði eða reynd. Ég mæli líka með því að þú lesir listann yfir önnur efni um öryggi í Kubernetes, sem er gefin upp í „P.S.“ - kannski finnur þú nauðsynlegar upplýsingar um vandamálin sem eiga við þig.

PS

Lestu líka á blogginu okkar:

• «33+ Kubernetes öryggisverkfæri»;
• «Kynning á netstefnu Kubernetes fyrir öryggissérfræðinga»;
• «Að skilja RBAC í Kubernetes»;
• «9 bestu starfsvenjur fyrir Kubernetes öryggi»;
• «11 leiðir til að (ekki) verða fórnarlamb Kubernetes hakks'.

Heimild: www.habr.com