설명
etcd와 kube-apiserver가 같은 클라이언트 CA를 공유하면 한쪽을 위해 발급한 인증서를 다른 쪽에서도 신뢰할 수 있습니다. 실제 권한은 추가 인증·인가 조건에 달려 있지만, CA의 발급 권한이나 키가 침해되면 영향 범위가 커질 수 있습니다.
CA 파일 이름을 다르게 만드는 것만으로 신뢰가 분리되지는 않습니다. 실제 CA 인증서와 발급 체계를 확인해야 합니다.
잠재적 영향
- 한 신뢰 영역의 인증서나 발급 권한이 다른 제어면 경로에도 영향을 줄 수 있습니다.
- CA 침해 시 교체와 사고 대응 범위가 여러 구성요소로 확대될 수 있습니다.
해결 방법
- etcd와 Kubernetes API 클라이언트 인증에 사용하는 CA를 목적별로 분리하세요.
--trusted-ca-file과--client-ca-file의 실제 인증서 내용을 확인하고 각 CA 키의 사용·발급 권한을 제한하세요.- 기존 클라이언트 인증서를 함께 교체하는 전환 절차를 마련하고 정상 접근과 다른 신뢰 영역의 인증서 거부를 확인하세요.
예시
과거 etcd·API 서버 인자의 부분 예시입니다. 지원되는 버전과 실제 인증서 마운트 및 나머지 배포 설정이 필요합니다.
변경 전
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: database
spec:
template:
spec:
containers:
- name: database
image: gcr.io/google_containers/etcd:v3.2.18
command: ["etcd"]
args: ["--trusted-ca-file=/etc/env/valid3.pem"]
---
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: ["--client-ca-file=/etc/env/valid3.pem"]
같은 CA 파일 경로를 사용합니다. 파일이 실제로 같은 CA를 담고 있다면 두 인증 경로가 신뢰를 공유합니다.
변경 후
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: ["--client-ca-file=/etc/env/valid.pem"]
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: database
spec:
template:
spec:
containers:
- name: database
image: gcr.io/google_containers/etcd:v3.2.18
command: ["etcd"]
args: ["--trusted-ca-file=/etc/env/valid2.pem"]
서로 다른 파일 경로를 지정했습니다. 두 파일이 실제로 별도의 CA를 담고 있는지 확인해야 신뢰 영역을 분리할 수 있습니다.