Elasticsearch hitelesítés és jogosultság kezelés

Elasticsearch 7.1 verzióval kapcsolatos a leírásom, melyben megpróbálom bemutatni egy ingyenesen használható, alapszintű hozzáférési rendszer beállítását.

Az elasticsearch alapból nem ad hitelesítéssel és jogosultsággal kapcsolatos funkciókat. Ezeket az X-Pack nevű modul biztosítja, amelynek használata első olvasatra fizetős.

Második olvasatra viszont észre vehetjük, hogy ha nem igényeljük az X-Pack teljes fegyvertárát, akkor a Basic verzióként (ami még szintén ingyenes) használhatunk alapfokú hitelesítési és jogosultságkezelő funkciókat. Jól látható, hogy az RBAC (Role-based access control), illetve a file és native realm típusú hitelesítés érhető el számunkra:

Első lépések

A telepítésről itt tudsz bővebben olvasni: Elasticsearch telepítése Arch Linuxon. Miután telepítetted a megfelelő verziót és megejtetted az első beállítások (cluster, node, network), először érdemes beállítani a beépített felhasználók jelszavát. Jelen állapotban ugyanis szabad a vásár, az csatlakozik az adatbázishoz aki akar. A jelszavak beállítása után ezt már nem lehet megtenni. A beépített felhasználók listája:

• apm_system
• kibana
• logstash_system
• beats_system
• remote_monitoring_user
• elastic

A jelszavak beállítását egy parancssoros programmal tudjuk megtenni:

#elasticsearch-setup-password auto

Használható az interactive opció is az auto helyett, de túl sok jelszót kell bepötyögni, érdemes az auto-t használnod. A felhasználókat és a generált jelszavakat kiírja a konzolra, ezeket érdemes elmenteni. Ezek után ha csatlakozni akarsz a REST API-hoz, az elastic felhasználót és annak jelszavát kell használnod (amíg nincsenek más felhasználóid).

Konfiguráció

Ahogy korábban is beszéltük, a sokfajta hitelesítési megoldás közül a file és a native realm áll ingyenesen a rendelkezésünkre. Mindegy, hogy melyiket választod, azt előtte engedélyezned kell.

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack:
  security:
    authc:
      realms:
        file:
          file1:
            order: 1
            enabled: false
        native:
          native1:
            order: 0

Először is engedélyezned kell az X-Pack security-t. Ez a beállítás megköveteli a transport csatorna SSL beállítását, tehát ezt is beállítjuk. Ezután beállíthatod a file vagy native realm-t. Akár mindkettőt is használhatod egyszerre, lényeg, hogy az order tulajdonságuk is beállításra kerüljön, amivel a hitelesítési sorrendet határozzuk meg. Jelen példában sorrendben első a native, majd a file, bár a fenti példában a file realm kikapcsolásra került (enabled: false).

Native realm

A dokumentácó szerint a legkönnyebb hitelesítési lehetőséget a native realm adja (persze annak, akinek a REST API használata nem gond). A native realm által kezelt felhasználói adatok a clusterre egészére vonatkoznak, így nem konfigurációs fájl, hanem REST API segítségével lehet menedzselni a felhasználókat, jogosultságokat és jelszavakat. Ezeket az adatokat a _security index alatt tárolja a rendszer, ami természetesen a cluster összes node-ján megtalálható lesz.

Mivel korábban már beállítottuk a beépített felhasználók jelszavát, a REST API használatához loginolni kell. Az elastic nevű felhasználó megfelelő lesz hozzá.

curl -u elastic -X POST "127.0.0.1:9200/_security/user/username" -H 'Content-Type: application/json' -d'
{
  "password" : "password",
  "roles" : [ "superadmin"],
  "full_name" : "User Name",
  "email" : "username@example.com",
  "metadata" : {
    "intelligence" : 7
  }
}
'

A parancs futtatásakor a curl bekéri az elastic user jelszavát, de ha megadható előre a -u elastic@password formátummal is. Ha minden rendben, az alábbi választ kapod vissza:

{
    "created": true
}

Ezek után tudod lekérdezni a felhasználó adatait:

curl -u username -X GET "127.0.0.1:9200/_security/_authenticate"

És a válasz:

{
  "username": "username",
  "roles": [
    "superadmin"
  ],
  "full_name": "User Name",
  "email": "username@example.com",
  "metadata": {
    "intelligence": 7
  },
  "enabled": true,
  "authentication_realm": {
    "name": "native1",
    "type": "native"
  },
  "lookup_realm": {
    "name": "native1",
    "type": "native"
  }
}

