Proposal
Fleet-managed Elastic Agents deployed via the Agent CRD should be automatically restarted (rolling restart) by the ECK operator when CA or client certificates are rotated — the same behavior already implemented for Fleet Server and Standalone Agents.
Currently, ECK provides automatic certificate lifecycle management and restart-on-rotation for every stack component except Fleet-managed Agents:
| Component |
Auto-restart on cert rotation |
Reference |
| Elasticsearch |
✅ Rolling restart on CA/transport cert rotation |
TLS certificates docs |
| Kibana |
✅ Auto-generates client cert, configures mTLS trust bundle |
mTLS blog |
| Fleet Server (Agent CRD) |
✅ "restarts Elastic Agent on certificate rollover" |
Fleet configuration docs |
| Standalone Agents |
✅ "recreates Pods when this certificate changes" |
Standalone Agent docs |
| Fleet-managed Agents |
❌ No restart or reload on cert rotation |
— |
Additionally, the Elastic Agent process itself does not support hot-reloading of certificates:
"Elastic Agent does not support hot reloading of updated certificates or CA files. You must restart the agent to apply changes."
— Fleet certificate rotation docs
This leaves Fleet-managed Agents in a uniquely vulnerable position: the ECK operator does not restart them on certificate rollover, and the agent process cannot detect certificate changes on disk.
Requested changes (one or both):
-
ECK operator parity: The operator should perform a rolling restart of Fleet-managed Agent pods when it rotates CA or client certificates — matching the existing behavior for Fleet Server and Standalone Agents.
-
Certificate file watching in Elastic Agent: The agent should watch configured certificate file paths for changes and reload TLS connections when certificates are rotated, without requiring a full process restart. This would bring Elastic Agent closer to parity with Beats and eliminate the dependency on external restart mechanisms.
Use case — why is this important?
This gap caused a production ingestion outage. After ECK-managed certificate rotation, Fleet-managed Agents continued running with stale certificates. Because neither the operator restarted the pods nor the agent detected the certificate change, those agents silently lost connectivity to Fleet Server / Elasticsearch. The result was data loss from affected sources into the SIEM platform until manual pod restarts were performed.
At scale, manually monitoring certificate expiry and restarting Fleet-managed Agent pods defeats the purpose of ECK's automated certificate lifecycle management. Every other component in the stack handles this transparently — Fleet-managed Agents should too.
The blast radius grows with fleet size: any organization running multiple Fleet-managed Agent deployments (different policies for different data sources) faces N potential ingestion gaps per certificate rotation event.
Alternatives considered
-
Manual pod restarts on a schedule — Operationally untenable at scale. Requires tracking certificate expiry per deployment and coordinating restarts. Error-prone and reactive.
-
Switching to Standalone Agents — Standalone Agents already get pod recreation on cert changes, but this sacrifices Fleet's centralized policy management, which is the primary reason for using Fleet-managed Agents.
-
External certificate-watch sidecar / CronJob — A sidecar or CronJob that watches the mounted certificate secrets and triggers a rollout restart when they change. This works but is a workaround that every ECK user must independently build and maintain. The operator already has this capability for other components.
-
Shorter certificate validity periods with aggressive rotation — Reduces the window of exposure but increases the frequency of outages rather than preventing them.
Related issues
Proposal
Fleet-managed Elastic Agents deployed via the Agent CRD should be automatically restarted (rolling restart) by the ECK operator when CA or client certificates are rotated — the same behavior already implemented for Fleet Server and Standalone Agents.
Currently, ECK provides automatic certificate lifecycle management and restart-on-rotation for every stack component except Fleet-managed Agents:
Additionally, the Elastic Agent process itself does not support hot-reloading of certificates:
This leaves Fleet-managed Agents in a uniquely vulnerable position: the ECK operator does not restart them on certificate rollover, and the agent process cannot detect certificate changes on disk.
Requested changes (one or both):
ECK operator parity: The operator should perform a rolling restart of Fleet-managed Agent pods when it rotates CA or client certificates — matching the existing behavior for Fleet Server and Standalone Agents.
Certificate file watching in Elastic Agent: The agent should watch configured certificate file paths for changes and reload TLS connections when certificates are rotated, without requiring a full process restart. This would bring Elastic Agent closer to parity with Beats and eliminate the dependency on external restart mechanisms.
Use case — why is this important?
This gap caused a production ingestion outage. After ECK-managed certificate rotation, Fleet-managed Agents continued running with stale certificates. Because neither the operator restarted the pods nor the agent detected the certificate change, those agents silently lost connectivity to Fleet Server / Elasticsearch. The result was data loss from affected sources into the SIEM platform until manual pod restarts were performed.
At scale, manually monitoring certificate expiry and restarting Fleet-managed Agent pods defeats the purpose of ECK's automated certificate lifecycle management. Every other component in the stack handles this transparently — Fleet-managed Agents should too.
The blast radius grows with fleet size: any organization running multiple Fleet-managed Agent deployments (different policies for different data sources) faces N potential ingestion gaps per certificate rotation event.
Alternatives considered
Manual pod restarts on a schedule — Operationally untenable at scale. Requires tracking certificate expiry per deployment and coordinating restarts. Error-prone and reactive.
Switching to Standalone Agents — Standalone Agents already get pod recreation on cert changes, but this sacrifices Fleet's centralized policy management, which is the primary reason for using Fleet-managed Agents.
External certificate-watch sidecar / CronJob — A sidecar or CronJob that watches the mounted certificate secrets and triggers a rollout restart when they change. This works but is a workaround that every ECK user must independently build and maintain. The operator already has this capability for other components.
Shorter certificate validity periods with aggressive rotation — Reduces the window of exposure but increases the frequency of outages rather than preventing them.
Related issues