설명
API 서버나 kubelet의 HTTPS 연결에는 올바른 서버 인증서와 대응하는 개인 키가 필요합니다. 명시적인 파일 설정이 없더라도 자체 서명 인증서를 생성하거나 승인된 인증서 발급 절차를 사용할 수 있으므로, 파일 경로 누락만으로 평문 통신이라고 판단할 수는 없습니다.
중요한 것은 실제 제공되는 인증서를 클라이언트가 신뢰할 CA와 올바른 서버 이름으로 검증하는지입니다.
잠재적 영향
- 서버 인증서를 검증하지 않으면 상대 서버의 사칭을 막기 어렵습니다.
- 잘못된 인증서·키나 만료된 인증서는 연결 장애를 일으킬 수 있습니다.
해결 방법
- 직접 파일을 관리한다면
--tls-cert-file과--tls-private-key-file에 유효한 쌍을 지정하세요. kubelet은 해당 구성 파일의 TLS 설정도 확인하세요. - 자동 발급을 사용한다면 승인·갱신 절차와 클라이언트의 CA 신뢰가 실제로 동작하는지 확인하세요.
- 개인 키 접근을 제한하고 인증서의 서버 이름·만료일 및 실제 HTTPS 연결을 시험하세요.
예시
Kubernetes 1.6.0 API 서버 인자의 과거 발췌입니다. 파일 이름은 예시이며 실제 PEM 인증서·키 내용과 배포 경로를 적용해야 합니다.
변경 전
yaml
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command: ["kube-apiserver"]
args: []
TLS 파일을 명시하지 않았습니다. 실제로 생성되거나 제공되는 인증서와 클라이언트의 검증 설정을 확인해야 합니다.
변경 후
yaml
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command: ["kube-apiserver"]
args: ["--tls-cert-file=someFile.txt", "--tls-private-key-file=someFile.txt"]
인증서와 개인 키 경로를 지정했습니다. 예시의 someFile.txt를 그대로 신뢰하지 말고 실제 파일에 올바른 인증서와 대응하는 키가 있는지 확인하세요.