Anyone else find Aqua's documentation out of date for Kubernetes 1.28+?

> The YAML examples still use the `admissionregistration.k8s.io/v1beta1` API.

No surprise. Aqua's docs have always been a step behind the actual releases. The v1beta1 API was deprecated back in 1.22 and removed in 1.28, so you're not the first to hit this.

You found the right answer yourself - GitHub issues. That's where the current configs live because nobody on their team cares to update the official docs until someone files a ticket. Next time skip the docs and go straight to the issue tracker. Saves you the frustration.

The GitHub issues workaround isn't a scalable solution for the community, and telling people to skip official docs sets a poor precedent.

It creates a fractured support experience where correct information is buried in comment threads instead of being maintained in a single source of truth. That's a vendor process problem, not a user problem.

Have you actually filed a documentation ticket with them, or are you just accepting the broken process?

It's definitely not just you. The v1beta1 to v1 transition has been a common stumbling block for a lot of tools, but it's particularly problematic in security tooling where the install process is critical.

My team ran into this a few weeks back. The workaround we found was to check the actual Helm chart's templates on their artifacthub page, as they're sometimes updated before the prose documentation. It's still not ideal, as you have to reverse-engineer the values from the template, but it's more reliable than the docs.

You should consider reporting the outdated section directly through their documentation portal. Vendors often prioritize tickets that come through official channels over forum chatter.

Checking the Helm chart templates on ArtifactHub is a solid workaround, and you're right that it's more reliable for the actual YAML structure. I've found that approach useful for other tools too, especially when the documentation lags.

The problem I see is that reverse-engineering the values from the template introduces its own risk. For compliance and audit purposes, we're supposed to follow a documented, repeatable procedure. If the official steps are wrong and the correct ones require piecing together from a template and issue tracker comments, that breaks the audit trail. An auditor would rightfully ask where the install procedure is formally documented.

Has your team started logging these documentation gaps internally as part of your change control? We've had to note the discrepancy and the source of the correct config in our runbooks, which feels like a workaround for their broken process.

It's never just you. The v1beta1 API is such a well-known deprecation timeline that any vendor still shipping examples with it is just... not trying.

You went to GitHub issues? That's the modern vendor manual. The docs are a marketing artifact, not a technical one. I bet if you looked at the actual chart you're deploying, it already has the correct v1 API in its templates. This is why I always pull the chart and read the raw Kubernetes manifests before trusting any installation guide. It adds five minutes but saves you the hour you spent digging through comment threads.

I get where you're coming from, and I do the same thing with pulling the chart to inspect the manifests. It's a good habit.

But calling the docs a "marketing artifact" feels a bit cynical and lets the vendor off the hook. If that's truly the case, then the product's quality and support model are being misrepresented. A security tool failing to keep its core installation docs accurate isn't just a process slip, it's a red flag about their diligence. Relying on users to bypass the official guidance because it's wrong creates real operational risk, as another user pointed out.

So while your workaround is practical, I think normalizing it as "the modern vendor manual" is part of the problem.

That "marketing artifact" line hits a nerve because I see it in my world all the time. A CRM's sales page shows beautiful, seamless integrations, but the actual API docs for that workflow are three versions old.

But I think you're both right. It's cynical to accept it as normal, but it's naive to think vendors always prioritize docs over new features. The red flag for me is when the *workaround* becomes the *standard operating procedure* for the whole community. That's when you know the vendor isn't listening, or worse, doesn't have a feedback loop that closes.

If everyone is inspecting the Helm chart instead of reading the guide, the guide has failed. So the question becomes, does Aqua know their docs have failed, or do they just see low support tickets because everyone gave up and went to GitHub?

No, it's not just you. I hit the same thing last month.

Their chart's templates are fine. Docs just rot.

Now I skip the whole "official guide" circus and run:

```
helm pull aqua/whatever --untar
grep -r admissionregistration templates/
```

Takes thirty seconds and you get the actual truth.