개발하는 두부

Elastic Stack 또는 ELK에 OpenDistro Security 적용하기

by 뚜부니

OpenDistro가 아닌 OpenSearch를 쓰는 게 맞지만..! OpenDistro를 Elastic Stack에 적용해 볼 일이 있어서 사용하는 김에 내용 정리했어요. 사실 오래전에 Github에 대충 정리해 놓고 이제야 올리네요.. 😂

(머쓱)

 

OpenDistro는 Elasticsearch와 Kibana를 위한 다양한 기능을 제공하고 있습니다.

그 중 주요 기능에 대해서 요약하여 설명드리겠습니다.

  1. Security : Elasticsearch와 Kibana의 보안을 강화하는 기능 제공
  2. Alerting : Elasticsearch에서 실시간으로 데이터를 감지하고 알림을 생성하는 기능 제공
  3. Anomaly Detection : Elaticsearch에서 비정상적인 데이터 패턴을 감지하여 이상 징후를 식별하는 기능 제공
  4. SQL : SQL 문을 사용하여 Elasticsearch 데이터를 쿼리하고 분석할 수 있는 기능 제공
  5. Index Management : Elasticsearch 인덱스의 생성, 스냅샷, 삭제 등을 자동으로 관리하는 기능 제공
  6. Performance : Elasticsearch의 성능을 분석하고 모니터링 하는 기능 제공
  7. KNN : K-Nearest Neighbors 알고리즘을 지원하여 Elasticsearch 데이터에 대한 유사성 검색 기능 제공

이 외에도 다양한 기능을 제공하며, 궁금하시다면 공식 문서를 참고하시길 바랍니다.

 

 

00. 실습 환경

Apache 2.0 License 내에서 사용할 수 있는 기능만 포함된 OSS 버전을 활용하여 실습하였습니다.

  • CentOS 7.9
  • Elasticsearc 7.10.2
  • Logstash 7.10.2
  • Kibana 7.10.2
  • opendistro_security 1.13.1.0
  • opendistroSecurityKibana 1.13.0.1
  • OpenSSL 1.0.2
  • Java 11

본 게시글에는 Elastic Stack 구축 방법 및 Java 11 설치에 대한 설명은 포함되어 있지 않습니다.

 

01. OpenSSL로 인증서 생성하기

tip
인증서 생성은 하나의 서버에서 진행하면 됩니다. 동일한 인증서를 가지고 있어야 하기 때문에, 하나의 서버에서 생성한 다음 다른 서버에 복사해야 합니다.

인증서 생성을 위해 OpenSSL을 설치합니다. 아래 명령어를 통해 설치한 OpenSSL은 1.0.2 버전입니다.

sudo yum install openssl

그다음 인증서를 저장할 디렉터리를 생성합니다.

sudo mkdir /etc/elasticsearch/certificates

이제 필요한 인증서를 순서대로 생성하도록 하겠습니다.

먼저 Root CA 인증서를 생성하겠습니다. 인증서를 생성할 때는 아래와 같이 개인키를 먼저 생성한 다음 인증서를 생성합니다.

# 키 생성
sudo openssl genrsa -out /etc/elasticsearch/certificates/root-ca-key.pem 2048
# 인증서 요청 (CSR) 생성
sudo openssl req -new -x509 -sha256 -key /etc/elasticsearch/certificates/root-ca-key.pem -subj "/C=KR/ST=Seoul/L=Gangnam-gu/O=monitoring/OU=monitoring/CN=root" -out /etc/elasticsearch/certificates/root-ca.pem -days 3650
  • openssl genrsa : RSA 개인키를 생성하는 명령어. root-ca-key.pem 파일에 2048 비트 길이의 RSA 개인키가 생성됨
  • openssl req : 인증서 요청(CSR, Certificates Signing Request)을 생성하는 명령어
    • -new : 새 인증서 요청을 생성함을 의미
    • -x509 : 자체 서명된 X.509 인증서를 생성함을 의미
    • -key : 개인키 파일
    • -subj : 인증서 상세 정보. (필수 X)
      • C : Country Name. 국가를 2자리 코드로 입력하며, 대문자로 표기해야 함
      • ST : State or Province Name. 시/도 입력. e.g. 서울시, 경기도
      • L : Locality Name. 구/군 입력. e.g. 강남구, 용인시
      • O : Organization Name. 회사/기관명. 개인은 이름 또는 사이트명
      • OU : Organizational Unit Name (OU). 회사/기관 내 조직
      • CN : Common Name. 인증서 고유 이름
      • E : Email Address. 이메일 (필수 X)
    • 그다음으로
    •  

