etcd authentication and RBAC is enabled by configuring TLS certificates for both the client and server, and then defining Role-Based Access Control (RBAC) rules within etcd itself.
Let’s see this in action. Imagine you have a Kubernetes cluster, and you want to ensure only authorized users and services can read or modify cluster-critical data stored in etcd.
First, you’ll need to generate TLS certificates. This typically involves a Certificate Authority (CA) that signs both server certificates for your etcd nodes and client certificates for your Kubernetes API servers (or any other clients that need to access etcd).
Here’s a snippet of what your etcd server configuration might look like, typically in a configuration file like etcd.conf.yml:
client-cert-auth: true
cert-file: /etc/etcd/ssl/etcd-server.pem
key-file: /etc/etcd/ssl/etcd-server-key.pem
trusted-ca-file: /etc/etcd/ssl/etcd-ca.pem
peer-cert-file: /etc/etcd/ssl/etcd-server.pem
peer-key-file: /etc/etcd/ssl/etcd-server-key.pem
peer-trusted-ca-file: /etc/etcd/ssl/etcd-ca.pem
The client-cert-auth: true is crucial; it tells etcd to require clients to present a valid TLS certificate signed by the trusted-ca-file. cert-file and key-file are for etcd’s own identity, and trusted-ca-file is the CA it trusts for clients. Similarly, peer-* flags handle inter-etcd node communication.
Once TLS is set up, etcd itself can be configured for RBAC. This is done via etcdctl rbac. You’ll need to define roles and then bind users or service accounts to those roles.
Let’s say we want to create a role called cluster-reader that can only read keys under /registry/.
First, we create the role:
ETCDCTL_API=3 etcdctl rbac role create cluster-reader
Then, we grant it permissions. For example, to allow GET operations on keys prefixed with /registry/:
ETCDCTL_API=3 etcdctl rbac role grant cluster-reader --prefix --path /registry/ --read
Now, we need to bind an identity to this role. This identity would typically be the certificate’s Common Name (CN) or Organization (O) field. If your API server’s client certificate has CN=kube-apiserver,O=system:masters, you’d bind it like this:
ETCDCTL_API=3 etcdctl rbac user grant --username "system:kube-apiserver" --role cluster-reader
Or, if you’re using Kubernetes service accounts and have mapped them to etcd identities, you’d bind accordingly. The system:kube-apiserver identity is often a special one that has broad access by default in many Kubernetes setups, but this demonstrates how you’d restrict it or grant specific permissions.
When a client (like the kube-apiserver) makes a request to etcd, etcd verifies the client’s TLS certificate against its trusted CA. If valid, it then inspects the certificate’s identity (CN, O, etc.) and checks if that identity has been granted the necessary RBAC permissions for the requested operation and key path.
The magic happens because RBAC rules are stored within etcd itself, under a special prefix like /sys/rbac/. This means etcd is self-protecting: its own access control policies are stored in a way that only authorized etcd users can modify them.
If a client tries to perform an operation (e.g., PUT /registry/pods/my-pod) without the cluster-reader role (or equivalent), etcd will deny the request with a permission denied error, even if the TLS connection was established successfully. The RBAC layer sits on top of TLS authentication.
The most surprising detail is how etcd handles certificate identity mapping. While you can bind RBAC roles directly to certificate CNs and OUs, it’s common in Kubernetes to use a SubjectAccessReview mechanism. The kube-apiserver, when it receives a request from a user, first checks its own RBAC rules. If authorized, it then forwards the request to etcd. The identity asserted by the client certificate is passed along. etcd’s RBAC checks are then performed against this asserted identity. This means etcd’s RBAC is often acting as a secondary, lower-level enforcement point, ensuring that even if the API server makes a mistake or has a misconfiguration, etcd won’t allow unauthorized access to raw data.
After successfully enabling authentication and RBAC, your next challenge will be managing certificate rotation and ensuring your RBAC policies are granular enough to meet your security requirements without impeding legitimate operations.