Kubernetes'e turvaabitus: autentimine, autoriseerimine, audit

Iga süsteemi kasutamisel kerkib varem või hiljem esile turvaküsimus: autentimise tagamise, õiguste jagamise, auditi ja teiste ülesannete kindlustamine. Kubernetes'ele on juba loodud palju lahendusi, mis võimaldavad saavutada vastavust standarditele isegi väga nõudlikes keskkondades… See materjal on pühendatud Kubernetes'i sisseehitatud mehhanismide raamides rakendatud turvaelementide põhialustele. Eelkõige on see kasulik neile, kes alustavad Kubernetes'ega tutvumist, — kui lähtepunkt turvaküsimuste uurimiseks.

Autentimine

Kubernetes'is on kaks kasutajatüüpi:

• Teenusekontod — kontod, mida haldab Kubernetes API;
• Kasutajad — „tavalised“ kasutajad, mida haldavad välistest, sõltumatutest teenustest.

Peamine erinevus nende tüüpide vahel on see, et Teenusekontode jaoks on Kubernetes API-s erilised objektid (need kannavad samuti nime — Teenusekontod), mis on seotud nimedega ja autoriseerimisandmete kogumiga, mis on salvestatud klastri Secrets tüüpi objektides. Sellised kasutajad (Teenusekontod) on peamiselt mõeldud õiguste haldamiseks Kubernetes API juurdepääsuks Kubernetes klastri protsesside jaoks.

Tavalised kasutajad ei oma kirjeid Kubernetes API-s: nende haldamine peab toimuma välistes mehhanismides. Need on mõeldud inimestele või protsessidele, kes elavad väljaspool klastrit.

Iga API-päring on seotud kas teenusekonto (Service Account) või kasutajaga, või seda peetakse anonüümseks.

Kasutaja autentimisandmed sisaldavad:

• Kasutajanimi — kasutajanimi (sensitiivne suurte tähtede suhtes!);
• UID — masinloetav kasutaja identifitseerimisrida, mis on "järjekindlam ja ainulaadsem kui kasutajanimi";
• Groups — kasutaja kuuluvate rühmade loetelu;
• Extra — lisaväljad, mida võib kasutada autoriseerimismehhanism.

Kubernetes toetab suurt hulka autentimismehhanisme: X509 sertifikaadid, Bearer-tokenid, autentimisproxi, HTTP Basic Auth. Neid mehhanisme kasutades saab rakendada mitmeid autoriseerimisskeeme: alates staatilisest paroolifailist kuni OpenID OAuth2-ni.

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

• teenusekonto tokenid — teenusekontode jaoks;
• X509 — kasutajate jaoks.

Küsimus ServiceAccountide haldamise kohta jääb selle artikli raamest välja, kuid soovitan selle teema põhjalikumaks tutvumiseks alustada ametlikest dokumentatsioonilehtedest. Meie vaatame lähemalt X509 sertifikaatide tööd.

Kasutaja sertifikaadid (X.509)

Klassikaline viis sertifikaatidega töötamiseks hõlmab:

• võtme genereerimist:

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

• sertifikaadi päringu genereerimist:

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