관리 권한을 가진 Client 인증서인 Admin 인증서를 생성하겠습니다.

# 키 생성
sudo openssl genrsa -out /etc/elasticsearch/certificates/admin-key-temp.pem 2048
# 개인키를 PKCS8로 변환
sudo openssl pkcs8 -inform PEM -outform PEM -in /etc/elasticsearch/certificates/admin-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out /etc/elasticsearch/certificates/admin-key.pem
# 인증서 요청 (CSR) 생성
sudo openssl req -new -key /etc/elasticsearch/certificates/admin-key.pem -subj "/C=KR/ST=Seoul/L=Gangnam-gu/O=monitoring/OU=monitoring/CN=admin" -out /etc/elasticsearch/certificates/admin.csr
# 인증서 생성
sudo openssl x509 -req -in /etc/elasticsearch/certificates/admin.csr -CA /etc/elasticsearch/certificates/root-ca.pem -CAkey /etc/elasticsearch/certificates/root-ca-key.pem -CAcreateserial -sha256 -out /etc/elasticsearch/certificates/admin.pem -days 3650

openssl genrsaopenssl req에 대한 내용은 Root CA 인증서와 동일하며, 그 외 명령어에 대한 설명만 간략히 요약해 두었습니다.

  • openssl pkcs8 : 개인키를 PKCS8 형식으로 변환하는 명령어
    • -inform PEM : 입력 형식을 PEM으로 지정
    • -outform PEM : 출력 형식을 PEM으로 지정
    • -in : 기존 RSA 개인키
    • -topk8 : 개인키를 PKCS8로 변환
    • -nocypt : 개인키를 암호화하지 않도록 지정
    • -v1 PBE-SHA1-3DES :
    • -out : 변환된 개인키를 저장할 파일
  • openssl x509 : 인증서를 생성하는 명령어
    • -req : 인증서 요청 (CSR)을 입력으로 받는다는 의미
    • -in : CSR 파일
    • -CA : Root CA 인증서
    • -CAKey : Root CA 개인키
    • -CAcreateserial : 일련번호 파일을 생성하도록 지정
    • -sha256 : 해시 알고리즘 지정
    • -out : 생성된 인증서를 저장할 파일 지정
    • -days : 인증서 유효 기간. 여기서는 10년.

그리고 Elasticsearch의 각 노드에서 사용할 Node 인증서도 생성하겠습니다. node 인증서는 필요한 개수만큼 이름을 다르게 설정하여 생성하면 됩니다. 저는 node-1부터 node-5까지 5개의 인증서를 생성하였습니다.

# 키 생성
sudo openssl genrsa -out /etc/elasticsearch/certificates/node-1-key-temp.pem 2048
# 개인키를 PKCS8로 변환
sudo openssl pkcs8 -inform PEM -outform PEM -in /etc/elasticsearch/certificates/node-1-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out /etc/elasticsearch/certificates/node-1-key.pem
# 인증서 요청 (CSR) 생성
sudo openssl req -new -key /etc/elasticsearch/certificates/node-1-key.pem -subj "/C=KR/ST=Seoul/L=Gangnam-gu/O=monitoring/OU=monitoring/CN=node-1" -out /etc/elasticsearch/certificates/node-1.csr
# 인증서 생성
sudo openssl x509 -req -in /etc/elasticsearch/certificates/node-1.csr -CA /etc/elasticsearch/certificates/root-ca.pem -CAkey /etc/elasticsearch/certificates/root-ca-key.pem -CAcreateserial -sha256 -out /etc/elasticsearch/certificates/node-1.pem -days 3650

모두 정상적으로 생성되었는지 확인해 봅시다.

sudo ls /etc/elasticsearch/certificates

그러면 다음과 같이 인증서들이 생성된 것을 확인할 수 있습니다.

이제 인증서 생성이 완료되었으므로, 생성한 인증서를 Elasticsearch 다른 서버와 Kibana 서버로 복사해 주세요.

 

