요약
SUMMARY
ECK(Elastic Cloud on Kubernetes) operator로 띄운 Elasticsearch에서, standalone처럼
elasticsearch.yml에xpack.security.*를 넣어 TLS·인증을 끄려 했는데 안 먹었다. ECK가 관리하는 설정은 사용자가 덮어써도 operator가 되돌리기 때문이다. 끌 수 있는 건 HTTP 계층의 자체서명 인증서(spec.http.tls.selfSignedCertificate.disabled: true)까지고, 노드 간 transport TLS와 보안 자체는 ECK가 강제한다.
“standalone에서 되던 걸 ECK에서도 되겠지”가 안 통하는 대표적인 지점이었다.
1. 무엇을 하려다 막혔나
개발·내부용이라 인증서·인증 없이 평문 HTTP로 간단히 붙고 싶었다. standalone Elasticsearch라면 elasticsearch.yml에 이렇게 쓰면 된다.
xpack.security.enabled: false
xpack.security.http.ssl.enabled: false
xpack.security.transport.ssl.enabled: false그런데 ECK로 만든 Elasticsearch 리소스의 spec.config에 같은 걸 넣어도 반영이 안 되거나, 클러스터가 안 뜬다. operator가 자기가 관리하는 설정을 다시 자기 값으로 덮기 때문이다.
2. ECK는 일부 설정을 “관리 대상”으로 잡고 되돌린다
ECK 문서의 settings managed by ECK에 명시돼 있듯, operator는 클러스터 형성·보안·TLS에 필요한 키들을 자신이 소유한다. 사용자가 spec.config로 그 키를 건드리면 무시되거나 operator가 원복한다. 특히 노드 간 transport TLS와 보안(security)은 ECK가 클러스터를 안전하게 운영하기 위한 전제라, 끄는 걸 열어두지 않았다. (discuss 스레드에서도 결론은 “그건 못 끈다”였다.)
3. 끌 수 있는 건 여기까지: HTTP 자체서명 인증서
완전히 평문으로는 못 가도, HTTP 엔드포인트의 자체서명 인증서 발급은 끌 수 있다. 그러면 HTTPS 대신 HTTP로 서빙하거나, 자체서명 대신 내가 준 인증서를 쓰게 된다.
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
spec:
http:
tls:
selfSignedCertificate:
disabled: true # ECK가 만드는 HTTP 자체서명 인증서를 끔selfSignedCertificate.disabled: true면 ECK가 HTTP 계층에 자체서명 TLS를 안 씌운다. 사설 CA 인증서를 붙이고 싶으면 이 자리에 certificate(시크릿 참조)로 내 인증서를 넣는다. 다만 이건 HTTP 계층 한정이고, transport TLS는 그대로 남는다.
4. 정리
- 가능: HTTP 계층 자체서명 인증서 비활성화(
spec.http.tls.selfSignedCertificate.disabled), 또는 내 인증서로 교체. - 불가: 노드 간 transport TLS 끄기, 보안(인증) 자체 끄기 — ECK가 관리·강제.
- 교훈: ECK를 쓰기로 했으면 “operator가 관리하는 영역”을 먼저 확인해야 한다. standalone 감각으로
elasticsearch.yml을 덮으려다 시간을 버렸다. 평문·무인증이 꼭 필요하면 ECK가 아니라 standalone 배포를 골랐어야 하는 문제다.