説明
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 が入っていることを確認してください。