클러스터 보안 (Security)

운영에 들어가는 Elasticsearch 클러스터라면 인증·인가·통신 암호화를 반드시 챙겨야 해요. 보안 기능은 배포 방식(Elastic Cloud 관리형 vs 자체 운영)에 따라 켜져 있거나 직접 설정해야 하는 등 차이가 있어요. 이 페이지에서 설명하는 설정은 주로 자체 운영(self-managed) 기준으로 보면 돼요.

출처: Security — Elasticsearch Guide

보안 기능 3대 축

인증(Authentication) — 누가인지 확인: 패스워드, API 키, 서비스 토큰 등.
인가(Authorization) — 무엇을 할 수 있는지 확인: 역할(role)과 권한(privilege).
암호화(Encryption) — 네트워크 통신 보호: transport·HTTP 레이어 TLS.

보안 기능은 기본적으로 elasticsearch.yml에서 켜고 끌 수 있어요.

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

transport.ssl은 노드 간 내부 통신을, http.ssl은 클라이언트와의 통신을 TLS로 감싸줘요. 인증서 생성부터는 elasticsearch-certutil 같은 도구를 쓰는 게 편해요.

사용자와 역할

내장 사용자(elastic, kibana_system, logstash_system 등)가 있고, 운영용 사용자는 역할 기반으로 만들 수 있어요. CLI로 사용자를 추가하거나, REST API로 역할을 정의해요.

elasticsearch-users useradd myuser -r superuser -p mypass

REST API로는 클러스터·인덱스 레벨 권한을 세밀하게 만드는 게 일반적이에요.

POST /_security/role/my_monitoring_role
{
  "cluster": ["monitor", "manage_slm"],
  "indices": [
    {
      "names": ["logs-*"],
      "privileges": ["read"]
    }
  ]
}

cluster: 클러스터 전역 권한(monitor, manage_* 등).
indices[].privileges: 특정 인덱스 패턴에 대한 권한(read, write, all 등).

API 키와 서비스 토큰

사용자 패스워드 대신 API 키를 발급해서 애플리케이션이 인증에 쓰는 것도 좋아요. API 키는 권한·만료를 개별 관리할 수 있고, 노출되면 곧바로 무효화할 수 있어서 안전해요. 서비스 계정용 토큰도 비슷한 방식으로 운용해요.

POST /_security/api_key
{
  "name": "my_app_key",
  "role_descriptors": {
    "read_logs": {
      "indices": [
        { "names": ["logs-*"], "privileges": ["read"] }
      ]
    }
  }
}

운영 관점 체크리스트

기본 포트를 그대로 두고 공개 네트워크에 노출하지 마세요.
자격증명을 코드·설정에 평문으로 박아 넣지 말고, 시크릿 관리로 분리하세요.
HTTPS를 통하지 않은 통신은 차단하고, 최소 권한 원칙으로 역할을 설계하세요.

클러스터 보안 (Security)