Review control plane certificate authority trust

Description

When etcd and kube-apiserver share a client CA, certificates issued for one can also be trusted by the other. Additional authentication and authorization conditions still govern access, but compromise of CA keys or issuance permissions can affect a wider area.

Different CA filenames do not establish separate trust. Check the actual CA certificates and issuance arrangements.

Potential impact

Certificates or issuance authority in one trust domain can affect another control plane path.
A CA compromise can require replacement and incident response across multiple components.

Remediation

Separate the CAs used for etcd and Kubernetes API client authentication by purpose.
Check the certificates inside --trusted-ca-file and --client-ca-file, and restrict use of CA keys and certificate issuance permissions.
Plan migration of existing client certificates and verify normal access and rejection of certificates from the other trust domain.

Examples

These are partial examples of historical etcd and API server arguments. Supported versions, actual certificate mounts and the remaining deployment settings are required.

Before

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"]

Both use the same CA file path. If the files actually contain the same CA, the two authentication paths share trust.

After