> While Consul can be used to store secret information and gate access using ACLs, it is not designed for that purpose. As such, data is not encrypted in transit nor at rest, it does not have pluggable authentication mechanisms, and there is no per-request auditing mechanism.
I guess my question now is why not add E2E encryption on top of Consul/Etcd instead of a whole new system?
It's desirable to keep secret managements simple and as self-contained and self-sufficient as possible. That way, it's much easier to drastically lock it down without impacting normal users too much. Your organization might have, say, 30 people who routinely need access to the orchestration / deployment infrastructure but maybe 3 who need access to cryptovariables.
> While Consul can be used to store secret information and gate access using ACLs, it is not designed for that purpose. As such, data is not encrypted in transit nor at rest, it does not have pluggable authentication mechanisms, and there is no per-request auditing mechanism.
I guess my question now is why not add E2E encryption on top of Consul/Etcd instead of a whole new system?