Andrei Kvapil
c8e4d97df9
## What this PR does Bumps ingress-nginx to chart 4.11.5 / controller v1.11.5, and closes the admission webhook to everything except the API server. ### Version bump The shipped `v1.11.2` controller is a cozystack rebuild that **already carries a backport** of the CVE-2025-1974 fix (v0.28.2, March 2025), so this is not a fix for a live vulnerability. The problem is that it reports itself as a plain `v1.11.2 build git-d3bb2b4`: the binary is built from the upstream 1.11.2 tag with the patch applied on top, which does not change the version ldflags, and the image labels are inherited from the `registry.k8s.io` base layer. A patched build is therefore indistinguishable from an unpatched one by anything except its digest, and anything scanning by version string flags it. This bump removes that ambiguity. `packages/system/ingress-nginx` feeds three consumers — the platform ingress, tenant Ingress applications (`extra/ingress`), and the ingress addon of tenant Kubernetes clusters — so one bump covers all three. The protobuf-exporter sidecar moves in lockstep, since its tag tracks the upstream controller version. `CHART_VERSION` is now pinned in the package Makefile. `helm pull` carried no `--version`, so `make update` would have fetched whatever is latest upstream (4.13.9 today) against a controller image that only exists for selected versions. ### Admission webhook policy The webhook is only ever called by the API server, but it was reachable from every pod in the cluster, in any namespace — avoidable attack surface independent of any specific CVE. The new `CiliumNetworkPolicy` is deny-only and disables default-deny. A Cilium rule carrying an ingress section otherwise puts the selected endpoints behind a default-deny, which here would mean enumerating every port the controller serves (80, 443, metrics, the exporter, tcp/udp services) and breaking traffic on the first one missed. Subtracting one port is the safer construction. Two callers are deliberately not denied: * **host-network sources**, which are not Cilium endpoints — this covers a management cluster, where the API server runs on the host network; * **the konnectivity agent**, which is not optional. On a Kamaji-hosted tenant cluster the API server lives outside the cluster and reaches in-cluster webhooks through the konnectivity tunnel (Kamaji defines only the `cluster` egress selection), so the call arrives from the agent pod in `kube-system`, not from the API server address. A `fromEntities: [kube-apiserver]` allow would not match it, and every Ingress create/update in every tenant cluster would start failing. The policy is namespaced rather than clusterwide on purpose: the same package is installed into several namespaces of one cluster, so a cluster-scoped object with a fixed name would collide between releases. It can be disabled with `admissionWebhookPolicy.enabled`. ### Verification Tested on a live Kamaji tenant cluster (k8s 1.35.6, Cilium 1.19), with the addon enabled for the test and disabled afterwards: | | probe from a pod in `default` | Ingress create | |---|---|---| | without policy | `open` | works | | with policy | `Connection timed out` | works | Also confirmed on the management cluster that `kube-apiserver` runs as static pods on the host network, so the host-network carve-out holds there. The package previously ran no unit tests at all; a `test` target is added with 7 assertions covering the policy. It is scoped with `--with-subchart=false` because the vendored chart carries upstream's own suites, which assert upstream defaults and fail under our values. The full `hack/helm-unit-tests.sh` sweep is green. The controller and exporter images are rebuilt by cozystack/ingress-nginx-with-protobuf-exporter#5, which vendors the `11843.diff` patch instead of fetching it from a still-open upstream PR at build time. ### Screenshots Not applicable — no UI changes. ### Downstream repositories Walked the trigger map in `docs/agents/contributing.md` against the diff, which touches `packages/system/ingress-nginx/` and one comment line in `hack/promote-retag.sh`: * **website** — no package added, renamed or removed under `apps/`/`extra/`; no platform component added or removed; no change to `packages/core/platform/values.yaml`, variants, bundles or release assets. The `package Makefiles` trigger was considered because of `CHART_VERSION` and the new `test` target: `CHART_VERSION` does not change the documented contract of `make update`, and `test: helm unittest` is an existing pattern in the repo (`packages/system/cilium-networkpolicy/Makefile`), not new tooling. * **terraform-provider-cozystack** — every trigger is about `packages/apps/`, `values.schema.json`, version enums or `ApplicationDefinition`; none apply to a system package. * **ansible-cozystack** — no change to installer values, platform keys the role sets, variants, waited-on objects or node prerequisites. * **ccp** — `hack/package.mk` and `hack/common-envs.mk` untouched; nothing under `hack/` moved or renamed, and the edit to `hack/promote-retag.sh` is a comment with no behaviour change; layout and namespaces unchanged. * **external-apps-example**, **talm**, **cozyhr**, **cozy-proxy**, **cozystack-telemetry-server**, **examples** — no trigger matches. - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: ### Release note ```release-note feat(ingress-nginx): update to chart 4.11.5 with controller v1.11.5, and restrict the admission webhook so it is reachable only by the API server. The previously shipped v1.11.2 image already contained a backport of the CVE-2025-1974 fix; it reported itself as a stock v1.11.2 build, which this update makes unambiguous. ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added optional network protection for the admission webhook with restricted access rules. * Added PrometheusRule support and improved ServiceMonitor configuration. * Webhook service ports are now configurable. * **Updates** * Upgraded ingress-nginx and controller images to version 4.11.5. * Improved default-backend availability and topology-spread settings. * Added Pod Security Admission guidance and refreshed configuration documentation. * **Bug Fixes** * Corrected webhook service rendering and default-backend disruption budget behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Cozystack
Cozystack is a free platform and framework for building clouds.
Cozystack is a CNCF Sandbox Level Project that was originally built and sponsored by Ænix.
With Cozystack, you can transform a bunch of servers into an intelligent system with a simple REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers, HTTP caching services, and other services with ease.
Use Cozystack to build your own cloud or provide a cost-effective development environment.
Use-Cases
-
Using Cozystack to build a public cloud
You can use Cozystack as a backend for a public cloud -
Using Cozystack to build a private cloud
You can use Cozystack as a platform to build a private cloud powered by Infrastructure-as-Code approach -
Using Cozystack as a Kubernetes distribution
You can use Cozystack as a Kubernetes distribution for Bare Metal
Documentation
The documentation is located on the cozystack.io website.
Read the Getting Started section for a quick start.
If you encounter any difficulties, start with the troubleshooting guide and work your way through the process that we've outlined.
Versioning
Versioning adheres to the Semantic Versioning principles.
A full list of the available releases is available in the GitHub repository's Release section.
Contributions
Contributions are highly appreciated and very welcomed!
In case of bugs, please check if the issue has already been opened by checking the GitHub Issues section. If it isn't, you can open a new one. A detailed report will help us replicate it, assess it, and work on a fix.
You can express your intention to on the fix on your own. Commits are used to generate the changelog, and their author will be referenced in it.
If you have a concrete feature request, open an issue. For a cross-cutting or architectural change, open a design proposal in the community repo. For questions or early ideas, use GitHub Discussions. See CONTRIBUTING.md for the full routing.
Community
You are welcome to join our Telegram group and come to our weekly community meetings. Add them to your Google Calendar or iCal for convenience.
License
Cozystack is licensed under Apache 2.0.
The code is provided as-is with no warranties.
Commercial Support
A list of companies providing commercial support for this project can be found on official site.