File realm

A file realm segítségével a felhasználókat és jogait konfigurációs fájlból olvassa ki az adatbázis. Mivel ez a módszer fájl alapon működik, a konfigurációs fájlokat a cluster mindegyik node-jára át kell másolni. A használható fájlok:

• role_mapping.yml
• roles.yml
• users
• users_roles

A role_mapping.yml fájlt most nem érintjük. A roles.yml tárolja az általunk létrehozott egyedi role szabályokat, az users tárolja a felhasználókat és azok hash jelszavait, az users_roles pedig a felhasználók és role-ok kapcsolásait. Egy felhasználóhoz akár több role is társítható, ezek soronként kerülnek be az users_role fájlba.

Nem kell a fájlokat magunknak szerkesztenünk, kapunk hozzá parancssoros programot: elasticsearch-users. Használata faék egyszerű:

#felhasznalok listazasa
elasticsearch-users list

#felhasznalo letrehozasa
elasticsearch-users useradd username

#role beallitasa
elasticsearch-users roles username -a superadmin

#role torlese
elasticsearch-users roles username -r superadmin

#felhasznalo torlese
elasticsearch-users userdel username 

#jelszo csere
elasticsearch-users passwd username

Role rendszer – RBAC

A szerver mindegyik felhasználóhoz társít egy alapértelmezett role-t. Ez a role engedélyezi a felhasználóknak az authentication végpont elérését, jelszavuk cseréjét és információ kérését saját magukról.

Ezen felül van pár beépített role a rendszerben, amelyek közül majdnem bármelyiket hozzáköthetjük bármelyik felhasználóhoz. Ezek a role-ok rögzített jogosultságokkal rendelkeznek és nem módosíthatóak. Van olyan role, amit nem lehet felhasználóhoz társítani.

• apm_system
  Biztosítja az APM rendszer felhasználójának szükséges hozzáférést ahhoz, hogy rendszer szintű adatokat (például monitoring) küldjön az Elasticsearch-nek.
• apm_user
  Biztosítja az APM-felhasználók számára szükséges jogosultságokat (például az apm-* és .ml-anomalies* indexek olvasási és view_index_metadata jogosultságait).
• beats_admin
  Hozzáférést biztosít a .management-beats indexhez, amely a Beats konfigurációs adatait tartalmazza.
• beats_system
  A Beats rendszer felhasználójának hozzáférést biztosít a rendszer szintű adatok (például megfigyelés) elküldéséhez az Elasticsearch-nek.
• ingest_admin
  Hozzáférést biztosít az összes index sablon és az összes ingest pipeline konfiguráció kezeléséhez.
• kibana_dashboard_only_user
  Hozzáférést biztosít a Kibana Dashboardhoz, és csak olvasási engedélyeket biztosít a Kibana számára. Ez a role nem fér hozzá a Kibana szerkesztési eszközeihez.
• kibana_system
  A Kibana rendszer felhasználójának szükséges hozzáférést biztosít a Kibana indexek olvasásához és írásához, index sablonok és tokenek kezeléséhez, valamint az Elasticsearch fürt elérhetőségének ellenőrzéséhez. Ez a szerep biztosítja a read hozzáférést a .monitoring-* indexekhez, valamint az olvasási és írási hozzáférést a .reporting-* indexekhez.
• kibana_user
  Kibana minden funkciójának elérése.
• logstash_admin
  Hozzáférést biztosít a .logstash* indexekhez a konfigurációk kezeléséhez.
• logstash_system
  Biztosítja a Logstash rendszer felhasználójának szükséges hozzáférést ahhoz, hogy rendszer szintű adatokat (például monitoring) küldjön az Elasticsearch-nek.
• machine_learning_admin
  Biztosítja a manage_ml cluster jogosultságokat, ezenkívül olvasási elérést az .ml-anomalies*, .ml-notifications*, .ml-state *, .ml-meta* indexekhez és írási jogosultságot az .ml-annotations* indexekhez.
• machine_learning_user
  Biztosítja a gépi tanulás konfigurációjának, állapotának és eredményeinek megtekintéséhez szükséges minimális jogosultságokat. Ez a szerepkör biztosítja a monitor_ml cluster jogosultságait, olvasási hozzáférést az .ml-notifications és a .ml-anomalies* indexekhez (amelyek a gépi tanulási eredményeket tárolják), és írási hozzáférést az .ml-annotations* indexekhez.
