説明
--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 のデプロイが完了するわけではありません。