EFK Stack 구축하기 (3) - Kibana
Fluent Bit가 보낸 log를 Elasticsearch에 저장했다면 Kibana는 이를 검색하고 시각화하며 운영자가 분석하는 UI가 됩니다. 이 글은 Elastic Cloud on Kubernetes(ECK)로 Kibana를 Elasticsearch에 연결하고, ECK가 기본으로 제공하는 TLS와 credential을 안전하게 다루는 방법을 정리합니다.
TL;DR
- ECK
Kibanacustom resource는elasticsearchRef로 같은 ECK가 관리하는 Elasticsearch에 연결합니다.- Kibana와 Elasticsearch는 호환되는 같은 Elastic Stack version으로 관리하고, ECK가 만든 HTTPS Service를 먼저 port-forward로 확인합니다.
- 기본
elasticpassword와 self-signed certificate는 quickstart 확인에만 사용하고, production에서는 최소 권한 사용자와 신뢰 가능한 TLS certificate를 사용합니다.
1. 구성과 용어
| 용어 | 의미 |
|---|---|
| ECK | Elasticsearch, Kibana 같은 Elastic workload를 Kubernetes custom resource로 관리하는 operator입니다. |
| Elasticsearch | log document를 index에 저장하고 검색하는 distributed search engine입니다. |
| Kibana | Elasticsearch data를 query, dashboard, alerting UI로 제공하는 application입니다. |
elasticsearchRef | Kibana resource가 연결할 Elasticsearch resource를 가리키는 field입니다. |
ECK는 Kibana와 Elasticsearch 사이의 secure connection을 자동 구성합니다. 두 resource가 같은 namespace가 아니라면 elasticsearchRef.namespace를 명시할 수 있지만, 두 namespace가 같은 ECK operator의 watch 범위에 있어야 합니다.
1
2
3
4
Fluent Bit --> Elasticsearch <--- ECK-managed TLS and credentials --- Kibana
^ |
| v
log index search, dashboard, alert
ECK가 관리하는 두 resource는 elasticsearchRef를 통해 연결할 때 필요한 Secret을 Kibana namespace로 복사해 secure connection을 설정합니다. 서로 다른 ECK instance가 관리하는 namespace 사이에는 이 자동 연결을 사용할 수 없습니다.
2. Kibana resource 배포
아래 example의 version은 Elasticsearch resource의 spec.version과 같은 값으로 맞춥니다. version을 한쪽만 변경하지 말고 Elastic upgrade 문서의 순서와 compatibility를 확인합니다.
1
2
3
4
5
6
7
8
9
10
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
name: weasel-kibana
namespace: logging
spec:
version: <same-version-as-elasticsearch> # Elasticsearch spec.version과 같은 version
count: 1
elasticsearchRef:
name: weasel-elasticsearch
1
2
3
kubectl apply -f kibana.yaml
kubectl -n logging get kibana,pods
kubectl -n logging get service weasel-kibana-kb-http
green health와 Kibana Pod Ready를 모두 확인한 뒤 UI 접속을 시도합니다. Pod가 기동하지 않으면 먼저 Kibana Pod log와 ECK operator log를 확인하고, Elasticsearch health와 resource version을 함께 점검합니다.
3. HTTPS로 로컬 접속 확인
ECK는 기본적으로 Kibana용 ClusterIP Service와 self-signed TLS certificate를 만듭니다. 외부 load balancer를 바로 만들기보다 port forwarding으로 application 상태와 credential을 먼저 검증하는 편이 안전합니다.
1
kubectl -n logging port-forward service/weasel-kibana-kb-http 5601:5601
브라우저에서 https://localhost:5601에 접속합니다. quickstart에서는 self-signed certificate 경고가 보일 수 있습니다. production endpoint에서 경고를 무시하지 말고 DNS name을 포함한 신뢰 가능한 certificate를 구성합니다.
ECK가 만든 elastic 사용자의 초기 password는 다음처럼 확인할 수 있습니다.
1
2
kubectl -n logging get secret weasel-elasticsearch-es-elastic-user \
-o jsonpath='{.data.elastic}' | base64 --decode; echo
이 password를 terminal history, ticket, dashboard screenshot, manifest에 저장하지 않습니다. 사람이 Kibana에 로그인할 때는 elastic superuser 대신 역할이 제한된 사용자나 SSO 연동을 사용합니다.
4. Production 노출과 운영 점검
Kibana는 log와 saved query에 민감 정보가 포함될 수 있는 운영 UI입니다. Internet에 직접 노출하는 대신 다음을 검토합니다.
- ingress 또는 load balancer에는 HTTPS와 인증을 강제하고, ingress controller와 ECK Service 사이의 TLS 종료 지점을 명확히 합니다.
- external DNS 또는 IP로 노출할 때 self-signed certificate의 SAN과 health check path, TLS 검증 정책을 함께 확인합니다.
- Kibana replica를 늘릴 경우 encryption key를 공유해야 합니다. replica 수를 늘리기 전에 session, saved object encryption, resource request를 설계합니다.
- Elasticsearch index lifecycle, snapshot, role-based access control, audit 정책을 Kibana deployment와 별도로 운영합니다.
- ECK operator와 CRD version을 서로 다른 지원 조합으로 운영하지 않습니다. operator upgrade가 workload rolling restart를 유발할 수 있으므로 maintenance window를 잡습니다.
5. 정리
ECK 환경에서 Kibana는 단순 UI deployment가 아니라 Elasticsearch access 경로입니다. 같은 Stack version과 elasticsearchRef를 먼저 맞추고, port-forward로 TLS와 login을 검증한 뒤에 ingress, 최소 권한, certificate, encryption key를 운영 요구사항에 맞게 추가하는 순서가 안전합니다.
6. Reference
- Elastic Docs - Deploy a Kibana instance
- Elastic Docs - Connect to an Elasticsearch cluster
- Elastic Docs - Configure deployments
궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi