ABC Kaamanan di Kubernetes: Auténtikasi, Otorisasina, Auditing

Moal lami deui atanapi engké, dina operasi sistem naon waé, masalah kaamanan timbul: mastikeun auténtikasi, pamisahan hak, pamariksaan sareng tugas sanés. Geus dijieun pikeun Kubernetes loba solusi, nu ngidinan Anjeun pikeun ngahontal minuhan standar malah dina lingkungan pisan nuntut... Bahan sarua devoted kana aspék dasar kaamanan dilaksanakeun dina mékanisme diwangun-di K8s. Anu mimiti, éta bakal mangpaat pikeun anu mimiti kenal sareng Kubernetes - salaku titik awal pikeun diajar masalah anu aya hubunganana sareng kaamanan.

Konfirmasi

Aya dua jinis pangguna dina Kubernetes:

• Rekening jasa - akun anu dikelola ku API Kubernetes;
• pamaké — Pamaké "normal" anu diurus ku jasa éksternal anu mandiri.

Beda utama antara jenis ieu nyaéta pikeun Akun Layanan aya objék khusus dina API Kubernetes (anjeunna disebut - ServiceAccounts), nu dihijikeun ka ngaranspasi sarta susunan data otorisasina disimpen dina klaster dina objék tina tipe Rahasia. Pamaké sapertos kitu (Akun Layanan) utamina dimaksudkeun pikeun ngatur hak aksés kana API Kubernetes prosés anu dijalankeun dina klaster Kubernetes.

Pamaké Biasa teu gaduh éntri dina API Kubernetes: aranjeunna kedah diurus ku mékanisme éksternal. Éta dimaksudkeun pikeun jalma atanapi prosés anu hirup di luar klaster.

Unggal pamundut API pakait sareng Akun Layanan, Pamaké, atanapi dianggap anonim.

Data auténtikasi pangguna kalebet:

• ngaran nu maké - ngaran pamaké (sénsitip leutik!);
• UID - string idéntifikasi pamaké nu bisa dibaca mesin nu "leuwih konsisten tur unik ti ngaran pamaké";
• Grup - daptar grup nu pamaké milik;
• tambahan - widang tambahan nu bisa dipaké ku mékanisme otorisasina.

Kubernetes tiasa ngagunakeun angka nu gede ngarupakeun mékanisme auténtikasi: sertipikat X509, tokens Bearer, authenticating proxy, HTTP Auth Dasar. Nganggo mékanisme ieu, anjeun tiasa nerapkeun sajumlah ageung skéma otorisasi: tina file statik sareng kecap akses ka OpenID OAuth2.

Leuwih ti éta, kasebut nyaéta dimungkinkeun pikeun ngagunakeun sababaraha schemes otorisasina sakaligus. Sacara standar, klaster ngagunakeun:

• token akun jasa - pikeun Akun Layanan;
• X509 - pikeun Pamaké.

Patarosan ngeunaan ngatur ServiceAccounts saluareun ruang lingkup artikel ieu, tapi pikeun maranéhanana anu hayang familiarize diri jeung masalah ieu dina leuwih jéntré, abdi nyarankeun dimimitian ku. kaca dokuméntasi resmi. Urang bakal ningali langkung caket kana masalah kumaha sertipikat X509 jalan.

Sertipikat pikeun pamaké (X.509)

Cara klasik pikeun damel sareng sertipikat ngalibatkeun:

• Generasi konci:

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

• ngahasilkeun pamundut sertipikat:

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