• sertifikaadi päringu töötlemist Kubernetes klastri CA võtmete abil, kasutaja sertifikaadi saamist (sertifikaadi saamiseks tuleb kasutada kontot, millel on juurdepääs klastri sertifitseerimiskeskuse võtmele, mis vaikimisi asub /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

• konfiguratsioonifaili loomist:
  • klastri kirjeldus (märkige CA sertifikaadi aadress ja asukoht antud klastrite installatsioonis):

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

  • või — kuidas eisoovitatav valik — juuresertifikaati ei ole vaja näidata (sel juhul ei kontrolli kubectl klastrite api-serveri õigust):

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

  • kasutaja lisamine konfiguratsioonifaili:

    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 ülalkirjeldatud toimingute tegemist, failis .kube/config loodakse konfiguraator järgmises vormis:

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

Konfiguraatori edasiviimise lihtsustamiseks kontode ja serverite vahel on kasulik redigeerida järgmiste võtmete väärtusi:

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

Selleks võib määratletud failid kodeerida base64 abil ja lisada need konfiguratsiooni, lisades võtme nimedele sufiksi -data, st saades certificate-authority-data jne.

Sertifikaadid kubeadm-iga

Koos väljaandega Kubernetes 1.15 sertifikaatidega töötamine on muutunud oluliselt lihtsamaks, tänu selle toe alfa-versioonile utiliidis kubeadm. Näiteks, siin on, kuidas nüüd võib välja näha kasutaja võtmete konfigureerimisfaili genereerimine:

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

NB: Nõutav reklaamimisadress saab vaadata api-serveri konfigureerimisfailist, mis asub vaikimisi aadressil /etc/kubernetes/manifests/kube-apiserver.yaml.

Tulemuseks olev konfiguraatsioon kuvatakse stdout-is. See tuleb salvestada ~/.kube/config kasutaja kontole või faili, mille kohta on määratud keskkonnamuutuja KUBECONFIG.

Sügavamale kaevuma

Neile, kes soovivad põhjalikumalt uurida käsitletud teemasid:

• eraldi artikkel sertifikaatide käsitlemisest Kubernetes'i ametlikus dokumentatsioonis;
• hea artikkel Bitnamilt, kus sertifikaatide küsimust käsitletakse praktilisest küljest.
• üldine dokumentatsioon Kubernetes'e autentimise kohta.

Autoriseerimine

Vaikimisi volitatud konto ei oma õigusi klastris tegutsemiseks. Kubernetes'is on volituste andmiseks rakendatud autoriseerimise mehanismi.

Kuni versioonini 1.6 kasutati Kubernetes'is autoriseerimistüüp, mida nimetatakse ABAC (atribuutide põhine juurdepääsu kontroll). Lisainfot leiate ametlikus dokumentatsioonis. Praegu peetakse seda lähenemist vananenuks (legacy), kuid saate seda siiski kasutada koos teiste autoriseerimisliikidega.

Praegune (ja paindlikum) meetod juurdepääsuõiguste jagamiseks klastris on nimetatud RBAC (Rollipõhine juurdepääsu kontroll). See kuulutati stabiilseks alates versioonist Kubernetes 1.8. RBAC rakendab õiguste mudelit, kus keelatud on kõik, mis ei ole selgelt lubatud.
RBAC-i aktiveerimisekstuleb käivitada Kubernetes api-server koos parameetriga --authorization-mode=RBAC. Parameetrid määratakse api-serveri konfigureerimise manifestis, mis asub vaikimisi teel /etc/kubernetes/manifests/kube-apiserver.yaml, jaoks command. Siiski on RBAC vaikimisi juba sisse lülitatud, seega tõenäoliselt pole põhjust muretseda: saate seda kontrollida väärtuse kaudu authorization-mode (eelnevalt mainitud kube-apiserver.yaml). Muide, selle väärtuste seas võivad esineda ka teisi autoriseerimisliike (node, webhook, always allow), kuid nende arutamine jääb materiaali raames välja.

Muide, oleme juba avaldanud artiklile üsna põhjaliku ülevaate RBAC-iga töötamise põhimõtetest ja eripäradest, seega piirdun siin põhitõdede ja näidete lühikese loeteluga.

Kubernetes'i RBAC kaudu juurdepääsu haldamiseks kasutatakse järgmisi API-entiteete:

• Roll ja ClusterRole — rollid, mis kirjeldavad ligipääsuõigusi:
• Roll kütus kirjeldada õigusi nimetatud nimekirjas;
• ClusterRole — klastris, sealhulgas klastrispetsiifiliste objektide, nagu sõlmede, non-resources URL-ide (st Kubernetes'e ressurssidega mitte seotud — näiteks, /version, /logs, /api*);
• Rolli seondus ja ClusterRoleBinding — teenib seondumiseks Roll ja ClusterRole kasutajale, kasutajagrupile või ServiceAccount'ile.

Rolli ja Rolli seondus entiteedid on piiratud nimeserveri ulatuses, st nad peavad olema ühe nimeserveri piires. Siiski võib Rolli seondus viidata ClusterRole'ile, mis võimaldab luua rikka loomuliku loa komplekti ja hallata juurdepääsu nende abil.

Rollid kirjeldavad õigusi reeglite komplektide abil, mis sisaldavad:

• API-grupid — vt. ametlikku dokumentatsiooni apiGroups ja väljund kubectl api-resources;
• ressursid (resources: pod, namespace, deployment jne);
• tegusõnad (verbs: set, update jne).
• ressursi nimed (resourceNames) — olukordades, kus tuleb anda juurdepääs kindlale ressursile, mitte kõigile selle tüübi ressurssidele.

Kubernetes'i autoriseerimise üksikasjalikum analüüs on saadaval leheküljelt ametlikus dokumentatsioonis. Selle asemel (ja täienduseks sellele) toon näited, mis illustreerivad selle toimimist.

RBAC-i näidisobjektid

Lihtne Roll, mis võimaldab tuua välja podide nimekirja ja staatuse ning neid jälgida sihtnimekirjas siht-nimekiri:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: siht-nimekiri
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Näide ClusterRole, mis võimaldab tuua välja podide nimekirja ja staatuse ning neid jälgida kogu klastris:

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

Näide Rolli seondus, mis annab kasutajale minuunewuser «lugeda» pod’e sihtnimekirjas minu-nimekiri:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: siht-nimekiri
subjects:
- kind: User
  name: minuuser # kasutajanimi on tundlik suur- ja väikeharfide suhtes!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # siin peab olema “Role” või “ClusterRole”
  name: pod-reader # Role'i nimi, mis asub samas nimekirjas
                   # või ClusterRole'i nimi, mille kasutamist
                   # soovime kasutajale lubada
  apiGroup: rbac.authorization.k8s.io

Sündmuste audit

Kubernetes'i arhitektuuri võib joonistada järgmiselt:

Kubernetes'i peamine komponent, mis vastutab päringute töötlemise eest, on api-server. Kõik klastriga seotud toimingud käivad selle kaudu. Nendest sisemistest mehhanismidest saab rohkem lugeda artiklist „Mis juhtub Kuberneteses, kui käivitada kubectl run?».

Süsteemi auditeerimine on huvitav funktsioon Kuberneteses, mis on vaikimisi välja lülitatud. See võimaldab logida kõiki pöördumisi Kubernetes API-le. Nagu lihtne arvata, tehakse kõik klastrit puudutavad toimingud just selle API kaudu. Selle võimaluste kohta saab head kirjeldust leida (nagu ikka) ametlikus dokumentatsioonis K8s. Järgnevalt püüan teemat lihtsamalt selgitada.

Nii et, auditimise lubamiseks, peame api-serverile konteinerisse edastama kolm kohustuslikku parameetrit, millest allpool rohkem juttu:

• --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 vajalikele parameetrile on veel palju muid seadeid auditeerimise kohta: logide pööramine kuni webhookide kirjeldusteni. Näide logide pööramise parameetritest:

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

Kuid jääme nendele pikemalt peatuma — kõik detailid leiate kube-apiserveri dokumentatsioonist.

Nagu juba mainitud, seadistatakse kõik parameetrid api-serveri konfiguratsioonimanifestis (vaikimisi /etc/kubernetes/manifests/kube-apiserver.yaml), sektsioonis command. Naaseme kolme kohustusliku parameetri juurde ja vaatame need läbi:

1. audit-policy-file — tee YAML-failini, mis kirjeldab auditi poliitikat (policy). Me pöördume selle sisu poole hiljem, aga märkida tuleb, et fail peab olema api-serveri protsessile loetav. Seetõttu tuleb see konteinerisse montaažida, mille jaoks saate lisada järgmise koodi vastavatesse konfigureerimise sektsioonidesse:

     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 olema samuti api-serveri protsessile loetav, seega kirjeldame selle montaaži samamoodi:

     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, aga saadaval on ka vananenud tekstivormaat (legacy).

Auditi poliitika

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

• Puudub — ei logi;
• Metadata — logige päringute metaandmed: kasutaja, päringu aeg, sihtressurss (pod, namespace jne), tegevuse tüüp (verb) jne;
• Request — logige metaandmed ja päringu body;
• RequestResponse — logige metaandmed, päringu body ja vastuse body.

Viimane kaks taset (Request ja RequestResponse) ei logi päringuid, mis ei suunatud ressurssidele (nn non-resources urls).

Samuti läbivad kõik päringud mitmeid etappe:

• RequestReceived — etapp, kui päring on töödeldud ja pole veel edastatud järgnevatele töötlejatele;
• ResponseStarted — vastuse pealkirjad on saadetud, kuid enne vastuse body edastamist. See genereeritakse pikaajaliste päringute jaoks (näiteks, watch);
• ResponseComplete — vastuse body on saadetud, rohkem teavet ei saadeta;
• Panic — sündmused genereeritakse, kui avastatakse ebanormaalne olukord.

Mõnede etapide vahelejätmiseks saab kasutada omitStages.

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

Kubelet jälgib api-serveri konfiguratsioonifesti muudatusi ja, kui selliseid avastatakse, taaskäivitab api-serveri konteineri. Kuid on üks oluline detail: muudatusi policy failis ei võeta arvesse.Pärast muudatuste tegemist policy failis tuleb api-server manuaalselt taaskäivitada. Kuna api-server töötab kui staatiline pod,, käsk kubectl delete ei too kaasa tema taaskäivitamist. Manuaalselt tuleb teha docker stop kube-masteritel, kus audiitpoliitikat on muudetud:

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

Auditimise lubamisel on oluline meeles pidada, et kube-apiserverile tõuseb koormus.Eriti suureneb mälu tarbimine päringute konteksti salvestamiseks. Logimise algus toimub alles pärast vastusepealkirja saatmist. Samuti sõltub koormus audiitpoliitika konfiguratsioonist.

Poliitika näidised

Analüüsime policy failide struktuuri näidete varal.

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

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

Policy failis saab määrata kasutajate (Kasutajad ja Teenusekontod) ja kasutajagruppide loendi. Näiteks, nii ignoreerime süsteemikasutajaid, kuid logime kõik muu tasemel 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

Samuti on võimalik kirjeldada sihtkohti:

• nimetused (namespaces);
• tegusõnad (verbs: get, update, kustuta ja muud);
• ressursid (resources, nimelt: pod, configmaps jne.) ning ressursside rühmad (apiGroups).

Palun pöörake tähelepanu! Ressursse ja ressursigruppide (API grupid, st apiGroups) versioone, mis on klastris installitud, saab saada järgmiste käskude abil:

kubectl api-resources
kubectl api-versions

Järgmine audit policy on toodud parimate praktikate demonstreerimiseks Alibaba Cloud'i dokumentatsioonis:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Ära logi RequestReceived etappi
omitStages:
  - "RequestReceived"
rules:
  # Ära logi sündmusi, mis peetakse vähenenud tähtsusega ja mitteohtlikeks:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # see on api grupp tühja nimega, mis kuulub
                  # Kubernetes'i põhivahendite alla, 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 lugemisõigusega URL-e:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Ära logi sündmusi, mis kuuluvad “sündmuste” ressursi tüübi alla:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Secret-i, ConfigMap-i ja TokenReview'i ressursid võivad sisaldada salajasi andmeid,
  # seega logime vaid seotud päringute metainformatsiooni
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Get-, list- ja watch-toimingud võivad olla ressursiintensiivsed; 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 standardsete API ressursside 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õigi teiste päringute jaoks
  - level: Metadata

Teine hea näide auditipoliitikast on profiil, mida kasutatakse GCE-s.

Auditisündmustele reageerimiseks on võimalik kirjeldada webhook'i. Seda küsimust käsitletakse ametlikus dokumentatsioonis, jätn ära selle artikli raamidest.

Kokkuvõte

Artiklis antakse ülevaade Kubernetes'e klastrite põhiturvamehhanismidest, mis võimaldavad luua isikupärastatud kasutajakontosid, jagada nende õigusi ja registreerida nende tegevusi. Loodan, et see on kasulik neile, kes on sarnaste küsimustega kokku puutunud teoorias või juba praktikas. Samuti soovitan tutvuda muude turvateemadega seotud materjalide loetelu, mis on toodud "P.S.", — võib-olla leiate nende hulgast vajalikke üksikasju teie jaoks olulistes küsimustes.

P.S.

Lugege ka meie blogist:

• «33+ Kubernetes'i turbe tööriista»;
• «Kubernetes'e võrgupoliitikas tutvumine turvaekspertidele»;
• «Mõistame RBAC-i Kubernetes'es»;
• «9 parimat praktikat Kubernetes'e turvamiseks»;
• «11 viisi, kuidas (mitte) sattuda Kubernetes'e häkkimise ohvriks».

Allikas: habr.com