Kubernetes and business components are mixed in the same etcd cluster, there is a possibility of key conflict, the plan is to control the paths that Client can write through the permission mechanism that comes with etcd.

Role-based access control

etcd v3 supports RBAC-based user rights management, which is disabled by default.

You will need to run the following command to enable etcd privileges after you start etcd.

1
2
3
4
5
6
7

# Create special user and role, and bind
etcdctl user add root --new-user-password=Hell0@ETCD
etcdctl role add root
etcdctl user grant-role root root

# Enable permission function
etcdctl auth enable

etcd requires users to create a special user and role before enabling permissions, where the root user is the superuser of the etcd cluster and has all permissions, and the root role has the same permissions as the root user, which can be bound to any user with the grant-role command.

Create the Kubenretes role

When deploying kubernetes with kubeadmin, the following client certificates are generated by default for access to etcd.

  • /etc/kubernetes/pki/apiserver-etcd-client.crt
  • /etc/kubernetes/pki/etcd/healthcheck-client.crt

The corresponding CN values are:

  • kube-apiserver-etcd-client
  • kube-etcd-healthcheck-client

By default kube-apiserver reads and writes etcd with the key prefix “/registry” (which can be specified with the -etcd-prefix parameter), so we create the corresponding user and role with the following command.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Create users
etcdctl user add kube-apiserver-etcd-client   --new-user-password=kubernetes
etcdctl user add kube-etcd-healthcheck-client --new-user-password=kubernetes

# Create a kubernetes role and configure read and write permissions
etcdctl role add kubernetes
etcdctl role grant-permission kubernetes --prefix=true readwrite /registry

# Binding user and role
etcdctl user grant-role kube-apiserver-etcd-client   kubernetes
etcdctl user grant-role kube-etcd-healthcheck-client kubernetes

The above command creates readwrite permissions in /registry for the kubernetes role. The types of permissions currently supported by etcd are very simple: readwrite, read, and write.

Enable Client Cert Auth

By default, if etcd exposes port 2379 via http, the user will need to provide the corresponding user/password when reading or writing to etcd. The corresponding command is as follows.

1
2

# Access via User/Passwd
etcdctl --user root --password Hell0@ETCD  get <key>

If etcd exposes port 2379 via https, we need to configure -client-cert-auth=true so that the CN field in the client’s TLS certificate is used as the etcd user, in which case the client does not need to provide the user’s password.

In the gRPC-proxy and gRPC-gateway scenarios, the server side cannot get the corresponding CN information from the client’s certificate, so the user needs to pass additional user/password information.

If the user provides both tls certificate and user/password, etcd will authenticate with the latter.

There does not seem to be a need to be concerned about permissions when communicating between peers.