• monitoring_user
  Biztosítja az X-Pack monitoring használatához szükséges minimális jogosultságokat, kivéve a Kibana használatához szükséges jogosultságokat. Ez a szerepkör lehetővé teszi a monitoring indexekhez való hozzáférést és az alapvető cluster információk olvasásához szükséges jogosultságokat. A monitoring_users felhasználókhoz a kibana_user role-t is hozzá kell rendelni.
• remote_monitoring_agent
  Biztosítja a minimális jogosultságokat az adatok monitoring indexekbe történő írásához (.monitoring-*). Ez a szerepkör a Metricbeat indexek (metricbeat- *) létrehozásához és a hozzájuk tartozó adatok írásához szükséges jogosultságokkal is rendelkezik.
• remote_monitoring_collector
  Biztosítja azokat a minimális jogosultságokat, amelyek az Elastic Stack monitoring adatainak gyűjtéséhez szükségesek.
• reporting_user
  Biztosítja az X-Pack felhasználóknak a riport jogosultságot, kivéve a Kibana használatához szükséges más jogosultságokat. Ez a szerepkör hozzáférést biztosít a report indexekhez; de mindegyik felhasználó csak saját jelentéseihez férhet hozzá. A riport felhasználókhoz hozzá kell rendelni a kibana_user szerepkört és egy olyan szerepkört, amely hozzáférést biztosít számukra a jelentések létrehozásához használt adatokhoz.
• snapshot_user
  Biztosítja a szükséges jogosultságokat az összes index pillanatfelvételének létrehozásához és a meta adatok megtekintéséhez. Ez a szerepkör lehetővé teszi a felhasználók számára, hogy megtekinthessék a meglévő pillanatfelvétel-tárolók és pillanatfelvételek részleteit. Nem engedélyezi a tárolók eltávolítását vagy hozzáadását, illetve a pillanatképek visszaállítását. Nem teszi lehetővé az index beállítások módosítását vagy az index adatok olvasását vagy frissítését.
• superuser
  Teljes hozzáférést biztosít a cluster-hez, beleértve az összes indexet és adatot. A felhasználók, akiknek a superadmin szerepe van, a felhasználókat és szerepköröket is kezelheti, és bármilyen más felhasználót is megszemélyesíthet a rendszerben.
• transport_client
  Biztosítja a Java Transport Client által a cluster eléréséhez szükséges jogosultságokat. A Java Transport Client a cluster csomópontjairól információkat gyűjt a Node Liveness API és a Cluster State API használatával.
• watcher_admin
  Olvasási hozzáférést biztosít a .watches indexhez, olvasási hozzáférést a watch history-hoz a triggered watch indexekhez és lehetővé teszi az összes watch action végrehajtását.
• watcher_user
  Biztosítja az olvasási hozzáférést a .watches indexhez, és szintén biztosítja a get watch action és a watcher statisztikát.

Az összes beépített role közül a superadmin a legérdekesebb. Ez a role teljes hozzáférést biztosít mindenhez, így csínján kell vele bánni.

Egyedi role

Saját role-ok is létrehozhatóak. Egy role-ban pár tulajdonságot szabályozni kell:

• applications
  Lista, amely az alkalmazások jogosultsági listáját tartalmazza. A lista elem tartalmazza: application, privileges, resources. Nem kötelező mező.
• cluster
  A cluster jogosultságok listája. Ezek a jogosultságok határozzák meg azokat a cluster-szintű műveleteket, amelyeket az ilyen szerepkörrel rendelkező felhasználók képesek végrehajtani. Nem kötelező mező.
• global
  A globális jogosultságokat meghatározó objektum. A globális jogosultság a cluster jogosultságának formája, amely kérés-érzékeny. A szabványos cluster jogosultság kizárólag a végrehajtott cselekvésen alapuló engedélyezési döntéseket hoz. A globális jogosultság figyelembe veszi a kérelemben szereplő paramétereket is. A globális jogosultságok támogatása jelenleg az alkalmazásjogosultságok kezelésére korlátozódik. Ez a mező nem kötelező.
• indices
  Az indexek hozzáférési listája. A lista elem tartalmazza: field_security, names, privileges, query. Nem kötelező mező.
• metadata
  Objektum, amely opcionális metaadatokat tartalmazhat. A metaadat objektumon belül az _ használatával kezdődő kulcsok a rendszerhasználat számára vannak fenntartva.
• run_as
  Azoknak a felhasználóknak a listája, akik az ezt tulajdonoló felhasználókat megszemélyesíthetik.

role

{
  "run_as": [ ... ], 
  "cluster": [ ... ], 
  "global": { ... }, 
  "indices": [ ... ], 
  "applications": [ ... ] 
}

indices

