Define “doesn’t have permission”.
The requirement for etcdctl authentication with etcd server is that a certificate signed by etcd’s CA cert and that cert’s key are presented along with the CA cert.
Let’s have a look at the certs in etcd’s PKI
controlplane $ cd /etc/kubernetes/pki/etcd/
controlplane $ ls -l
total 32
-rw-r--r-- 1 root root 1094 Nov 6 12:27 ca.crt
-rw------- 1 root root 1679 Nov 6 12:27 ca.key
-rw-r--r-- 1 root root 1123 Nov 6 12:27 healthcheck-client.crt
-rw------- 1 root root 1675 Nov 6 12:27 healthcheck-client.key
-rw-r--r-- 1 root root 1208 Nov 6 12:27 peer.crt
-rw------- 1 root root 1679 Nov 6 12:27 peer.key
-rw-r--r-- 1 root root 1208 Nov 6 12:27 server.crt
-rw------- 1 root root 1675 Nov 6 12:27 server.key
controlplane $ openssl x509 -in ca.crt -noout -text | grep Subject:
Subject: CN = etcd-ca
controlplane $ openssl x509 -in server.crt -noout -text | grep Issuer:
Issuer: CN = etcd-ca
controlplane $ openssl x509 -in peer.crt -noout -text | grep Issuer:
Issuer: CN = etcd-ca
controlplane $
When the Issuer of a given certificate is the same as the Subject of a CA certificate, it means that the given certificate was issued from that CA and is valid (along with it’s key) for authentication.
Therefore either of server.crt and server.key or peer.crt and peer.key along with ca.crt will work.