02. Elasticsaerch에 적용하기

OpenDistro 플러그인 설정

Elasticsearch에 OpenDistro를 설치하기 전, Elasticsearch의 모든 노드를 중지합니다.

sudo systemctl stop elasticsearch

그다음, Elasticsearch 각 서버에 OpenDistro Security 플러그인 설치합니다.

저는 Windows 10 서버에서 opensearch-project security Github에 접속하여 파일을 다운로드한 다음, 서버에 업로드하였습니다. 그다음 아래 명령어를 통해 플러그인을 설치하였습니다.

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install file:///home/monitoring/opendistro-security-1.13.1.0.zip

여기서 /usr/share/elasticsearch/bin은 일반적으로 CentOS에서 elasticsearch-plugin이 존재하는 위치이며, file:// 뒤에 있는 /home/monitoring/opendistro-security-1.13.1.0.zip은 설치하려는 OpenDistro Security 파일의 위치 및 zip 파일입니다.

명령어를 입력하면 다음 그림과 같은 문구를 확인할 수 있으며, Continue with installation? [y/N]에 대해 y를 입력하면 됩니다.

image

설치가 완료되었다면, /etc/elasticsearch/elasticsearch.yml 파일에 OpenDistro 설정을 추가합니다.
아래 내용은 node-1 서버에서 설정한 내용입니다.

opendistro_security.ssl.transport.pemcert_filepath: certificates/node-1.pem
opendistro_security.ssl.transport.pemkey_filepath: certificates/node-1-key.pem
opendistro_security.ssl.transport.pemtrustedcas_filepath: certificates/root-ca.pem
opendistro_security.ssl.transport.enforce_hostname_verification: false
opendistro_security.ssl.http.pemcert_filepath: certificates/node-1.pem
opendistro_security.ssl.http.pemkey_filepath: certificates/node-1-key.pem
opendistro_security.ssl.http.pemtrustedcas_filepath: certificates/root-ca.pem
opendistro_security.nodes_dn:
  - "CN=node-1,OU=monitoring,O=monitoring,L=Gangnam-gu,ST=Seoul,C=KR"
  - "CN=node-2,OU=monitoring,O=monitoring,L=Gangnam-gu,ST=Seoul,C=KR"
  - "CN=node-3,OU=monitoring,O=monitoring,L=Gangnam-gu,ST=Seoul,C=KR"
  - "CN=node-4,OU=monitoring,O=monitoring,L=Gangnam-gu,ST=Seoul,C=KR"
  - "CN=node-5,OU=monitoring,O=monitoring,L=Gangnam-gu,ST=Seoul,C=KR"
opendistro_security.allow_default_init_securityindex: true
opendistro_security.authcz.admin_dn:
  - "CN=admin,OU=monitoring,O=monitoring,L=Gangnam-gu,ST=Seoul,C=KR"
opendistro_security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]

설정이 완료되었으므로 Elasticsearch를 실행합니다.

sudo systemctl start elasticsearch

OpenDistro Config 설정

OpenDistro 설정 파일은 /usr/share/elasticsearch/plugins/opendistro_security/securityconfig 디렉터리에 있습니다. 디렉터리 내에는 다음과 같은 파일이 존재하며, 이를 활용하여 OpenDistro 설정을 하도록 하겠습니다. 참고로, elasticsearch.yml 내에 인증서 경로 입력 시, 모두 상대 경로로 입력해야 합니다.

  • action_groups.yml : action group이라는 권한(permission) 모음에 대한 설정 파일
  • audit.yml : 감사(audit) 로깅 설정 파일
  • config.yml : OpenDistro 사용자 자격 증명을 위한 설정 파일
  • elasticsearch.yml.example : elasticsearch 설정 예제 파일
  • internal_users.yml : internal user database에 사용자 및 해시로 변환한 비밀번호를 설정하는 파일
  • nodes_dn.yml : 통신을 하려는 노드 및 클러스터에 대한 설정 파일
  • roles_mapping.yml : 사용자, 호스트 등을 역할에 매핑하기 위한 파일
  • roles.yml : 역할 및 관련 권한에 대한 설정 파일
  • tenants.yml : 대시보드 tenant를 지정하는 파일
  • whitelist.yml : 허용된 엔드포인트 및 요청 목록 설정 파일

