You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Existing open issues along with etcd frequently asked questions have been checked and this is not a duplicate.
What happened?
I have observed that etcd is reading the private key from disk continuously. The issue observed when an audit rule has been applied to catch the private keys being read.
The issue was discovered running a kubernetes cluster with three nodes deployed with kubespray in three virtual machines managed by vagrant.
What did you expect to happen?
etcd should read the key at start up and keep it in memory for further use.
My previous ticket was closed without any chance of justifying my point of view.
Here goes the replica:
Supporting dynamically loading the certificate does not imply on reading it from disk at every call.
The certificate can be held for a specific amount of time, and replaced when that time is expired. That could be even configurable.
Reading the file at every call can cause a bottleneck and harm the performance.
How can we reproduce it (as minimally and precisely as possible)?
On a k8s control plane node install auditd.
apt-get install auditd
Create an audit rules for monitoring the key file
for key in $(ls /etc/ssl/etcd/ssl/*key.pem); do
echo -a always,exit -F arch=b64 -F path=${key} -F perm=rwa -k etcd -k etcd-keys
done >/etc/audit/rules.d/etcd-keys.rules
systemctl restart auditd
You raised this as a bug, what's the exact issue that impacts your business?
You also mentions the performance impact. If it's only related to performance, this ticket should be a feature request, also it'd be better to demo how much performance may be affected with or without the dynamically loading certificate feature.
Bug report criteria
What happened?
I have observed that etcd is reading the private key from disk continuously. The issue observed when an audit rule has been applied to catch the private keys being read.
The issue was discovered running a kubernetes cluster with three nodes deployed with kubespray in three virtual machines managed by vagrant.
What did you expect to happen?
etcd should read the key at start up and keep it in memory for further use.
My previous ticket was closed without any chance of justifying my point of view.
Here goes the replica:
Supporting dynamically loading the certificate does not imply on reading it from disk at every call.
The certificate can be held for a specific amount of time, and replaced when that time is expired. That could be even configurable.
Reading the file at every call can cause a bottleneck and harm the performance.
How can we reproduce it (as minimally and precisely as possible)?
On a k8s control plane node install auditd.
Create an audit rules for monitoring the key file
Inspect audit logs
Anything else we need to know?
No response
Etcd version (please run commands below)
Etcd configuration (command line flags or environment variables)
Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)
Relevant log output
The text was updated successfully, but these errors were encountered: