#agenix decrypts the .age file → feeds the #secretbox key to kube-apiserver → apiserver uses it for etcd. The failure happened at the agenix layer (wrong key in the .age file), not in secretbox itself.
RBAC defeats: A compromised pod, a stolen kubeconfig, a rogue user — anyone who tries to read secrets through the Kubernetes API without sufficient permissions. They hit the apiserver, RBAC says no, they get a 403.
secretbox defeats: Someone who bypasses the API entirely — steals the etcd data directory, takes an etcd snapshot from a backup, reads etcd directly over its client port without going through kube-apiserver. RBAC never runs in this scenario because the attacker never talked to kube-apiserver.
The critical insight: secretbox does nothing if the attacker has API access, and RBAC does nothing if the attacker has disk access. They cover completely non-overlapping attack surfaces.
problem hit here would have been identical with #SQLite — the encryption layer is in kube-apiserver, not in the storage backend. But the operational simplicity of SQLite would have made recovery easier since inspecting and backing up the database is much more straightforward than #etcd snapshot management.
#kubernetes