설명
--client-cert-auth=false만으로 etcd의 클라이언트 인증서 인증이 꺼졌다고 판단할 수는 없습니다. etcd 3.4에서는 --trusted-ca-file을 지정해도 HTTPS 클라이언트 인증서 인증이 활성화됩니다. 실제 CA와 HTTPS 구성을 함께 확인해야 합니다.
etcd는 클러스터 핵심 데이터를 저장하므로 접근 통제가 중요합니다. 클라이언트 인증서 기반 인증과 필요한 데이터 접근 권한을 함께 관리해야 합니다.
잠재적 영향
네트워크 접근이 가능한 비인가 주체를 인증서로 구분하지 못할 수 있습니다. 다른 인증·권한 통제도 부족하면 핵심 데이터의 조회·변경이나 서비스 장애 위험이 커집니다.
해결 방법
- etcd에
--client-cert-auth=true와--trusted-ca-file을 설정하고 허용할 클라이언트에 신뢰할 인증서와 키를 배포하세요. - 서버 인증서·키 및 HTTPS 주소를 구성하고 클라이언트도 서버 인증서를 검증하도록 설정하세요.
- 데이터 접근 권한과 네트워크 범위를 제한하고 승인된 연결의 성공 및 잘못된 인증서의 거부를 확인하세요.
예시
기존 etcd 버전의 인자 비교입니다. 실제 배포에는 HTTPS 주소, 서버 인증서·키, 신뢰할 CA와 클라이언트 인증서 등 나머지 설정이 필요합니다.
변경 전
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-etcd-deployment
spec:
template:
spec:
containers:
- name: database
image: gcr.io/google_containers/etcd:v3.2.18
command: ["etcd"]
args: ["--client-cert-auth=false"]
인자는 false이지만 실제 인증 동작은 신뢰할 CA와 HTTPS 설정도 함께 확인해야 합니다. 이 발췌만으로 인증서 인증이 비활성화됐다고 단정할 수는 없습니다.
변경 후
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-etcd-deployment
spec:
template:
spec:
containers:
- name: database
image: gcr.io/google_containers/etcd:v3.2.18
command: ["etcd"]
args: ["--client-cert-auth=true"]
클라이언트 인증서 검증을 요구합니다. 신뢰할 CA와 인증서 파일을 함께 구성해야 하며, 이 인자만으로 TLS 배포가 완성되지는 않습니다.