Belajar Elasticsearch - Security Fundamentals - Authentication & Authorization

#Pendahuluan

Cluster yang tidak diamankan adalah server tanpa kunci: siapa pun yang bisa menjangkau port 9200 bisa membaca, mengubah, bahkan menghapus semua data. Sejak Elasticsearch 8.0, security aktif secara default. Episode 15 membahas dua pilar keamanan — authentication (verifikasi identitas) dan authorization (apa yang boleh dilakukan): aktivasi security, built-in users dan realms, manajemen user dan role, metode autentikasi, serta RBAC dengan DLS/FLS dan role mapping.

#Mengaktifkan Security

Security diaktifkan di elasticsearch.yml. Di 8.x, instalasi fresh sudah mengaktifkannya otomatis dan mencetak password superuser elastic. Untuk memastikan atau mengaktifkan manual:

xpack.security.enabled: true
xpack.security.enrollment.enabled: true
xpack.security.transport.ssl.enabled: true

Jika security belum pernah diaktifkan, atur password untuk built-in users setelah start:

bin/elasticsearch-setup-passwords auto

Jangan lupa menyalakan ulang Kibana setelah mengaktifkan security, lalu login memakai user elastic dan password yang baru dibuat.

#Built-in Users dan Realms

Elasticsearch datang dengan built-in users yang masing-masing punya peran khusus:

User-user ini memakai realm (sumber otentikasi): file realm menyimpan user di file lokal, native realm di internal index, dan ldap/active_directory/saml/oidc terhubung ke sistem eksternal. Urutan realm menentukan prioritas autentikasi — user di native realm paling umum untuk kebutuhan sehari-hari.

#User dan Role Management

Membuat user dan role dilakukan lewat Security API:

POST /_security/user/arman
{
  "password": "StrongPass2026!",
  "roles": ["kibana_admin", "viewer"],
  "full_name": "Arman Dwi Pangestu",
  "email": "arman@example.com"
}

Cek detail user dengan GET /_security/user/arman. User boleh memiliki banyak role; role yang berbeda dijumlahkan izinnya. Jangan pernah memberi role superuser ke user aplikasi — berikan hak seminimal mungkin (least privilege).

#Metode Autentikasi

#Native Realm (Internal Users)

#LDAP / Active Directory

Untuk organisasi yang sudah punya directory server, integrasi AD/LDAP membuat user perusahaan bisa langsung login tanpa user duplikat:

xpack.security.authc.realms.active_directory.my_ad:
  order: 2
  domain_name: corp.example.com
  url: ldap://dc1.corp.example.com
  bind_dn: cn=service-account,dc=corp,dc=example,dc=com

#SAML dan OIDC

Untuk single sign-on berbasis browser (portal perusahaan), SAML dan OpenID Connect menghubungkan Elasticsearch/Kibana dengan IdP seperti Okta, Azure AD, atau Keycloak. Cocok untuk akses UI; API keys tetap menjadi pilihan utama untuk aplikasi.

#API Keys

Untuk akses aplikasi, API keys adalah standar emas — kredensial yang bisa dibuat per-aplikasi, dicabut tanpa menghapus user, dan dibatasi izinnya:

POST /_security/api_key
{
  "name": "search-app-key",
  "role_descriptors": {
    "search_only": {
      "indices": [
        { "names": ["produk*"], "privileges": ["read", "view_index_metadata"] }
      ]
    }
  }
}

Responsnya mengembalikan api_key (nilai rahasia) yang dipakai aplikasi sebagai header Authorization: ApiKey <encoded>. Jika key bocor, cabut dengan DELETE /_security/api_key.

#Service Tokens

Untuk service yang berjalan terus-menerus (seperti Beats atau agent), service accounts menyediakan token yang lebih mudah dirotasi: POST /_security/service/{namespace}/{service}/credential/token.

#Authorization dan RBAC

#Membuat Custom Role

PUT /_security/role/log_viewer
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["logs-*"],
      "privileges": ["read", "view_index_metadata"]
    }
  ]
}

Index privileges mengontrol akses per index (read, write, delete, manage, dll); cluster privileges mengontrol akses tingkat cluster (monitor, manage, manage_ilm, dll).

#Document dan Field Level Security

Document Level Security (DLS) membatasi dokumen mana yang bisa dilihat — misalnya user support hanya melihat log divisinya sendiri; Field Level Security (FLS) menyembunyikan field tertentu seperti password atau token:

{
  "indices": [
    {
      "names": ["produk"],
      "privileges": ["read"],
      "query": { "term": { "owner.keyword": "support-team" } },
      "field_security": { "grant": ["name", "price", "category"], "except": ["internal_note"] }
    }
  ]
}

#Role Mapping

Role mapping menghubungkan identitas eksternal (grup LDAP/AD atau atribut SAML) ke role Elasticsearch:

PUT /_security/role_mapping/log_admin
{
  "roles": ["log_viewer", "kibana_admin"],
  "rules": {
    "field": {
      "groups": "cn=devops,ou=Groups,dc=corp,dc=example,dc=com"
    }
  }
}

Dengan role mapping, manajemen akses mengikuti struktur organisasi — anggota grup DevOps otomatis punya akses yang sama, dan rotasi keanggotaan dikelola di AD, bukan di Elasticsearch.

#Penutup

Di episode 15 kalian menguasai security fundamentals: aktivasi xpack.security, built-in users dan realms, manajemen user dan role, metode autentikasi (native, LDAP/AD, SAML, API keys, service tokens), serta authorization dengan custom roles, index/cluster privileges, DLS/FLS, dan role mapping.

Inti yang harus dibawa pulang:

• Security aktif default di 8.x — user elastic adalah superuser, simpan aman.
• Realm adalah sumber autentikasi; AD/LDAP untuk manusia, API keys untuk aplikasi.
• API keys memberi hak terbatas dan bisa dicabut tanpa menghapus user.
• RBAC memakai index privileges dan cluster privileges.
• DLS/FLS membatasi dokumen dan field yang terlihat — sesuai least privilege.
• Role mapping menghubungkan grup eksternal ke role Elasticsearch.

Autentikasi dan otorisasi sudah jalan, tapi masih ada satu lapisan lagi: melindungi data saat transit dan mengamankan jaringan. Di episode 16 kita bahas network security dan encryption: TLS untuk HTTP dan transport layer, pembuatan sertifikat dan perpanjangan, bind/publish address, serta firewall dan network isolation di cloud. Sampai jumpa!