説明
API サーバーが証明書で etcd に認証する場合は、--etcd-certfile と --etcd-keyfile を両方設定してください。片方だけではクライアント認証の設定が不完全になり、接続に失敗する可能性があります。
クライアント証明書と鍵は、etcd サーバー証明書を検証する CA 設定とは別です。両ファイルの指定だけで相互認証が完成するわけではありません。
想定される影響
- etcd への接続失敗により、API サーバーの動作に支障が出る可能性があります。
- 接続を復旧するために認証やサーバー検証を回避すると、コントロールプレーンのデータ保護が弱まるおそれがあります。
対処方法
--etcd-certfileと--etcd-keyfileに、対応する有効な証明書と秘密鍵を指定してください。- HTTPS の etcd エンドポイントと
--etcd-cafileを構成し、etcd 側で API サーバーのクライアント証明書を信頼するよう設定してください。 - ファイルのマウント・権限・有効期限を確認し、変更後に認証付き接続を試験してください。
例
Kubernetes 1.6.0 の引数を示す過去の抜粋です。サポート対象のバージョンと、実際にマウントした証明書ファイルを使用してください。
変更前
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: ["--etcd-keyfile=/path/to/key/file.key"]
秘密鍵だけが指定されています。証明書によるクライアント認証に必要な組み合わせが揃っていません。
変更後
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: ["--etcd-keyfile=/path/to/key/file.key", "--etcd-certfile=/path/to/cert/file.crt"]
クライアント証明書と秘密鍵を両方指定しています。HTTPS エンドポイントと双方の CA 信頼設定も別途必要です。