먼저 config.yml을 설정하겠습니다. config.yml의 기본 구조는 다음과 같습니다.

sg_config:
  dynamic:
    http:
      anonymous_auth_enable: false
      ...
    authc: ...
    authz: ...

이 중 authc 설정 중 하나인 basic_internal_auth_domain를 통해 내부 사용자 데이터베이스를 설정하겠습니다.

사실 처음 config.yml을 열면 basic_internal_auth_domain을 사용하도록 설정되어 있어 특별히 변경할 내용은 없습니다.

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern

roles.ymlroles_mapping.yml의 기본 설정을 그대로 사용하며, internal_user.yml을 통해 사용자에 대한 설정을 하도록 하겠습니다. 그전에 사용자의 비밀번호 설정을 위해 /usr/share/elasticsearch/plugins/opendistro_security/tools 디렉터리의 hash.sh를 사용하여 사용자 비밀번호를 해시로 변환하도록 하겠습니다.

tools 디렉터리로 이동한 다음 아래 명령어를 이용하여 해시로 변환합니다. 이때, <new-password>에 원하는 비밀번호를 입력해 주세요.

. hash.sh -p <new-password>

특수문자를 포함하고 싶다면 백슬래스(\)를 앞에 붙여주면 됩니다.

. hash.sh -p test\!\@

참고로, BCrypt 변환 사이트를 통해 해시를 할 수도 있습니다.

해시로 변환한 사용자 비밀번호 준비를 완료했다면, securityconfig 디렉터리로 이동하여 internal_user.yml을 설정하도록 하겠습니다.

admin:
  hash: "{password}"
  reserved: true
  backend_roles:
  - "admin"
  description: "admin user"

kibanaserver:
  hash: "{password}"
  reserved: true
  description: "kibanaserver user"

logstash:
  hash: "{password}"
  reserved: false
  backend_roles:
  - "logstash"
  description: "logstash user"

readall:
  hash: "{password}"
  reserved: false
  backend_roles:
  - "readall"
  description: "readall user"

snapshot:
  hash: "{password}"
  reserved: false
  backend_roles:
  - "snapshotrestore"
  description: "snapshotrestore user"

설정한 내용이 적용되도록 securityadmin.sh를 실행하기 위해 tools 디렉터리로 이동합니다.
그다음, securityadmin.sh를 실행할 수 있도록 권한을 변경합니다.

chmod +x securityadmin.sh

권한을 변경하였으면, securityadmin.sh를 실행하여 구성을 적용합니다.

sudo ./securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/certificates/root-ca.pem -cert /etc/elasticsearch/certificates/admin.pem -key /etc/elasticsearch/certificates/admin-key.pem
  • cacert : root PEM 파일 입력
  • cert : admin 권한을 가진 PEM 파일 입력
  • key : admin 권한을 가진 KEY 파일 입력

정상적으로 동작하는지 curl 호출을 통해 확인해 보도록 하겠습니다.

curl -k -u admin:<user_password> -X GET "localhost:9200"

#e.g.
curl -k -u admin:pass1\! -X GET "localhost:9200"

참고로, https://를 붙여 호출하면 다음과 같은 에러가 발생하기도 합니다.

curl: (35) SSL received a record that exceeded the maximum permissible length.

 

03. Kibana에 적용하기

OpenDistro Security 적용을 위해 Kibana에 플러그인 설치합니다. 저는 Windows 10 서버에서 opensearch-project security-dashboards-plugin Github에 접속하여 파일을 다운로드한 다음, 서버에 업로드하였습니다. 그다음 아래 명령어를 통해 플러그인을 설치하였습니다.

sudo /usr/share/kibana/bin/kibana-plugin install file:///home/monitoring/opendistroSecurityKibana-7.10.2.zip --allow-root

그리고 이전에 만들었던 certificateskibana.yml이 존재하는 디렉터리에 추가합니다. 파일 구조는 다음과 같습니다.

etc
├─ certificates
│ ├─ admin.key
│ ├─ admin.pem
│ ├─ root-ca.key
│ └─ root-ca.pem
├─ kibana.yml
└─ node.options

