cEOS: back RESTCONF with EOS's own SSL profile, dropping the cert Job

[mbakalarski]

The defect

RESTCONF died on every container restart. startup-config is a ConfigMap mounted at /mnt/flash/startup-config and survives anything; the certificate it named was written by the <node>-generate-cert Job into the container's writable layer and did not. After a restart the profile referenced a file that no longer existed:

Certificate 'restconf.crt' does not exist
Key 'restconf.key' does not exist

EOS marked the profile invalid, management api restconf reported "SSL profile not in valid state", and the Job was long since Complete and never re-ran. Observed on a lab whose host sleeps nightly — the pods restart, and RESTCONF is gone every morning.

v0.5.10 fixed the ordering at install time. It could not fix this, because the defect is not ordering — it is that the config outlives the certificate it points at.

The change

EOS generates a self-signed profile for itself, so pointing RESTCONF at ARISTA_DEFAULT_SELF_SIGNED_PROFILE takes the certificate out of the chart's concerns entirely. The Job and its ConfigMap are deleted.

This is what management api http-commands already did: eAPI names no profile, takes the EOS default, and that is precisely why eAPI on 443 kept working across restarts while RESTCONF did not. RESTCONF now behaves the same way rather than through a mechanism of its own.

ceos.restconfSslProfile is there for anyone who needs a verifiable certificate: configure the profile and name it. Chart-wide, because one startup-config ConfigMap is shared by every cEOS node.

Verification

Tested from a cold boot with no Job in the cluster — the pod was deleted and recreated from the new startup-config:

Enabled: yes
Server: running on port 6020, in default VRF
SSL profile: ARISTA_DEFAULT_SELF_SIGNED_PROFILE

plus a real request between devices returning HTTP 200.

That ordering was the one risk in this change: if the built-in profile were not yet valid when EOS processes the management api restconf line, we would have reproduced the original bug under a different profile name, since EOS never revisits an "invalid" verdict. It is valid in time.

Also checked: ARISTA_SELF_SIGNED.crt has different serial numbers on different devices, so EOS generates it per device rather than shipping it in the image.

Notes

• Behaviour change: the SSL profile on the device changes name. The contract — RESTCONF answering on 6020 — is unchanged.
• Both certificates were self-signed and neither carried a CN matching the Service, so the generated one was no better placed for a client that verifies.
• Removing the Job also removes the three traps it had to work around: an explicit 600s deadline instead of a backoffLimit a slow boot loses, --fail-with-body because curl exits 0 on the HTTP 404 nginx serves during boot, and a test for "result" because eAPI reports a failed command inside an HTTP 200. None are fixed — they stopped being reachable.
• Confirmed on cEOS 4.36.1F. Worth a look on a markedly older image that ARISTA_DEFAULT_SELF_SIGNED_PROFILE exists there too.
• CI installs the srlinux defaults, so the cEOS path is not exercised there — unchanged by this PR, and not closable, since cEOS is licensed and cannot be pulled in Actions.

🤖 Generated with Claude Code