Elasticsearch 權限管理 RBAC 實戰 深度解析 Elastic Stack RBAC 權限管理機制與實作指南

什麼是 Elasticsearch RBAC 及其權限控管原則？

Elasticsearch 權限管理 核心基於 Role-Based Access Control (RBAC) 機制，旨在精確控制「誰能對哪些數據執行什麼操作」。其核心定義在於將權限封裝進「角色 (Role)」，再將角色指派給「使用者 (User)」。實踐 RBAC 實戰 的首要原則是 最小特權原則 (Least Privilege)：僅給予完成工作所需的最小權限集。透過 Kibana 介面或 Security API，管理者可以實現 多租戶安全隔離，針對不同的 Index 設定讀寫限制。這不僅保障了資料隱私，也確保了各系統元件（如 Beats, Logstash）能在使用者認證體系下安全運行。

這篇文章主要會簡介 Role-Based Access Control (RBAC)。在資安體系中，缺乏權限控管的系統如同不設防的數據金庫。Elasticsearch 提供的 RBAC 機制，讓管理者能精確定義「誰能對哪些數據做什麼」，確保資料隱私與使用者認證的嚴謹性。

RBAC 的核心哲學：最小特權原則

在實踐 Elasticsearch RBAC 時，我們必須遵循 最小特權原則 (Principle of Least Privilege)。這意味著每個使用者應僅獲得其完成工作所必須的最小權限集。

Role-Based Access Control

RBAC 機制中，每個使用者可能會得到很多不同的角色，每個角色擁有不同的層級的權限，角色可以提供選取的權限非常多種，可以參考文件中 security-privileges 的部分。

在我們把機制啟動之後，可以設置相關密碼，Elasticsearch 其實本來就有提供預設的使用者及角色，相關的設定都會存放在特定的 Index 中，主要是讓相關的服務像是 Beats、Kibana 等可以運作，所以接下來就會從預設值開始了解。

Built-in Users

Elastic Stack 在安全性方面，提供了一些內建的使用者，會存放在 .security Index 裡面，想要修改預設的密碼就可以透過這個指令 bin/elasticsearch-setup-passwords interactive 來設定，內建的使用者，看文件看說明也可以在各服務找到對應的 yml (kibana.yml)去修改。

1
2

elasticsearch.username: "kibana_system"
elasticsearch.password: "kibanapassword"

內建的使用者列表與細節如下，剛開始可先用 elastic 測試連線與功能，之後再創一個常用的使用者。

• elastic(超級使用者): 擁有存取全部 cluster 的權限，沒設定的話預設本來就會有預設密碼
• kibana_system(一般使用者): 給 Kibana 服務跟 Elasticsearch 互動用的帳號
• logstash_system(一般使用者): Logstash 存資料進 Elasticsearch 用
• beats_system(一般使用者): 給不同類型的 beat 儲存或監控 Elasticsearch
• apm_system(一般使用者): APM server 使用，儲存或監控 Elasticsearch
• remote_monitoring_user(一般使用者): 特別給 Metricbeat 使用，可以蒐集儲存相關需監控的資訊

多租戶安全隔離的實踐

在大型企業中，不同部門（如財務部與技術部）可能共用同一個 Elasticsearch 叢集。透過 Role-Based Access Control 實戰，我們可以針對不同的 Index 設定權限隔離：

• 財務人員僅擁有 finance-* 的 read 權限。
• 開發者僅擁有 app-logs-* 的 all 權限。
  這種 Index 級別權限 的劃分，是實現 多租戶安全隔離 的斷捨離——捨棄混亂的權限堆疊，回歸精確的權限定義。

Built-in Users：系統運行的基石

Elastic Stack 在安全性方面，提供了一些內建使用者（Built-in Users），它們是維持集群內部通訊運行的關鍵。例如：

• elastic: 超級使用者，負責初始配置。
• kibana_system: 專供 Kibana 服務與 Elasticsearch 互動，應避免給予真實人類使用。

Built-in Roles：快速啟動權限配置

剛開始建立使用者時，建議先從內建角色入手。這些角色已經過優化，能滿足大多數常見場景：

• kibana_dashboard_only_user: 適用於僅需查看報表的主管。
• monitoring_user: 適用於負責系統效能監控的維運人員。

剛開始創建使用者，可能發現權限很多有點難懂，也可以先使用內建的角色去進行相關安排，每個使用者都有一個預設的角色，允許去打 Auth 的 API 還有讀取或修改自己的相關資訊，像是修改密碼等等。