그다음, kibana.yml을 다음과 같이 수정하여 OpenDistro를 적용하도록 하겠습니다.

# kibana default setting
elasticsearch.hosts: ["http://10.0.0.1:9200", "http://10.0.0.2:9200", "http://10.0.0.3:9200", "https://10.0.0.4:9200", "http://10.0.0.5:9200"]
elasticsearch.username: "kibanaserver"
elasticsearch.password: "password"
elasticsearch.ssl.certificateAuthorities: "/etc/kibana/certificates/root-ca.pem"
elasticsearch.ssl.verificationMode: full
# opendistro security setting
elasticsearch.requestHeadersWhitelist: ["securitytenant","Authorization"]
opendistro_security.multitenancy.enabled: true
opendistro_security.multitenancy.tenants.enable_global: true
opendistro_security.multitenancy.tenants.enable_private: true
opendistro_security.multitenancy.tenants.preferred: ["Private", "Global"]
opendistro_security.multitenancy.enable_filter: false
  • elasticsearch.hosts : Elasticsearch host 입력
  • elasticsearch.username : kibana_server 권한을 가진 사용자에 대한 이름
  • elasticsearch.password : kibana_server 권한을 가진 사용자에 대한 password
  • elasticsearch.ssl.certificateAuthorities : Root CA 인증서 전체 경로 입력. 인증서 유효성 검사를 하지 않을 시, 미입력
  • elasticsearch.ssl.verificationMode: full : 인증서 유효성 검사를 하도록 full로 설정. 인증서 유효성 검사를 하지 않을 시, none으로 입력
  • elasticsearch.requestHeadersWhitelist : Elasticsearch에 전달해야 하는 모든 HTTP 헤더 입력. multi-tenancy 사용 시, "securitytenant", "Authorization" 입력 필요
  • opendistro_security.multitenancy.enabled : multi-tenancy 활성화 여부
  • opendistro_security.multitenancy.tenants.enable_global : global tenancy 활성화 여부
  • opendistro_security.multitenancy.tenants.enable_private : private tenancy 활성화 여부
  • opendistro_security.multitenancy.tenants.preferred : tenant 탭 순서 설정. default 설정은 global, private 다음부터는 알파벳 순서.
  • opendistro_security.multitenancy.enable_filter : tenant 목록 상단 검색바 추가 여부

설정을 완료하였으면, Kibana를 실행합니다.

sudo systemctl start kibana

그다음 5061 포트를 통해 접속해보면 다음과 같이 로그인 페이지가 뜨는 것을 확인할 수 있습니다.

image

만약, opendistro brand image가 표출되지 않았으면 하는 경우, 아래와 같은 설정을 추가하면 됩니다.

opendistro_security.basicauth.login.showbrandimage: false

설정을 추가한 다음 Kibana를 restart 해보면 다음과 같이 opendistro brand image가 표출되지 않는 것을 확인할 수 있습니다. 그 외에서 다른 로고를 추가한다거나 문구를 바꿀 수도 있는데, 여기서는 이러한 내용은 생략하도록 하겠습니다.

image

 

04. Logstash 설정하기

OpenDistro를 통해 생성한 사용자로 로그인을 하기 위해 먼저 이전에 만들었던 root-ca.pem/etc/logstash 디렉터리에 추가합니다. 파일 구조는 다음과 같습니다.

그 다음 logstash 설정 파일을 불러올 수 있도록 pipelines.yml을 설정합니다.

- pipeline.id: main
  path.config: "/etc/logstash/conf.d/main.conf"

그리고 main.conf를 생성하여 다음과 같이 내용을 입력합니다. input.log는 테스트를 위해 임의로 구성한 파일이며, 설정과 관련된 상세한 설명은 생략하도록 하겠습니다.

input {
  file {
    path => "/etc/logstash/test/input.log"
        start_position => "beginning"
        sincedb_path => "/dev/null"
    }
}

output {
  elasticsearch {
    hosts => ["http://10.0.0.1:9200", "http://10.0.0.2:9200", "http://10.0.0.3:9200", "http://10.0.0.4:9200", "http://10.0.0.5:9200"]
    index => "opendistrotest"
    user => "logstash"
    password => "logstash_password"
    ssl => true
    cacert => "/etc/logstash/root-ca.pem" # Elasticsearch path
  }
}

