Kubernetes’i turvalisuse abecedaar: autentimine, autoriseerimine, audit

Varem või hiljem tekib iga süsteemi kasutamisel küsimus turvalisusest: autentimise, õiguste jagamise, auditeerimise ja muude ülesannete tagamisest. Kubernetes'ele on juba loodud hulgaliselt lahendusi, mis võimaldavad saavutada vastavust standarditele isegi väga nõudlikes keskkondades... See materjal keskendub K8s sisseehitatud mehhanismide raames rakendatud turvalisuse põhiaspektidele. Esiteks on see kasulik neile, kes tutvuvad Kubernetes'ega, - kui alguspunkt küsimuste uurimiseks, mis on seotud turvalisusega.

Ahnikeerimine

Kubernetes'is on kaks kasutajatüüpi:

• Teenusekontod — Kubernetes API poolt hallatavad kontod;
• Kasutajad — "tavalised" kasutajad, keda haldavad välised, sõltumatud teenused.

Peamine erinevus nende tüüpide vahel on see, et Teenusekontode jaoks eksisteerivad Kubernetes API-s spetsiaalsed objektid (neid nimetatakse ka Teenusekontodeks), mis on seotud nimede ruumiga ja autoriseerimisandmete kogumiga, mis on salvestatud klastris Secrets tüüpi objektidesse. Sellised kasutajad (Teenusekontod) on peamiselt mõeldud Kubernetes API juurdepääsuõiguste haldamiseks nende protsesside jaoks, mis töötavad Kubernetes klastris.

Tavalised kasutajad ei oma kirjeid Kubernetes API-s: nende haldamine peab toimuma väliste mehhanismide kaudu. Nad on mõeldud inimestele või protsessidele, kes elavad klastrist väljaspool.

Iga API päring on seotud kas Teenusekonto või Kasutajaga või loetakse anonüümseks.

Kasutaja autentimisandmed sisaldavad:

• Kasutajanimi — kasutajanimi (sõltub suurtest ja väikestest tähtedest!);
• UID — masinloetav identifitseerimisnumber, mis on "tugevam ja ainulaadsem kui kasutajanimi";
• Rühmad — kasutaja kuuluvate rühmade nimekiri;
• Extra — täiendavad väljad, mida võib autoriseerimismehhanismis kasutada.

Kubernetes saab kasutada mitmeid autentimismehhanisme: X509 sertifikaate, Bearer-tokens, autentimisproxies, HTTP Basic Auth. Nende mehhanismide abil saab rakendada mitmeid autoriseerimisskeeme: staatilisest paroolifailist kuni OpenID OAuth2-ni.

Lisaks on lubatud mitme autoriseerimisskeemi samaaegne kasutamine. Vaikimisi kasutatakse klastris:

• teenusekonto märke — Teenusekontode jaoks;
• X509 — Kasutajate jaoks.

Küsimus ServiceAccounts'i haldamise kohta ületab käesoleva artikli piire, ning neile, kes soovivad sellest teemast lähemalt tutvuda, soovitan alustada ametliku dokumentatsiooni lehelt. Me käsitleme detailsemalt X.509 sertifikaatide tööd.

Kasutajate sertifikaadid (X.509)

Klassikaline sertifikaatidega töötamise viis eeldab:

• võtme genereerimist:

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

• sertifikaadi taotluse genereerimist:

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

