Thanks for the thoughtful response. The prescriptive enhancements to Kubernetes (and constituent components) require the correct configuration of not one, but two access control mechanisms which have a dependency on secure component and operator authentication mechanisms. Kubernetes is a really great project but one thing that has been missed from the beginning is any realistic insight into the people and organizations that adopt the tech. The people focused on building these tools are completely lost in their own world. They’re doing great things that seem easy if you are experts in their systems. The reality is that nobody wants to use Kubernetes. What people want is a sane platform that they can quickly setup and maintain over the long haul with minimal effort so that they can do what they actually want. They want to run their software to make money. Configuring an authentication system correctly is difficult. Implementing one access control mechanism is really difficult. Implementing two and maintaining them is a monumental task. Doing all of that en lieu of properly encrypting sensitive data in a database is crazy.
Adding encryption mitigates much of the risk in doing those other difficult things well. The (un)seal keys should be exposed to few actors which both decreases the size of the attack footprint and decreases the complexity of the systems requires to maintain secrecy.
Nobody is using Kubernetes the right way because nobody knows how to use Kubernetes the right way. This isn’t a training issue. Every training issue is a product issue spun by a product owner.
None of these projects / products are perfect. I didn’t expect that they would be. I don’t even think they need to be. What I expect and what I think the community needs to demand is an extreme degree of transparency. The first section on the “secrets” feature page for all of these products should be “risks.” Before telling people how to use the feature they need to be clear what the implementation does and does not protect the users from. Once we have that clarity then we can really let the adopter voice drive criticality of different attack vectors.
I want to make it clear that I’m not lashing Kubernetes for their implementation. Like I said, it is a perfectly fine proof of concept for an abstraction. The big miss on their part was the ridiculous miscommunication. People are putting their livelihoods into Kubernetes hands here. By misleading them Kubernetes is taking a liability here both morally and financially.