설정을 완료한 다음 logstash를 재실행합니다.

sudo systemctl restart logstash

opendistrotest 인덱스를 생성하였는지 확인하기 위해 Kibana의 DevTools에 접속하여 아래 명령어를 입력해 봅시다.

GET _cat/indices?v

명령어를 실행하면 다음과 같이 opendistro가 존재하지 않는 것을 확인할 수 있습니다.

image

어떻게 된 것인지 알아보기 위해, /var/log/logstash/logstash-plain.log를 열어보면 다음과 같은 로그를 볼 수 있습니다.

retrying failed action with response code: 403 ({"type"=>"security_exception", "reason"=>"no permissions for [indices:admin/create] and User [name=logstash, backend_roles=[logstash], requestedTenant=null]"})
Retrying individual bulk actions that failed or were rejected by the previous bulk request. {:count=>4}

권한 부족으로 발생한 에러이며, 해당 에러를 해결하기 위해 logstash 기본 설정이 어떻게 되어있는지 확인을 해봅시다. 먼저, Kibana 메뉴의 Open Distro for Elasticsearch > Security로 이동합니다. 참고로, admin 권한이 있는 사용자만 아래 내용을 확인할 수 있습니다.

image

그다음 Roles 메뉴로 이동하여 logstash를 검색하면 다음과 같은 화면을 볼 수 있습니다.

image

여기서 logstash라는 Role을 선택하여 설정을 확인해 보면, logstash-* 인덱스와 *beat* 인덱스에 대한 권한만 가지고 있는 것을 확인할 수 있습니다.

image

logstash는 기본적으로 제공하는 역할이기에 수정이 불가능합니다. 그러므로 Duplicate role을 통해 새로운 logstash 설정을 생성하도록 하겠습니다. 설정은 아래 이미지와 같이 했습니다.

image

  • Name : custom_logstash
  • Cluster permissions : 기존 설정 유지
  • Index permissions :
    • Index : 인덱스 패턴. 여기서는 모두 허용하기 위해 * 사용
    • Index permissions :
      • crud : 기존 설정
      • create_index : 기존 설정
      • indices:admin/create : 로그에 찍힌 에러 해결을 위한 권한
      • indices:data/write/bulk* : 로그에 찍힌 에러 해결을 위한 권한
      • indices:admin/mapping/put : mapping 생성을 할 수 있는 권한 추가
      • indices:data/write/index : 인덱스 작성 권한 추가

create 하고 나면 생성된 역할에 대한 화면으로 이동합니다. 여기서 Mapped users 선택하면 다음과 같은 화면을 볼 수 있습니다.

image

여기서 Manage mapping을 선택하면 뜨는 페이지의 Backend roleslogstash를 입력해 넣습니다. logstash로 Backend role을 지정한 이유는, 기존의 Backend role을 재사용하기 위해서입니다.

image

Map을 눌러 Backend role을 생성하였다면, logstash를 재실행합니다.

sudo systemctl restart logstash

그다음 Kibana의 DevTools에 접속하여 아래 명령어를 입력해 봅시다.

GET _cat/indices?v

그러면 opendistrotest 인덱스가 생성된 것을 확인할 수 있습니다.

image

이처럼 권한 문제로 인해 정상 동작하지 않는 경우, Security 메뉴에서 설정을 추가/변경하여 해결하면 됩니다.

 

05. 사용자별 다른 인덱스 접근 권한 부여하기

먼저 새로운 인덱스를 하나 더 추가하겠습니다. main.conf 내용을 아래와 같이 수정한 다음 logstash를 restart 합니다. 참고로, 현재 설정이 sincedb_path => "/dev/null"이기에 기존에 어디까지 log 파일을 읽었는지 따로 저장하지 않아 기존의 input.log 파일 내용을 처음부터 읽어오게 되어 새로운 log 파일 생성을 할 필요는 없습니다.

input {
  file {
    path => "/etc/logstash/test/input.log"
        start_position => "beginning"
        sincedb_path => "/dev/null"
    }
}