• apm_system: 給跟 APM 系統同等級的權限，可以傳送相關資訊
• apm_user: APM 使用者用，像是針對 apm-*、.ml-anomalies* 有 read、view_index_metadata 的權限
• beats_admin: .management-beat的控制權，進行相關 Beats 的配置
• beats_system: 能傳送系統層級的監控資訊，不適合給使用者
• data_frame_transforms_admin: 管理 transforms，包含 kibana 中機器學習模組的權限
• data_frame_transforms_user: 使用 transforms，包含 kibana 中機器學習模組的權限
• ingest_admin: 可以管理全部的 Index、Pipeline，但不包含創建
• kibana_dashboard_only_user: 只能讀取 Dashborad 用
• kibana_system: 任何足夠管理 Kibana 的相關權限 .monitoring-*、.reporting-*，不適合給使用者
• kibana_user: 可以存取所有 Kibana 功能
• logstash_admin: .logstash* 的控制權，管理相關配置
• logstash_system: Logstash system 層級的相關權限，不適合給使用者
• machine_learning_admin: 機器學習相關的控制權
• machine_learning_user: 存取機器學習相關最小的權限配置
• monitoring_user: 監控 Index 的最小權限配置
• remote_monitoring_agent: 寫資料到 .monitoring-*、metricbeat-* 中的最小權限配置
• remote_monitoring_collector: 可以蒐集 Elastic Stack 監控相關資料的最小權限配置
• reporting_user: 只能存取自己相關報告的權限
• snapshot_user: 讓使用者可以對任何 Index 做快照
• superuser: 超級使用者
• transport_client: 使用者可以看所有的 metadata、但不能讀資料
• watcher_admin: .watches 的控制權
• watcher_user: 可以存取 .watches

使用者與角色管理：從 GUI 到 API

要進行權限管理，您可以選擇 Kibana 的視覺化介面，或透過 Security API 實現自動化，有兩種方式

• Kibana GUI 中的使用者與角色設定
  • 新增 Role
  • 加入相關權限
  • 新增使用者
  • 加入相關 Role

    如下圖箭頭指的三個位置
    

• Security API: 透過寫程式打 API 進行操作，可能在只安裝 Elasticsearch 才有需要? 底下就是示範新增一個 test-user並進行相關設定，其實 Kibana GUI 理論上也是打 API 完成設置，所以有可以用就不需要再自己寫一套了?
  • Create and update users
  • Create and update roles
  • Change passwords
  • Delete users/roles
  • Disable/Enable users
  • Get users/roles

Security API 在自動化維運中的作用

在 DevOps 流程中，我們常需要透過腳本自動建立臨時的 Service Account。利用 Security API，我們能無縫整合身份管理系統（如 LDAP 或 AD），實現權限配置的自動化輪轉，大幅提升 Elastic Stack 安全性。

1
2
3
4
5
6
7

# 透過 Security API 建立測試使用者
POST /_security/user/test-service-account
{
  "password" : "secure-password-string",
  "roles" : [ "monitoring_user" ],
  "full_name" : "Automated Monitoring Agent"
}

FAQ：Elasticsearch 權限管理常見問題

Q1：為什麼建議優先使用內建角色而非自定義角色？

A：內建角色 (Built-in Roles) 是 Elastic 官方針對特定元件（如 Kibana, APM, Beats）所設計的最佳權限集合。它們會隨著系統版本的升級自動更新相關權限。除非您有非常特殊的 多租戶安全隔離 需求，否則優先使用內建角色能降低配置錯誤的風險，並確保系統功能的完整性。

Q2：如何避免 elastic 超級使用者帳號外洩的風險？

A：在 使用者認證教學 中，最佳實務是「初始配置後即禁用」。在完成所有管理員級別的 Elasticsearch 權限管理 設定後，應建立具備 superuser 角色的個人帳號，並修改 elastic 帳號的密碼後將其妥善存封。同時，應啟用 TLS 加密傳輸，防止帳密在網路中以明文傳輸。

Q3：Security API 自動化腳本如何保證安全性？

A：執行 Security API 自動化 的腳本本身不應包含明文密碼。建議結合作業系統的安全存儲機制或 HashiCorp Vault 等密鑰管理工具。此外，腳本所使用的 API Key 或帳號應遵循 最小特權原則，僅授予 manage_security 等必要權限，並在完成任務後立即撤銷臨時憑證。

結語：通往安全防禦的捷徑

掌握 Elasticsearch RBAC，不僅是為了符合資安合規性，更是為了建立一個可信任的數據環境。透過實踐 最小特權原則 與 Security API 自動化，我們能從繁瑣的手動權限維護中「斷捨離」，讓系統具備更安全防禦韌性。

• ← 上一篇
• 下一篇 →