• ngolah pamundut sertipikat ngagunakeun kenop Kubernetes klaster CA, meunangkeun sertipikat pamaké (pikeun ménta sertipikat, Anjeun kudu make akun nu boga aksés ka konci Kubernetes klaster CA, nu sacara standar lokasina di /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

• nyieun file konfigurasi:
  • pedaran klaster (sebutkeun alamat jeung lokasi file sertipikat CA pikeun instalasi klaster husus):

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

  • atawa kumaha teupilihan anu disarankeun - anjeun henteu kedah netepkeun sertipikat akar (teras kubectl moal pariksa kabeneran API-server klaster):

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

  • nambahkeun pamaké kana file konfigurasi:

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

  • nambahkeun konteks:

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

  • tugas konteks standar:

    kubectl config use-context mynewuser-context

Saatos manipulasi di luhur, dina file .kube/config a config kawas ieu bakal dijieun:

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

Pikeun ngagampangkeun nransfer konfigurasi antara akun sareng server, mangpaat pikeun ngédit nilai-nilai konci ieu:

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

Jang ngalampahkeun ieu, anjeun tiasa encode file anu ditunjukkeun dina aranjeunna nganggo base64 sareng ngadaptarkeunana dina konfigurasi, nambihan sufiks kana nami konci. -data, i.e. sanggeus narima certificate-authority-data jeung sajabana

Sertipikat sareng kubeadm

Kalayan ngaleupaskeun Kubernet 1.15 gawé bareng sertipikat geus jadi loba gampang berkat versi alfa pangrojong na di utiliti kubeadm. Salaku conto, ieu mangrupikeun anu ngahasilkeun file konfigurasi nganggo konci pangguna ayeuna sigana sapertos:

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

NB: Diperlukeun alamat ngiklankeun tiasa dipendakan dina konfigurasi api-server, anu sacara standar aya di /etc/kubernetes/manifests/kube-apiserver.yaml.

Konfigurasi anu dihasilkeun bakal kaluaran ka stdout. Ieu perlu disimpen dina ~/.kube/config akun pamaké atawa kana file nu ditangtukeun dina variabel lingkungan KUBECONFIG.

Ngali Deeper

Pikeun anu hoyong ngartos masalah anu dijelaskeun langkung lengkep:

• tulisan misah dina gawé bareng sertipikat dina dokuméntasi resmi Kubernetes;
• artikel alus ti Bitnami, dimana masalah sertipikat disentuh tina sudut pandang praktis.
• dokuméntasi umum on auténtikasi dina Kubernetes.

mieun kuwasa

Akun otorisasi standar teu gaduh hak pikeun beroperasi dina kluster. Pikeun masihan idin, Kubernetes nerapkeun mékanisme otorisasi.

Sateuacan versi 1.6, Kubernetes nganggo jinis otorisasi anu disebut ABAC (Kadali aksés dumasar-atribut). Rincian ngeunaan éta tiasa dipendakan dina dokuméntasi resmi. Pendekatan ieu ayeuna dianggap warisan, tapi anjeun masih tiasa dianggo sareng jinis auténtikasi anu sanés.

Cara ayeuna (sareng langkung fleksibel) ngabagi hak aksés kana klaster disebut basa sunda (Kontrol aksés dumasar peran). Eta geus dinyatakeun stabil saprak versi Kubernet 1.8. RBAC nerapkeun modél hak dimana sagala hal anu henteu diidinan sacara eksplisit dilarang.
Pikeun ngaktipkeun RBAC, Anjeun kudu ngamimitian Kubernetes api-server jeung parameter --authorization-mode=RBAC. Parameter disetél dina manifest kalayan konfigurasi api-server, anu sacara standar aya di sapanjang jalur /etc/kubernetes/manifests/kube-apiserver.yaml, dina bagian command. Nanging, RBAC parantos diaktipkeun sacara standar, janten kamungkinan anjeun henteu kedah hariwang ngeunaan éta: anjeun tiasa pariksa ieu ku nilai authorization-mode (dina anu parantos disebatkeun kube-apiserver.yaml). Ku jalan kitu, diantara harti na meureun aya tipe séjén otorisasina (node, webhook, always allow), tapi urang bakal ninggalkeun tinimbangan maranéhanana di luar lingkup materi.

Ku jalan kitu, kami geus diterbitkeun tulisan kalayan katerangan anu cukup rinci ngeunaan prinsip sareng fitur gawé bareng RBAC, janten salajengna kuring bakal ngawatesan diri kana daptar ringkes dasar sareng conto.

Éntitas API di handap ieu dipaké pikeun ngadalikeun aksés di Kubernetes via RBAC:

• Role и ClusterRole - kalungguhan anu ngagambarkeun hak aksés:
• Role ngidinan Anjeun pikeun ngajelaskeun hak dina spasi ngaran;
• ClusterRole - dina kluster, kaasup kana objék husus kluster sapertos titik, url non-sumberdaya (nyaéta henteu aya hubunganana sareng sumber Kubernetes - contona, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - dipaké pikeun ngariung Role и ClusterRole ka pamaké, grup pamaké atawa ServiceAccount.

Peran jeung RoleBinding éntitas diwatesan ku namespace, i.e. kedah aya dina rohangan ngaran anu sami. Nanging, RoleBinding tiasa ngarujuk kana ClusterRole, anu ngamungkinkeun anjeun nyiptakeun sakumpulan idin umum sareng ngontrol aksés ngagunakeunana.

Peran ngajelaskeun hak ngagunakeun set aturan anu ngandung:

• Grup API - tingali dokuméntasi resmi ku apiGroups jeung output kubectl api-resources;
• sumberdaya (sumberdaya: pod, namespace, deployment teras salajengna.);
• Kecap pagawéan (kecap gawe: set, update teras salajengna.).
• ngaran sumberdaya (resourceNames) - pikeun kasus nalika anjeun kedah nyayogikeun aksés kana sumber daya khusus, sareng henteu ka sadaya sumber tina jinis ieu.

Analisis otorisasi anu langkung rinci dina Kubernetes tiasa dipendakan dina halaman dokuméntasi resmi. Gantina (atawa rada, salian ieu), abdi bakal masihan conto nu ngagambarkeun karya nya.

Conto éntitas RBAC

Basajan Role, anu ngamungkinkeun anjeun kéngingkeun daptar sareng status pod sareng ngawas aranjeunna dina rohangan ngaran 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"]

conto ClusterRole, anu ngamungkinkeun anjeun kéngingkeun daptar sareng status pod sareng ngawas aranjeunna sapanjang kluster:

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

conto RoleBinding, nu ngidinan pamaké mynewuser "baca" pods dina namespace 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

Audit acara

Sacara skéma, arsitéktur Kubernetes bisa digambarkeun saperti kieu:

Komponén konci Kubernetes jawab requests processing nyaeta api-server. Sadaya operasi dina kluster ngaliwat éta. Anjeun tiasa maca langkung seueur ngeunaan mékanisme internal ieu dina tulisan "Naon anu lumangsung dina Kubernetes nalika anjeun ngajalankeun kubectl run?".

Auditing sistem mangrupikeun fitur anu pikaresepeun dina Kubernetes, anu ditumpurkeun sacara standar. Éta ngamungkinkeun anjeun log sadaya telepon ka API Kubernetes. Sakumaha anjeun tiasa nebak, sadaya tindakan anu aya hubunganana sareng ngawaskeun sareng ngarobih kaayaan klaster dilaksanakeun ngalangkungan API ieu. Katerangan anu hadé ngeunaan kamampuanna tiasa (sapertos biasa) dipendakan dina dokuméntasi resmi K8s. Salajengna, abdi bakal nyobian nampilkeun topik dina basa basajan.

Ku kituna, pikeun ngaktipkeun auditing, urang kudu lulus tilu parameter diperlukeun kana wadahna di api-server, nu dijelaskeun dina leuwih jéntré di handap:

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

Salian tilu parameter ieu diperlukeun, aya loba setelan tambahan patali auditing: ti rotasi log nepi ka déskripsi webhook. Conto parameter rotasi log:

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

Tapi kami moal ngémutan aranjeunna langkung rinci - anjeun tiasa mendakan sadaya detil dokuméntasi kube-apiserver.

Sakumaha anu parantos disebatkeun, sadaya parameter disetél dina manifest kalayan konfigurasi api-server (sacara standar /etc/kubernetes/manifests/kube-apiserver.yaml), dina bagian command. Hayu urang balik deui ka 3 parameter anu diperyogikeun sareng analisa aranjeunna:

1. audit-policy-file - jalur ka file YAML ngajéntrékeun kawijakan Inok. Urang bakal balik deui ka eusina engké, tapi pikeun ayeuna kuring bakal dicatet yén file kudu bisa dibaca ku prosés api-server. Ku alatan éta, perlu dipasang di jero wadahna, nu Anjeun bisa nambah kodeu handap kana bagian luyu tina config nu:

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

2. audit-log-path - jalur ka file log. Jalurna ogé kedah tiasa diaksés ku prosés api-server, ku kituna kami ngajelaskeun pamasanganna ku cara anu sami:

     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 - format log audit. standar nyaéta json, tapi format téks warisan ogé sayogi (legacy).

Kabijakan Audit

Ayeuna ngeunaan file anu disebatkeun ngajelaskeun kawijakan logging. Konsep kahiji kawijakan audit nyaéta level, tingkat logging. Aranjeunna kieu:

• None - ulah asup;
• Metadata - métadata pamundut log: pamaké, waktos pamundut, sumberdaya target (pod, namespace, jsb), tipe Peta (verba), jsb;
• Request - log metadata sareng badan pamundut;
• RequestResponse - metadata log, badan pamundut sareng badan réspon.

Dua tingkatan terakhir (Request и RequestResponse) ulah asup log requests nu teu ngakses sumberdaya (aksés ka disebut non-sumberdaya url).

Ogé sagala requests ngaliwatan sababaraha tahapan:

• RequestReceived - tahap nalika pamundut ditampi ku prosesor sareng henteu acan dikirimkeun langkung jauh sapanjang ranté prosesor;
• ResponseStarted - headers respon dikirim, tapi saméméh awak respon dikirim. Dihasilkeun pikeun patarosan anu panjang (contona, watch);
• ResponseComplete - badan réspon parantos dikirim, teu aya inpormasi anu langkung seueur anu bakal dikirim;
• Panic - kajadian anu dihasilkeun nalika kaayaan abnormal dideteksi.

Pikeun ngalangkungan léngkah-léngkah anu anjeun tiasa dianggo omitStages.

Dina file kawijakan, urang tiasa ngajelaskeun sababaraha bagian kalayan tingkat logging anu béda. Aturan cocog munggaran kapanggih dina pedaran kawijakan bakal dilarapkeun.

Daemon kubelet ngawas parobahan dina manifes ku konfigurasi api-server sareng, upami aya anu dideteksi, balikan deui wadahna nganggo api-server. Tapi aya hiji rinci penting: parobahan dina file kawijakan bakal dipaliré ku eta. Saatos ngadamel parobihan kana file kawijakan, anjeun kedah ngabalikan deui api-server sacara manual. Kusabab api-server dimimitian salaku pod statik, tim kubectl delete moal ngabalukarkeun eta balikan deui. Anjeun kedah ngalakukeunana sacara manual docker stop on kube-masters, dimana kawijakan audit geus robah:

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

Nalika ngaktipkeun auditing, hal anu penting pikeun nginget éta beban dina kube-apiserver naek. Khususna, konsumsi mémori pikeun neundeun kontéks paménta ningkat. Logging dimimitian ngan sanggeus lulugu respon dikirim. Beban ogé gumantung kana konfigurasi kawijakan Inok.

Conto kawijakan

Hayu urang tingali struktur file kawijakan nganggo conto.

Ieu file basajan policypikeun log sadayana dina tingkat Metadata:

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

Dina kawijakan anjeun tiasa netepkeun daptar pangguna (Users и ServiceAccounts) jeung grup pamaké. Contona, ieu kumaha urang bakal malire pamaké sistem, tapi log sagalana sejenna dina tingkat nu 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

Éta ogé mungkin pikeun ngajelaskeun target:

• spasi ngaran (namespaces);
• Kecap pagawéan (kecap gawe: get, update, delete jeung sajabana);
• sumberdaya (sumberdaya, nyaéta: pod, configmaps jeung sajabana) jeung grup sumberdaya (apiGroups).

Nengetan! Sumberdaya sareng grup sumberdaya (grup API, nyaéta apiGroups), sareng versi na dipasang dina kluster, tiasa didapet nganggo paréntah:

kubectl api-resources
kubectl api-versions

Kabijakan audit di handap ieu disayogikeun salaku demonstrasi prakték pangsaéna dina Dokuméntasi 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

conto sejen alus kawijakan Inok nyaeta profil dipaké dina GCE.

Pikeun gancang ngabales acara Inok, mungkin ngajelaskeun webhook. masalah ieu katutupan di dokuméntasi resmi, Kuring bakal ninggalkeun eta di luar ruang lingkup artikel ieu.

hasil

Tulisan éta nyayogikeun tinjauan mékanisme kaamanan dasar dina klaster Kubernetes, anu ngamungkinkeun anjeun nyiptakeun akun pangguna anu dipersonalisasi, misahkeun hakna, sareng ngarékam tindakanna. Muga-muga aya mangpaatna pikeun anu disanghareupan ku pasualan-pasualan sapertos kitu dina teori atanapi prakna. Kuring ogé nyarankeun yén anjeun maca daptar bahan séjén dina topik kaamanan di Kubernetes, anu dirumuskeun dina "PS" - meureun diantara aranjeunna anjeun bakal manggihan rinci diperlukeun dina masalah anu relevan pikeun anjeun.

PS

Baca ogé dina blog urang:

• «33+ alat kaamanan Kubernetes";
• «Perkenalan kana Kabijakan Jaringan Kubernetes pikeun Profesional Kaamanan";
• «Ngartos RBAC di Kubernetes";
• «9 Prakték Pangalusna pikeun Kaamanan Kubernetes";
• «11 Cara pikeun (Henteu) Janten Korban Hack Kubernetes".

sumber: www.habr.com