2019년 tistory에 작성한 내용을 velog에 이전한 내용입니다.
엘라스틱서치 7.2가 업데이트 전에 시큐리티의 인증 보안 기능은 유료로 사용되었기 때문에 키바나에 접근제어를 위해서는 Nginx와 Apache의 프록시 기능을 써야만 했다.
하지만 7.2 업데이트 후 RBAC과 Native 인증 보안 기능이 무료로 풀려서 Role Base의 인증 기능을 사용할 수 있게 되었다.
라이센스 별 기능에 대한 요금제는 엘라스틱서치 홈페이지에서 찾을 수 있다.
https://www.elastic.co/kr/subscriptions
아래 글은 엘라스틱서치의 시큐리티 튜토리얼 문서를 보고 진행하였다.
우선, 엘라스틱서치, 키바나, 로그스캐시, 비트를 설치하고 구성한다.
기본적으로 유효기간이 없는 베이직 라이선스가 적용되며, 아래는 기본 라이선스를 사용한다고 가정하고 진행한다.
기본 및 트라이얼 라이선스를 사용할때 엘라스틱서치 시큐리티 기능은 기본적으로 비활성화되므로 아래 스텝을 따라하여 활성화한다.
elasticsearch.yml에 xpack.security.enabled을 추가한다.
기본 및 트라이얼 라이선으를 사용한다면 기본값은 false이다. 만약 골드 혹은 그 이상의 라이선스를 사용한다면 기본값은 true이다.
하지만 혼란을 피하기 위해서 이 설정을 정확하게 추가하는 것이 좋다.
xpack.security.enabled: true
elasticsearch.yml에 single-node discovery를 활성화한다.
이 튜토리얼은 단일 노드 클러스터를 수반하지만 만약 여러 개의 노드를 사용한다면, 클러스터안의 모든 노드의 시큐리티 기능을 활성화해야 하고, 상호간의 커뮤니케이션을 위해 이 튜토리얼 범위 밖의 내용인 TLS를 구성해야 한다.
Single-node discovery를 활성화함으로써 TLS 구성을 뒤로 미룰 수 있다.
엘라스틱서치 시큐리티 기능을 활성화할 때, Basic 인증은 기본적으로 활성화된다.
클러스터와 통신하기 위해, username과 password를 정의해야만 한다.
익명 접근을 허용하지 않는한 username과 password를 포함하지 않는 모든 요청은 거절된다.
discovery.type: single-node
특별한 관리성 목적의 시스템 계정을 생성하기 위해 패스워드를 세팅한다.
ex) apm_system, beats_system, elastic, kibana, logstash_system, remote_monitoring_user
./bin/elasticsearch-setup-passwords interactive
엘라스틱서치의 시큐리티 기능을 활성화할때 사용자는 유효한 사용자ID와 패스워드를 필요로 한다.
생성한 키바나 유저와 패스워드를 이용하여 키바나를 구성한다.
kibana.yml에 작성
elasticsearch.username: "kibana"
elasticsearch.password: "your_password"
elasticsearch-setup-passwords 커맨드를 이용해 세팅한 패스워드를 정의한다.
만약 kibana.yml 파일에 사용자ID와 패스워드를 입력하는 것을 선호하지 않는다면, 대신에 키스토어를 저장한다.
아래 명령어를 통해 키바나 키스토어를 생성하고 보안 세팅을 추가할 수 있다.
./bin/kibana-keystore create
./bin/kibana-keystore add elasticsearch.username
./bin/kibana-keystore add elasticsearch.password
설정이 끝나면, 키바나를 재시작한다.
키바나에 접속하여 인증을 구성한다. 자세한 방법은 엘라스틱서치 가이드를 참고한다.
https://www.elastic.co/guide/en/elastic-stack-overview/7.1/ssl-tls.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.1/configuring-tls.html#node-certificates
TLS는 통신중인 응용 프로그램의 암호화와 인증을 수행하기 위한 X.509 인증서를 필요로한다.
노드간의 통신이 정말 안전하기 위해서는 그 인증서의 유효성을 체크해야한다.
엘라스틱서치 클러스터에서 인증서의 신뢰성을 확인하기 위한 권장하는 방법은 인증서에 서명된 CA 인증서를 믿는것이다.
이렇게 하면 노드는 동일한 CA에 서명된 인증서를 사용하길 필요로 하는 클러스터에 추가되고
그 노드는 자동으로 클러스터에 합류하게 된다.
또한, 호스트명의 유효성을 확인하기 위한 노드의 IP주소와 DNS명에 해당하는 SAN을 인증서에 포함되는 것이 좋다.
elasticsearch-certutil 명령어는 엘라스틱스택을 위한 인증서 생성 프로세스를 단순하게한다.
이것은 CA 생성 및 CA 인증서 서명에 필요하다.
대화식 혹은 입력 파일을 사용한 사일런트 모드로 사용할 수 있다.
이것은 CSR을 생성하는 것을 지원하며, 상용 혹은 조직에 특성화된 CA를 인증서에 서명하도록 사용된다.
엘라스틱서치 클러스터에 CA를 생성한다.
bin/elasticsearch-certutil ca
이 CA에 서명된 인증서를 가지는 모든 노드를 신뢰하도록 클러스터를 구성할 수 있다. 이 명령어는 elastic-stack-ca.p12 의 이름을 가진 단일 파일을 내보낸다. 이 파일은 CA의 public 인증서와 각 노드의 인증서에 서명하는데 사용되는 private 키를 포함한 PKCS#12 Keystore이다. elasticsearch-certutil 명령어는 파일과 키를 보호하기 위해 패스워드를 묻는 메시지를 표시한다.
만약 클러스터에 더 많은 노드를 추가시킬 계획이 있다면, 파일의 복사본을 유지하고 패스워드를 기억한다.
각 노드의 인증서와 private키를 생성한다.
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
출력되는 파일은 노드 인증서, 노드 키, CA 인증서를 포함한 PKCS#12 keystore 파일이다. 또한 암호를 묻는 메시지가 나타난다. 인증서와 키를 위한 패스워드를 입력하거나 엔터를 누름으로써 패스워드를 비워둘 수 있다. 기본적으로 elasticsearch-certutil는 호스트명 정보가 없는 인증서를 생성한다. 즉, 클러스터의 모든 노드에 대해 인증서를 사용할 수 있지만 아래 구성에서 보는 것 처럼 호스트명 유효성을 체크해야한다. 만약 클러스터 안에 호스트명 유효성을 사용하길 원한다면, 각 노드의 한번 elasticsearch-certutil cert 명령어를 수행하고 --name, --dns, --ip 옵션을 사용한다.
대안으로, 만약 상용 혹은 조직에 특성화된 CA를 사용하기를 원한다면 클러스터에 노드를 위한 CSR을 생성하는 elasticsearch-certutil csr 명령어를 사용할 수 있다.
각 노드의 엘라스틱서치 구성 디렉토리 안의 디렉토리에 .p12 파일을 복사한다. (예를 들어, /home/es/config/certs.)
이 디렉토리를 위한 CA 파일의 복사는 불필요하다. 구성하기를 원하는 각 추가된 엘라스틱 제품을 위해서 구성 디렉토리와 관련된 인증서를 복사한다.
전송 계층 레이어는 클러스터 안에서 노드간의 상호 통신을 위해서 사용된다.
시큐리티 기능이 활성화될 때, 암호화된 노드 사이에 통신을 하기 위해 TLS를 사용해야만 한다.
위에서 노드 인증서가 생성되면 TLS를 활성화하고 노드의 인증서를 접근하는데 필요한 정보를 정의한다.
만약 서명된 인증서가 PKCS#12 형식이라면, 각 노드의 elasticsearch.yml 파일에 다음 정보를 기입한다.
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12
① --dns나 --ip 옵션을 사용하고 엄격한 호스트명 검사를 원한다면, verification mode를 full로 설정하라.
② 각 노드의 별도의 인증서를 만드는 경우, 각 노드에서 커스터마이즈된 경로가 필요하다. 파일명이 노드명과 일치한다면, certs/${node.name}.p12 형식을 사용할 수 있다.
③ elasticsearch-certutil는 CA 인증서를 포함하는 PKCS#12 keystore를 출력한다. 이것은 truststore로서 사용되는 keystore를 허용한다. 이 경우에, 경로 값은 keystore.path값과 일치해야 한다. 그러나 이것은 일반적인 규칙이 아니며, trustores로서 사용될수 없는 keystore가 있다.
만약 서명된 인증서가 PEM 형식일 경우, 각 노드의 elasticsearch.yml 파일에 다음 정보를 기입한다.
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.key: /home/es/config/node01.key
xpack.security.transport.ssl.certificate: /home/es/config/node01.crt
xpack.security.transport.ssl.certificate_authorities: [ "/home/es/config/ca.crt" ]
① --dns나 --ip 옵션을 사용하고 엄격한 호스트명 검사를 원한다면, verification mode를 full로 설정하라.
② 노드 키 파일의 전체 경로. 엘라스틱서치 구성 디렉토리 안에 위치되어야 한다.
③ 노드 인증서의 전체 경로. 엘라스틱서치 구성 디렉토리 안에 위치되어야 한다.
④ 신뢰되는 CA 인증서의 경로 배열. 엘라스틱서치 구성 디렉토리 안에 위치되어야 한다.
패스워드를 사용하여 노드 인증서를 보호하고 싶아면 엘라스틱서치 키스토어에 패스워드를 추가한다.
만약 서명된 인증서가 PKCS#12 형식이라면, 아래 명령어를 사용한다.
bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password
만약 서명된 인증서가 PEM 형식이라면, 아래 명령어를 사용한다.
bin/elasticsearch-keystore add xpack.security.transport.ssl.secure_key_passphrase
최종적으로 elasticsearch.yml에 설정될 구성은 아래와 같다.
elasticsearch.yml 설정
- xpack.security.enabled: true
- xpack.security.transport.ssl.enabled: true
- xpack.security.transport.ssl.verification_mode: certificate
- xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
- xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12
{elastic_home}/elasticsearch/config/cert/ 하위에 elastic-certificates.p12 Keystore파일 위치
{elastic_home}/elasticsearch/ 하위에 elastic-stack-ca.p12 CA파일 위치
설정이 완료되면, 엘라스틱서치를 재시작한다.
https://www.elastic.co/guide/en/logstash/current/ls-security.html#ls-http-auth-basic
로그스태시 파이프라인 Output 플러그인에서 엘라스틱서치에 접근하기 위해서는 별도의 아이디, 패스워드가 필요하다.
키바나에서 익덱스의 생성 및 삭제를 수행할 Role을 생성한다.
Role Name: logstash_writer
cluster privileges: manage_index_templates/monitor
indices privileges: write, delete, create_index
위에서 생성한 Role이 부여된 User를 생성한다.
User Name: logstash_internal
logstash_writer Role 부여
로그스태피 파이프라인 Output 플러그인에 아래와 같이 작성한다.
output {
elasticsearch {
...
user => logstash_internal
password => x-pack-test-password
}
}