I’ll start this blog post with a funny story: my last blog post was an introduction to Kubernetes audits (which I recommend reading before diving into this post). As a continuing post, I wrote about what I thought to be the future of Kubernetes audits – the dynamic backend. Only to find out, a couple of days before publishing my post, that the dynamic backend (also known as the AuditSink API object) was entirely removed.
What was it?
The dynamic backend, first introduced in Kubernetes v1.13, was a third audit backend option. The first two being logging to a file and sending logs to a webhook – both defined via API server flags.
On the other hand, the dynamic backend introduced the ability to define a webhook endpoint dynamically. All you had to do is post the AuditSink object to the API server and you’re done. You could have also modify it at any point in time which was really cool!
The dynamic backend was a Kubernetes alpha feature. The statistics regarding how many Kubernetes features eventually get discarded are unknown to me, but I can guess that this doesn’t happen often. This feature didn’t make it to GA (General Availability), and for me, at a very funny timing.
Why was it removed?
A few days ago, I got a notification from GitHub which stated that the dynamic backend feature has been closed, and will be removed in Kubernetes V1.19.
I asked around the Kubernetes slack channel to understand what happened, and this is the explanation I got:
TL;DR: the feature did not progress for the last 1.5 years since the group responsible for it couldn’t agree on it’s future.
As you can see the removal of this feature happened for two main reasons:
- The logging and webhook backends both use a static policy file. It is supplied, as mentioned above, via an API server flag. As opposed to them, the dynamic backend policy was dynamic. The team leaders tried to understand what was the right approach to implement this but couldn’t reach an agreement. At the time, I also struggled to understand how will that feature work exactly.
- Performance and scalability issues were very common when using this feature. I noted it several times when writing my original post. Part of the issue here was that the policy wasn’t fine grained as it is for the other backends. This caused a lot of performance issue. I guess that behind the scenes this was a lot more complex.
And that was that.
I guess that’s the price you pay when trying to cover the most recent developments in the cloud world.
1 Reply to “The Death Of Kubernetes AuditSink”