Separate etcd peer and client trust before scaling the cluster
etcd is the durable control store for many Kubernetes and platform deployments. Its peer connections replicate state among members. Client connections read and write the same state. A certificate that authenticates a peer is therefore not interchangeable with a certificate that authenticates an ordinary client. Treating both as one broad TLS population weakens the cluster boundary.
Two directions, two identities
etcd supports TLS and client-certificate authentication for client-to-server and peer-to-server communication. The client-facing settings use a trusted CA and client certificate authentication. Peer settings have their own trusted CA, certificate, and key fields. The cluster can use the same CA, but the roles should remain distinguishable through certificate profiles, SANs, and issuance policy.
A peer certificate usually needs the member's reachable names and addresses in its subject alternative names. A client certificate represents an application or operator identity. If the same issuing role can mint both, a compromised application might request a peer-shaped certificate. Separation at the role and certificate-profile level reduces that path.
etcd's configuration documentation also describes allowed names for inter-peer authentication. A peer certificate signed by the trusted CA may still need its common name to match the allowed set. That check is useful because it narrows which certificates can act as cluster members.
Plaintext peer traffic is a design choice with consequences
A cluster may start with client TLS while leaving peer traffic unauthenticated. This simplifies the bootstrap process, but it makes the network between members part of the trust boundary. Anyone who can reach the peer port and speak the protocol may be able to affect cluster state. Network segmentation helps, yet it should be documented as an assumption and tested against accidental exposure.
When peer TLS is enabled, verify both directions. The listening member needs a certificate the other members can validate. The connecting member needs a client certificate the listener accepts. A successful one-member configuration does not prove the cluster path. Restart or add a member and inspect the handshake with the actual peer identity.
Authentication does not replace authorization
A valid client certificate establishes identity. etcd still needs an authorization model for what that identity may read or write. Kubernetes service accounts, backup jobs, and operators should not all receive the same client certificate. A backup process that only reads a range should not be able to delete keys.
Map each client certificate to a workload and an owner. Review the authentication method that binds the certificate to an etcd user. Check whether the client can still authenticate with a password or another method that bypasses the intended certificate control. Remove unused authentication paths when the migration is complete.
Audit the cluster as it is deployed
Collect the peer and client CA files, certificate SANs, allowed peer names, and authentication flags from the running process command lines. Compare them across members. A single member with an older certificate or a missing peer authentication flag can weaken the whole cluster even when the other members look correct.
Test a client certificate against the peer endpoint and a peer certificate against the normal client endpoint. Both should fail unless the design explicitly requires that overlap. Test a certificate with an unexpected SAN or common name. Confirm that the rejection happens before the client can issue a request.
Certificate rotation belongs in the same design. Peer certificates and client certificates may need different lead times and different rollback paths. Keep enough overlap for a safe restart, but remove the old trust after the new members are healthy. Record which certificates are active and when the old trust will be withdrawn.
etcd gives operators the flags to separate these paths. The security value comes from using the separation consistently across issuance, configuration, network access, and authorization.
Top comments (0)