• sertifikaadi taotluse töötlemist Kubernetes klastrite CA võtmete abil, kasutaja sertifikaadi saamist (sertifikaadi saamiseks tuleb kasutada kontot, millel on juurdepääs Kubernetes klastrite sertifitseerimiskeskuse võtmele, mis asub vaikimisi /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/mynewuser/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/mynewuser/.certs/mynewuser.crt -days 500

• konfiguratsiooni faili loomist:
  • klastri kirjeldust (määra CA sertifikaadi aadress ja asukoht konkreetse klastri installatsiooni kohta):

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

  • või — nagu eisoovitatav variant — ei pruugi öelda juure sertifikaadi (siis kubectl ei kontrolli klastrite api-serveri õigust):

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

  • kasutaja lisamine konfigureerimisfaili:

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

  • konteksti lisamine:

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

  • vaikimisi konteksti määramine:

    kubectl config use-context mynewuser-context

Pärast ülaltoodud toiminguid luuakse failis .kube/config konfiguratsioon järgmisel kujul:

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

Konfiguratsiooni lihtsustamiseks konto ja serverite vahel on kasulik redigeerida järgmiste võtmete väärtusi:

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

Selleks saab nimetatud failid kodeerida base64 ja kirjutada need konfiguratsiooni, lisades võtme nimedele suffiksi -data, st pakkuda certificate-authority-data jne.

Sertifikaadid kubeadm'iga

Kubernetes 1.15 väljaandega Kubernetes 1.15 Töötamine sertifikaatidega on muutunud oluliselt lihtsamaks tänu alpha-versioonile selle toe. utiliidile kubeadm.Näiteks, nii võiks nüüd välja näha конфигурационный файл koos kasutaja võtmetega:

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

NB: Nõutud advertise address. Saate seda vaadata api-serveri konfiguraatsioonis, mis asub vaikimisi aadressil /etc/kubernetes/manifests/kube-apiserver.yaml.

Tulemuslik konfiguraatsioon kuvatakse stdout-s. See tuleb salvestada ~/.kube/config kasutaja kontole või faili, mille olete määranud keskkonnamuutujas. KUBECONFIG.

Kaevama sügavamale

Neile, kes soovivad neid küsimusi põhjalikumalt uurida:

• erinev artikkel sertifikaatide töötamine Kubernetes ametlikus dokumentatsioonis;
• hea artikkel Bitnamilt,, kus sertifikaatide küsimust käsitletakse praktilise poole pealt.
• üldine dokumentatsioon Kubernetes'e autentimise kohta.

Autoriseerimine

Vaikimisi ei oma autoriseeritud konto õigusi klastris tegutsemiseks. Kubernetes'is on rakendatud autoriseerimise mehhanism õiguste määramiseks.

Kuni versioonini 1.6 kasutati Kubernetes'is autoriseerimise tüüpi, mida nimetatakse ABAC (Attribute-based access control). Üksikasjad selle kohta leiate ametlikust dokumentatsioonistSiiski peetakse seda lähenemist vananenuks (legacy), kuid saate seda ikkagi kasutada koos teiste autoriseerimise tüüpidena.

Praegu aktsepteeritud (ja paindlikum) viis õiguste jagamiseks klastrisse nimetatakse RBAC (Role-based access control.) See kuulutati stabiilseks alates versioonist Kubernetes 1.8.RBAC rakendab õiguste mudelit, kus kõik, mis ei ole selgesõnaliselt lubatud, on keelatud.
RBAC'i lubamiseks, peate käivitama Kubernetes api-serveri koos parameetriga --authorization-mode=RBAC.Parameetrid seotakse manti jaga konfigureerimisega, mis asub vaikimisi aadressil /etc/kubernetes/manifests/kube-apiserver.yaml, jaotises käsk. Siiski on RBAC vaikimisi juba lubatud, mistõttu ei tasu selle pärast ärevust tunda: selle olemasolu saab kontrollida väärtusest authorization-mode (juba mainitud kube-apiserver.yaml.). Muide, selle väärtuste hulgas võivad olla ka teised autoriseerimise tüübid (node, webhook, always allow), kuid nende käsitlemine jääb käesoleva materjali teemast väljapoole.

Muide, oleme juba avaldanud artiklit piisavalt detailselt juttu RBAC'iga töötamise põhimõtetest ja eripäradest, seega piirduksin edaspidi põhimõtete ja näidete lühikese loetlemisega.

Kubernetes'is juurdepääsu haldamiseks RBAC kaudu kasutatakse järgmisi API üksusi:

• Role ja ClusterRole — rollid, mis kirjeldavad juurdepääsuõigusi:
• Role aitab kirjeldada õigusi nimiruumide raames;
• ClusterRole — klastris, sealhulgas klastrispetsiifilised objektid nagu sõlmed, non-resources urls (st mitte-Kubernetes'i ressurssidega seotud — näiteks, /version, /logs, /api*);
• RoleBinding ja ClusterRoleBinding — teenib sidumise jaoks Role ja ClusterRole kasutajale, kasutajagruppidele või ServiceAccount'ile.

Rolli ja RolliSidumise entiteedid on piiratud nimiruumiga, st peavad jääma ühe nimiruumi piiresse. Kuid RolliSidumine võib viidata ClusterRole'le, mis võimaldab luua tüüpiliste õiguste komplekti ja hallata juurdepääsu nende kaudu.

Rollid kirjeldavad õigusi reeglite kogumite abil, mis sisaldavad:

• API rühmad - vt. ametlikku dokumentatsiooni apiGroups ja väljundit kubectl api-resources;
• ressursid (ressursid: pod, namespace, deployment jne);
• tegusõnad (tegusõnad: set, update jne.).
• ressursside nimed (resourceNames) — juhul, kui on vaja anda juurdepääs mõnele konkreetsele ressursile, mitte kõigile selle tüübi ressurssidele.

Kubernetes'i autoriseerimise põhjalikku analüüsi leiate lehelt ametlikust dokumentatsioonist. Selle asemel (ja täpsemalt — selle lisandina) toome näited, mis illustreerivad selle toimimist.

RBAC entiteetide näited

Lihtne Role, mis võimaldab saada loend ja olek pod'ide ning jälgida neid nimiruumis 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"]

Näide ClusterRole, mis võimaldab saada loend ja olek pod'ide ning jälgida neid kogu klastris:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # sektsioon "namespace" puudub, kuna ClusterRole katab kogu klastri
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Näide RoleBinding, mis võimaldab kasutajal mynewuser «lugeda» pod'e nimiruumis my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # kasutajanimi on juhtumists sõltuv!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # siin peab olema “Role” või “ClusterRole”
  name: pod-reader # rolli nimi, mis asub samas nimiruumis,
                   # või ClusterRole'i nimi, mille kasutamist
                   # tahame kasutajale lubada
  apiGroup: rbac.authorization.k8s.io

Sündmuste audit

Kubernetes'i arhitektuuri võib skeemiliselt esitada järgmiselt:

Kubernetes'i võtmeelement, mis vastutab päringute töötlemise eest, on api-server. Kõik operatsioonid klastriga toimuvad selle kaudu. Täiendava teabe saamiseks nende sisemehanismide kohta lugege artiklit «Mis toimub Kuberneteses, kui käivitame kubectl run?».

Süsteemi auditeerimine on huvitav funktsioon Kuberneteses, mis on vaikimisi välja lülitatud. See võimaldab logida kõik päringud Kubernetes API-le. Nagu kergesti arvata võib, toimub kõik tegevused, mis on seotud klastri oleku kontrolli ja muutmisega, läbi selle API. Hea ülevaate selle võimalustest saab (nagu tavaliselt) leida ametlikust dokumentatsioonist K8s. Edasi püüan ma teemat väljendada lihtsamate sõnadega.

Nii, auditeerimise aktiveerimiseks, peame edastama konteinerile api-serverisse kolm kohustuslikku parameetrit, millest lähemalt räägin allpool:

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

Lisaks nendele kolmele vajalikule parameetrile on olemas palju lisaseadeid, mis puudutavad auditeerimist: logide pööramine kuni webhookide seadistamiseni. Näide logide pööramise parameetritest:

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

Aga ei hakka nendel pikemalt peatuma — kõik detailid on leitavad kube-apiserveri dokumentatsioonis.

Nagu juba mainitud, kõik parameetrid määratakse api-serveri konfiguratsiooni manifestis (vaikimisi /etc/kubernetes/manifests/kube-apiserver.yaml), sektsioonis käsk. Naaseme kolme kohustusliku parameetri juurde ja vaatame neid lähemalt:

1. audit-policy-file — tee YAML-failini, kus on kirjas auditeerimise poliitika. Selle sisusse me veel tagasi tuleme, kuid praegu mainin, et fail peab olema api-serveri protsessile ligipääsetav. Seetõttu tuleb see konteinerisse mountida, nii et saame lisada järgmise koodi vastavatesse seadistuse osadesse:

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

2. audit-log-path — tee logifailini. Tee peab samuti olema api-serveri protsessile ligipääsetav, seega kirjeldame selle mountimist sarnaselt:

     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 — auditi logi formaat. Vaikimisi on see json, kuid saadaval on ka vananenud tekstiformaadis (legacy).

Auditeerimise poliitika

Nüüd rääkides mainitud failist, kus on kirjas logimise poliitika. Esimene mõisted audit policy — see on level, logimise tase. Need võivad olla järgmised:

• None — mitte logida;
• Metadata — logida päringu metainformatsiooni: kasutaja, päringu aeg, sihtressurss (pod, namespace jne), tegevuse tüüp (verb) jne;
• Päring — logida metainformatsioon ja päringu keha;
• RequestResponse — logida metaandmeid, päringu sisu ja vastuse sisu.

Viimane kaks taset (Päring ja RequestResponse) ei logi päringuid, mis ei suunanud ressursse (näiteks nn non-resources urls).

Kõik päringud läbivad samuti mitu etappi:

• RequestReceived — etapp, mil päring on töötleja poolt saadud ja ei ole veel edasi antud töötleja ahelas;
• ResponseStarted — vastuse pealkirjad on saadetud, kuid enne vastuse sisu saatmist. Genereeritakse pikaajaliste päringute jaoks (näiteks, watch);
• ResponseComplete — vastuse sisu on saadetud, rohkem teavet ei saadeta;
• Panic — sündmused genereeritakse, kui tuvastatakse erandolukord.

Mõningate etappide vahelejätmiseks saab kasutada omitStages.

Poliitika failis saame kirjeldada mitmeid sektsioone erinevate logimise tasemetega. Rakendatakse esimest sobivat reeglit, mis leiti poliitika kirjeldusest.

Demon kubelet jälgib api-serveri konfiguratsiooni manifesti muutusi ja tuvastades, käivitab ta api-serveri konteineri uuesti. Kuid on oluline üks detail: poliitika faili muutusi ignoreeritakse. Pärast muudatuste tegemist poliitika failis tuleb api-server spetsiaalselt uuesti käivitada. Kuna api-server on käivitunud kui static pod, käsk kubectl delete ei põhjusta selle taaskäivitamist. Tuleb manuaalselt teha docker stop kube-master’ides, kus auditi poliitika on muudetud:

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

Auditi lubamisel on oluline meeles pidada, et kube-apiserveri koormus tõuseb. Eriti suureneb mälu tarbimine päringute konteksti hoidmiseks. Logimine algab alles pärast vastuse pealkirja saatmist. Samuti sõltub koormus auditi poliitika konfiguratsioonist.

Poliitikate näited

Käsitleme poliitika failide struktuuri näidete kaudu.

Siin on lihtne fail policy, et logida kõike tasemel Metadata:

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

Poliitikas saab määrata kasutajate (Kasutajad ja Teenusekontodeks) ja kasutajagruppide nimekirja. Näiteks, nii ignoreerime süsteemi kasutajaid, kuid logime kõik muu tasemel Päring:

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

Samuti on võimalik kirjeldada sihtkohti:

• nimetuse ruume (namespaces);
• tegusõnad (tegusõnad: get, update, delete ja muud);
• ressursid (ressursid, nimelt: pod, configmaps jne.) ja ressursside gruppe (apiGroups).

Pange tähele! Ressursid ja ressursigrupid (API rühmad, st apiGroups) ning nende versioonid, mis on klastrisse installitud, on saadaval järgmiste käskude abil:

kubectl api-resources
kubectl api-versions

Järgnevat auditi poliitikat tuuakse kui parimate praktikate näide Alibaba Cloud dokumentatsioonis:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Ära logi RequestReceived etappi
omitStages:
  - "RequestReceived"
rules:
  # Ära logi juhtumeid, mida peetakse väheoluliseks ja mitte ohtlikuks:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # see on api rühm tühja nimega, mis kuulub
                  # Kubernetes'i põhivara, mida nimetatakse "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"]
  # Ära logi lugemise ainult URL-esid:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Ära logi sõnumeid, mis kuuluvad "sündmuste" ressursside tüübile:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Salajased andmed, ConfigMap ja TokenReview ressursid võivad sisaldada
  # salajasi andmeid, seega logime ainult nende taotluste metainfoid
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Get, list ja watch toimingud võivad olla ressursimahukad; ei logi neid
  - 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"
  # Vaikimisi logimise tase API standardressursside jaoks
  - 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"
  # Vaikimisi logimise tase kõikide teiste taotluste jaoks
  - level: Metadata

Teine hea näide audit poliitikast — profiil, mida kasutatakse GCE-s.

Auditisündmustele kiiresti reageerimiseks on võimalus kirjeldada webhook. See teema on avatud ametlikust dokumentatsioonist, jätan selle artikli raames käsitlemata.

Summary

Artiklis antakse ülevaade Kubernetes klastrite põhjalike turvainstrumentide mehhanismidest, mis võimaldavad luua isikupärastatud kontosid kasutajatele, jagada nende õigusi ning registreerida nende tegevusi. Loodan, et see on kasulik neile, kes on silmitsi selliste küsimustega teoorias või juba praktikaliselt. Soovitan tutvuda ka muu turvalisuse temaatikaga seotud materjalide nimekirjaga, mis on toodud "P.S."-s — võib-olla leiate sealt vajalikud üksikasjad teile olulistes probleemides.

P.S.

Lugege ka meie blogist:

• «33+ Kubernetesi turvalisuse tööriista»;
• «Kubernetesi võrgupoliitikate sissejuhatus turbespetsialistidele»;
• «Mõistame RBAC-d Kuberneteses»;
• «9 parimat praktikat Kubernetes'e turvalisuse tagamiseks»;
• «11 viisi (mitte) saada Kubernetes'i häkkimise ohvriks».

Allikas: habr.com