Skip to content

Commit 84b7ccf

Browse files
flavioflavio
authored
Merge pull request #406 from viccuad/blog/1.33.0
Add Adm Controller 1.33 release blogpost
2 parents 7621126 + 25c6941 commit 84b7ccf

1 file changed

Lines changed: 222 additions & 0 deletions

File tree

‎content/blog/2026/03/adm-controller-1.33-release.md‎

Lines changed: 222 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,222 @@
1+
---
2+
title: "Admission Controller 1.33 Release"
3+
authors:
4+
- Víctor Cuadrado Juan
5+
date: 2026-03-09
6+
---
7+
8+
The garden is thriving and Kubewarden 1.33 is ready to bloom! Following last
9+
release's big repotting, this one is serious about pruning, including a
10+
security issue. It's not all housekeeping though, fresh flowers are blooming
11+
and come with nice features: BYO-PKI landing in the policy-server, field mask
12+
filtering for context-aware calls, proxy support, and a few more treats. Let's
13+
dig in!
14+
15+
## Security fix: Cross-namespace data access, removal of deprecated API calls
16+
17+
In our [previous
18+
post](https://www.kubewarden.io/blog/2026/02/not-affected-by-cve-2026-22039/)
19+
we explained how our architecture protects namespaced policy users from
20+
privilege escalations. While this still stands, Ville Vesilehto
21+
([thevilledev](https://github.com/thevilledev) on GitHub) found the following
22+
security vulnerability: an attacker with permissions to create
23+
AdmissionPolicies could make use of 3 deprecated host-callbacks
24+
(`kubernetes/ingresses`, `kubernetes/namespaces`, `kubernetes/services`) to
25+
craft a policy that would allow them read access to Ingresses, Namespaces, and
26+
Services resources respectively.
27+
28+
This attack is read-only, there is no write capability and no access to
29+
Secrets, ConfigMaps, or other resource types beyond these three. The attacker
30+
could read, for example:
31+
32+
- Ingresses across all namespaces with hostnames and routing rules.
33+
- Namespace names and labels.
34+
- Services across all namespaces with ClusterIPs and ports to reveal cluster
35+
internal topology.
36+
37+
This security issue has received **CVE-2026-29773**, with score 2.7(low). We thank
38+
Ville for finding this vulnerability and responsible disclosure!
39+
40+
In this release we remove these vulnerable and already-deprecated host-callback
41+
API calls (`kubernetes/ingresses`, `kubernetes/namespaces`, `kubernetes/services`).
42+
The removed calls were not being used by any Kubewarden SDK.
43+
44+
These host-callbacks had already long been superseded by
45+
`kubewarden/kubernetes/list_resources_by_namespace`,
46+
`kubewarden/kubernetes/list_resources`, and
47+
`kubewarden/kubernetes/get_resource`. They provide similar capabilities while
48+
being more granular, performant, and gated through our context-aware permissions
49+
feature. These current host-capabilities are part of the Kubernetes capabilities
50+
listed in our [documentation](https://docs.kubewarden.io/reference/spec/host-capabilities/kubernetes).
51+
52+
## Deprecation of `wgk8spolicy.io` in favour of OpenReports
53+
54+
Since `v1.30` [we have optionally supported
55+
OpenReports](https://www.kubewarden.io/blog/2025/10/kubewarden-1.30-release/)
56+
as an output report format of our Audit Scanner. In that release we marked the
57+
`wgk8spolicy.io` PolicyReports CRDs as deprecated, but we kept installing them
58+
by default.
59+
60+
With this release, we are defaulting to OpenReports instead. The CRDs for
61+
`wgk8spolicy.io` PolicyReports are not installed by default anymore by the
62+
`kubewarden-crds`, only the new OpenReports. The Audit Scanner is configured to
63+
produce OpenReports by default now.
64+
65+
Users wishing to maintain the previous behavior need to:
66+
67+
- Change the `kubewarden-crds` Helm chart value of
68+
`.Values.install.installPolicyReportCRDs` to `true`.
69+
- Change the `kubewarden-controller` Helm chart value of
70+
`.Values.auditScanner.reportCRDsKind` from `openreports` to `policyreport`.
71+
72+
Old existing `wgk8spolicy.io` reports CRs will be removed when performing the
73+
upgrade, as the CRDs for them are removed. In the case that the user had
74+
installed the `wgk8spolicy.io` CRDs by other means, if the Audit Scanner is
75+
configured to create OpenReports (the new default), upon each scan, it performs
76+
a one-time cleanup of old `wgk8spolicy.io` PolicyReports and
77+
ClusterPolicyReports that were created by Kubewarden. This cleanup is
78+
performant.
79+
80+
In a future release, the option to create `wgk8spolicy.io` PolicyReports
81+
and their optional CRDs installation will both be removed.
82+
83+
The included sub-chart for policy-reporter already supports OpenReports and
84+
continues to function for both the deprecated `wgk8spolicy.io`
85+
PolicyReports and OpenReports without any reconfiguration.
86+
87+
## Support for custom Sigstore trust roots and BYO-PKI in policy-server
88+
89+
Since `v1.31` release, [`kwctl` accepts the new Sigstore ClientTrustConfig
90+
format](https://www.kubewarden.io/blog/2025/11/kubewarden-1.31-release/), also
91+
know as "Bring Your Own PKI (BYO-PKI)". This allows to consume a single JSON
92+
configuration file with all the certificates, URLS and information to perform
93+
Sigstore signing and verifications.
94+
95+
For this release, we have enhanced `policy-server` with the same feature. Users
96+
that want to use PolicyServers against their own custom Rekor and Fulcio
97+
services (like those inside an air-gap) can now set the PolicyServer
98+
`spec.sigstoreTrustConfig` to the name of a ConfigMap that contains this JSON
99+
configuration.
100+
101+
The ConfigMap must contain the JSON in a key named `sigstore-trust-config`, and
102+
it must be in the same Namespace as the PolicyServer.
103+
104+
For the default PolicyServer, installed via the `kubewarden-defaults` Helm chart,
105+
the ConfigMap name can be configured via its `.Values.sigstoreTrustConfig`.
106+
107+
Have a read at our new [documentation
108+
page](https://docs.kubewarden.io/howtos/policy-servers/private-sigstore) on how
109+
to configure this feature.
110+
111+
## Field mask filtering for Kubernetes context aware calls
112+
113+
When policies perform queries about Kubernetes resources via context-aware
114+
calls, the resulting object may be particularly big, and sometimes the policy
115+
author only cares about a subset of the data. For example, a policy reasoning
116+
about Pods may only be interested in the `spec.containers.image` and not the
117+
full Kubernetes object, with its versions and fields.
118+
119+
To improve performance, we have enhanced our Kubernetes context aware calls
120+
with an optional `field_masks` field that prunes the Kubernetes resource to
121+
contain _only_ the specified fields.
122+
123+
Our [image-cve-policy](https://artifacthub.io/packages/kubewarden/kubewarden-policy-library/image-cve-policy),
124+
exercised by our SBOMscanner project, now makes use of this feature. This
125+
reduces its memory usage and serialization overhead when it processes
126+
VulnerabilityReport CRs, as they can be quite big and the policy doesn't need
127+
the whole of it.
128+
129+
### Updated SDKs and cel-policy
130+
131+
We have enhanced our Policy SDKs to expose this new field mask feature. Policy
132+
SDK authors can also find this new `field_masks` input field in the Kubernetes
133+
[host-calls](https://docs.kubewarden.io/next/reference/spec/host-capabilities/kubernetes#operation---list_resources_all).
134+
135+
In addition, we have enhanced our
136+
[cel-policy](https://artifacthub.io/packages/kubewarden/kubewarden-policy-library/cel-policy),
137+
and exposed this feature as a native CEL function, `<Client>.fieldMask(<string>)`.
138+
You can read more in the [go CEL docs](https://github.com/kubewarden/policies/blob/main/policies/cel-policy/internal/cel/library/kubernetes.go#L70-L90)
139+
of the policy.
140+
141+
As an example, the following CEL code returns the `nginx` Pod with only its
142+
`metadata.labels` field:
143+
144+
```cel
145+
kw.k8s.apiVersion('v1').kind('Pod').namespace('default').fieldMask('metadata.labels').get('nginx')
146+
```
147+
148+
This new `.fieldMask()` function can be called multiple times to add several
149+
field paths to the mask. For example, this returns a list of Pod resources with
150+
only their `metadata.name` and `medata.namespace` fields:
151+
152+
```cel
153+
kw.k8s.apiVersion('v1').kind('Pod').fieldMask('metadata.name').fieldMask('metadata.namespace').list()
154+
```
155+
156+
## Configuring policies to run in the kubewarden namespace
157+
158+
By default, the Kubewarden admission controller is configured so _all policies_
159+
pass in the namespace in which the controller is running (usually, `kubewarden`).
160+
161+
This prevents the user from locking the cluster if they misconfigure policies,
162+
or interfering with the PolicyServers there. For example, expecting _all_
163+
container images to be signed by Issuer `my.corp` would make the Deployment of
164+
the Kubewarden Admission Controller eventually fail, as its container images
165+
are signed by the Kubewarden team. Or mutating PolicyServers, which may affect
166+
not only their desired PolicyServers but others.
167+
168+
In some cases though, users may want to run policies in the namespace of the
169+
Admission Controller, for example if aiding resource allocation or preventing
170+
core namespaces from being modified.
171+
172+
For those really unusual cases, cluster operators can now deploy Kubewarden
173+
policies to also apply to the Admission Controller namespace by doing the following:
174+
175+
- Configure the Admission Controller to accept AdmissionReviews for policies in
176+
the controller namespace by setting the `kubewarden-controller` Helm chart
177+
values `.Values.alwaysAcceptAdmissionReviewsOnDeploymentsNamespace` to `false`.
178+
This means that both clusterwide and namespaced policies may apply to the
179+
namespace where the Deployments for the controller and PolicyServers are.
180+
- If deploying clusterwide policies, do so with their new
181+
`spec.allowInsideAdmissionControllerNamespace`to `true`.
182+
183+
We expect cluster operators to rarely use this feature. We
184+
recommend caution when doing so. If interested, you can see our [documentation
185+
page](https://docs.kubewarden.io/howtos/policies-eval-resources-in-controller-namespace)
186+
for it.
187+
188+
## Proxy configuration
189+
190+
Both `kwctl` and `policy-server` support now proxy configuration via either the
191+
usual environment variables `HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY` (and their
192+
lowercase counterparts), or via the `sources.yaml` file.
193+
194+
This proxy configuration routes policy pulling and pushing, as well as those
195+
context-aware capabilities that make use of the network, such as obtaining an OCI
196+
image digest or Sigstore operations. Read more about it in our
197+
[how-to](https://docs.kubewarden.io/howtos/proxy-configuration) docs.
198+
199+
## Versioning of the policy-server cert Secret
200+
201+
Starting with this release, the Secret that contains the PolicyServer
202+
certificate is now versioned via an annotation, to ease maintenance and
203+
future migrations. This means that on first install/upgrade of this release,
204+
the Secret and certificate will be automatically recreated to match this new
205+
scheme. This doesn't affect users.
206+
207+
## Monorepo cleanup continues
208+
209+
Our monorepo is sailing strong, and we couldn't be happier!
210+
211+
We have restored test coverage submission for our Rust crates, which brings us
212+
back to [our usual ~80%
213+
coverage](https://app.codecov.io/github/kubewarden/kubewarden-controller). We
214+
also have automation back for Rust toolchain updates, spell checking,
215+
contribution docs, and a general cleanup.
216+
217+
# Getting in touch
218+
219+
Join the conversation on
220+
[Slack](https://kubernetes.slack.com/?redir=%2Fmessages%2Fkubewarden) or
221+
[GitHub discussions](https://github.com/orgs/kubewarden/discussions) and let us
222+
know how you’re finding Kubewarden 1.33!

0 commit comments

Comments
 (0)