{
  "names": [ … ],
  "privileges": [ … ],
  "field_security" : { … },
  "query": "…"
}

• names
  Az indexek (vagy indexnevek) listája, amelyekre az ebben a bejegyzésben szereplő jogosultságok érvényesek.
• privileges
  Indexszintű jogosultság a kapcsolódó indexeken (azok az indexek, amelyek a name mezőben vannak megadva)
• field_security
  A dokumentum mezők leírása amelyhez a felhasználók olvasási hozzáféréssel rendelkeznek
• query
  Egy olyan keresési lekérdezés, amely meghatározza az elérhető dokumentumok olvasási jogát. A társított indexeken belüli dokumentumnak meg kell egyeznie ezzel a lekérdezéssel annak érdekében, hogy a szereplők számára hozzáférhető legyen.

global

{
  "application": {
    "manage": {    
        "applications": [ ... ] 
    }
  }
}

• manage
  Az egyetlen támogatott globális jogosultság az alkalmazások jogosultságainak kezeléséhez
• applications
  A kezelendő alkalmazások neveinek listája. Ez a lista támogatja a helyettesítő karaktereket (pl. “myapp-*”) és a reguláris kifejezéseket (pl. “/ app[0-9]*/”)

application

{
  "application": "my_app", 
  "privileges": [ ... ],   
  "resources": [ ... ]     
}

• application
  Alkalmazás neve.
• privileges
  Az alkalmazáshoz tartozó jogosultságok neveinek listája.
• resources
  Azok az erőforrások, amelyekre e kiváltságok érvényesek. Ezeket ugyanúgy kezelik, mint az indexnév minta az indices jogosultságban. Ezeknek az erőforrásoknak nincs különösebb jelentősége az Elasticsearch biztonsági jellemzőihez.

Egy teljes példa

{
  "cluster": ["all"],
  "indices": [
    {
      "names": [ "index1", "index2" ],
      "privileges": ["all"],
      "field_security" : { // optional
        "grant" : [ "title", "body" ]
      },
      "query": "{\"match\": {\"title\": \"foo\"}}" // optional
    }
  ],
  "applications": [
    {
      "application": "myapp",
      "privileges": [ "admin", "read" ],
      "resources": [ "*" ]
    }
  ],
  "run_as": [ "other_user" ], // optional
  "metadata" : { // optional
    "version" : 1
  }
}

A role-okat természetesen REST API-n keresztül a legkönnyebb menedzselni, amihez a felhasználónak szüksége van a manage_security cluster jogosultságra.

Egy role létrehozása:

curl -u username -X POST "127.0.0.1:9200/_security/role/clicks_admin" -H 'Content-Type: application/json' -d'
{
  "run_as": [ "clicks_watcher_1" ],
  "cluster": [ "monitor" ],
  "indices": [
    {
      "names": [ "events-*" ],
      "privileges": [ "read" ],
      "field_security" : {
        "grant" : [ "category", "@timestamp", "message" ]
      },
      "query": "{\"match\": {\"category\": \"click\"}}"
    }
  ]
}
'

A válasz:

{
  "role": {
    "created": true 
  }
}

A fenti definíció alapján a clicks_admin szerepkörrel rendelkező felhasználó:

• megszemélyesítheti a clicks_watcher_1 felhasználót és kéréseket hajthat végre a nevében
• monitorozhatja az Elasticsearch cluster-t
• olvashatja az összes events- kezdetű indexből származó adatokat
•  ezeken az indexeken belül csak a click kategóriájú events olvashatja el
•  ezeken a dokumentumon belül csak a category-, @timestamp- és message mezők olvashatók.

Fájl alapú role-ok

A fájl alapú role-ok esetében egy role definicióját a roles.yml fájlban hozzuk létre:

click_admins:
  run_as: [ 'clicks_watcher_1' ]
  cluster: [ 'monitor' ]
  indices:
    - names: [ 'events-*' ]
      privileges: [ 'read' ]
      field_security:
        grant: ['category', '@timestamp', 'message' ]
      query: '{"match": {"category": "click"}}'

Az Elasticsearch folyamatosan monitorozza a roles.yml fájlt, és automatikusan alkalmazza a változásokat.

A users_roles fájlban társítjuka felhasználót és a role-t. Egy sorban egy társítás:

superuser:user1
click_admins:user2

Ne felejtsd el, hogy a file realm (azaz a fájl alapú felhasználó és role kezelés) node alapú. Ha több node-ból áll a clustered, akkor a cluster összes node-jára el kell juttatnod a fájlokat, illetve az esetleges változtatásokat.