output {
  elasticsearch {
    hosts => ["http://10.0.0.1:9200", "http://10.0.0.2:9200", "http://10.0.0.3:9200", "http://10.0.0.4:9200", "http://10.0.0.5:9200"]
    index => "testindex" # 변경된 부분
    user => "logstash"
    password => "logstash_password"
    ssl => true
    cacert => "/etc/logstash/root-ca.pem" 
  }
}

opendistrotest testindex라는 두 개의 인덱스 준비를 완료하였으면, 새로운 사용자를 추가해 보도록 하겠습니다.
두 명의 사용자를 추가할 예정이며, testuser1opendistrotest 인덱스에만 접근할 수 있고, testuser2testindex에만 접근할 수 있게 생성하려고 합니다.

먼저 사용자 생성을 위해 Security > Internal users로 이동하여 Create internal user를 클릭합니다.
그러면 표출되는 사용자 생성 페이지가 표출되며, 아래와 같이 UsernamePassword를 채웁니다. 그리고 Create 버튼을 눌러 사용자를 생성합니다. testuser1 사용자와 testuser2 사용자 모두 생성해 주세요.

image

사용자 생성을 완료하면, 각 사용자가 얻을 역할에 대한 tenant를 먼저 생성하도록 하겠습니다. Security > Tenants로 이동하고 Create tenant를 클릭합니다. 그러면 tenant 생성 팝업이 표출되며, 다음과 같이 원하는 Name을 입력하면 됩니다.

image

그다음 Security > Roles로 이동하여 Create role을 클릭합니다. 그러면 역할 생성 페이지가 표출되며, Name은 원하는 대로 설정하고, Index permissions 설정과 Tenant permissions 설정은 아래와 같이 추가합니다.

image

저는 opendistro_rw를 역할 이름으로 지정하였으며, 해당 역할은 opendistro로 시작하는 인덱스에 대해 읽고 쓰기 권한을 가지고 있게 설정하였습니다.

opendistro_rw 역할이 생성되면, Mapped users에서 Manage mapping을 선택합니다. 그러면 다음과 같은 페이지가 뜨는데, 여기서 Userstestuser1을 추가합니다.

image

그러고 나서 Map을 클릭하면 testuser1opendistro_rw 역할을 가지게 됩니다.

testuser2에게 testindex를 접근할 수 있는 권한 부여도 이와 같은 방법으로 진행하면 됩니다. 저는 test_rw라는 이름으로 역할을 생성하였으며, testuser2를 연결하였습니다.

Kibana 대시보드에 testuser1 사용자로 로그인을 하면, 다음과 같이 tenant를 선택하는 화면을 볼 수 있습니다. 여기서 custom tenant를 opendistro로 선택하여 접속해 보겠습니다.

image

그다음 Kibana 메뉴의 Dashboard나 Discover로 접속하려고 할 때, 다음과 같이 index pattern을 생성하라는 문구를 보게 됩니다.

image

페이지 하단에 보면 아주 작은 글씨로 create an index pattern이 존재합니다.

image

이 문구를 클릭하면, Create index pattern 페이지로 이동하게 됩니다.

image

opendistro_rw 역할을 생성할 때 설정했던 인덱스 패턴을 동일하게 입력해 주면, 해당하는 인덱스가 어떤 것이 있는지 화면에 표시됩니다.

image

Next step >을 누르면, Time field를 설정할 수 있습니다. 원하는 대로 설정한 다음 Create index pattern을 클릭하면 인덱스 패턴이 생성됩니다.

image

다시 Kibana > Discover에 접속해 보면, 데이터가 정상적으로 표출되는 것을 확인할 수 있습니다.

image

OpenDistro를 설정하면서 가장 놀랐던 점은 Search Guard와 굉장히 유사하다는 점이었습니다. Search Guard 설정을 한 번 해보아서 그런지, OpenDistro를 설정하는 것은 Search Guard를 처음 설정할 때보다 수월하게 진행할 수 있었습니다. 아직 x-pack을 직접 적용해보지는 않았지만, 공식 문서를 가볍게 살펴보았을 때 굉장히 유사하게 설정하는 것을 확인할 수 있었습니다. 하나만이라도 설정 경험을 해보는 것은 나중에 다른 Security 플러그인을 설정할 때 많은 도움이 될 것 같습니다. 😊😊

 

참고

블로그의 정보

개발하는 두부

뚜부니

활동하기