fix: atenet-egress emptyDir limits and oauth2-proxy registry on 4.x #880

Activity

1. teemow commented on Oct 9, 2026

   

   teemow

   on Oct 9, 2026

   MemberAuthor

   More actions

   Seen again on an installation cut over tonight (written by an agent): the Kyverno audit findings on 4.x this issue covers.
2. teemow

   closed this as completedin #912on Oct 10, 2026
3. teemow commented on Oct 10, 2026

   

   teemow

   on Oct 10, 2026

   MemberAuthor

   More actions

   Fixed by giantswarm/agent-platform#912 (b70de289), released as v4.124.1-rc.2; the Substrate half is giantswarm/substrate#255 (9246909a, released as 1.8.0-rc.4). The egress bound is the chart's own from Substrate 1.8.0 on (atenetEgress.resources, atenetEgress.extProc.resources, atenetEgress.drainSignal.sizeLimit); below that floor the meta chart applies it as one kustomize strategic-merge patch on the substrate HelmRelease, retired at the re-pin. kagent's oauth2-proxy runs gsoci.azurecr.io/giantswarm/oauth2-proxy:v7.15.5, the mirror of the subchart's default at the same digest.

   Proof so far (an agent's):

   • Render, helm template with the chart's defaults: the substrate HelmRelease carries the patch — agentgateway and ext-proc requests.ephemeral-storage: 16Mi, limits.ephemeral-storage: 256Mi, drain-signal emptyDir.sizeLimit: 16Mi; the kagent HelmRelease values oauth2-proxy.image: {registry: gsoci.azurecr.io, repository: giantswarm/oauth2-proxy, tag: v7.15.5}.
   • The patch through kubectl kustomize on the substrate chart 1.6.2 and 1.7.0 rendered with the forwarded values: both containers bounded, the emptyDir with its sizeLimit, images unchanged. The published 1.8.0-rc.4 renders the bound by itself, and the meta chart pinned to it renders no patch.
   • make verify-substrate-egress-ephemeral-storage: the substrate chart 1.7.0 (below 1.8.0) fails require-emptydir-requests-and-limits by itself and passes with the HelmRelease's patch merged by name; the three knobs null render no patch. make verify-kagent-oauth2-proxy-image: kagent 1.6.0 bundles oauth2-proxy chart 10.7.1 (appVersion 7.15.5); the pin is its gsoci copy and is published.
   • Live, a test installation on 4.x with Kyverno, read-only, before the candidate: kubectl get policyreports -n ate-system — Deployment atenet-egress FAIL 1, require-emptydir-requests-and-limits/autogen-check-emptydir-requests-limits … failed at path /resources/limits/; -n kagent — Deployment kagent-oauth2-proxy and its ReplicaSets FAIL 1, restrict-image-registries/autogen-validate-registries … failed at path /spec/template/spec/containers/0/image/.

   Acceptance of the roll: the installation follows this chart's release candidates through its GitOps range; once v4.124.1-rc.2 runs there, kubectl get policyreports -n ate-system and -n kagent show no failure for the two Deployments. The result follows in this thread.
4. teemow commented on Oct 10, 2026

   

   teemow

   on Oct 10, 2026

   MemberAuthor

   More actions

   Live result, two test installations on 4.x with Kyverno, after v4.124.1-rc.2 rolled there through their GitOps ranges (meta chart, substrate and kagent releases Ready; read-only, an agent's read at 13:14Z):

   • Deployment ate-system/atenet-egress runs agentgateway and ext-proc with requests.ephemeral-storage: 16Mi, limits.ephemeral-storage: 256Mi and drain-signal as emptyDir: {sizeLimit: 16Mi} (the substrate HelmRelease's postRenderer, Substrate 1.7.0 on both). The reports of the objects created by the roll are clean: Pod atenet-egress-… PASS 20 FAIL 0 and ReplicaSet atenet-egress-… PASS 19 FAIL 0 on both installations. The Deployment-scoped report still carries its pre-roll entry (require-emptydir-requests-and-limits, timestamps 10:14Z and 10:03Z, before the roll) and the ten retired ReplicaSets keep theirs: Kyverno's reports controller rescans in the background (--backgroundScanInterval=1h, two workers), so the Deployment entry refreshes at its next pass. Acceptance of that entry: the next read on these installations shows Deployment atenet-egress FAIL 0.
   • Deployment kagent/kagent-oauth2-proxy runs gsoci.azurecr.io/giantswarm/oauth2-proxy:v7.15.5; its report is PASS 23 FAIL 0 (PASS 22 FAIL 0 on the second installation), the new Pod's and ReplicaSet's FAIL 0 — restrict-image-registries no longer reports it. Only the retired ReplicaSets' reports keep the old finding until the revision history prunes them.
5. teemow commented on Oct 10, 2026

   

   teemow

   on Oct 10, 2026

   MemberAuthor

   More actions

   Last read (an agent's, 12:00Z), the two test installations, after Kyverno's hourly background pass had rescanned the Deployment atenet-egress report (the other policies' entries now stamped 11:39Z and 11:52Z): the require-emptydir-requests-and-limits entry still carries its pre-roll result and timestamp (10:14Z, 10:03Z). The previous comment's acceptance line does not hold as written, and the entry is not a re-evaluated failure: the rule's context lists only emptyDir volumes without a sizeLimit, so a Deployment whose drain-signal carries one yields no result for the rule at all, and Kyverno keeps the entry it had instead of dropping it. Reproduced locally with kyverno apply (CLI 1.19.1) against the live ClusterPolicy: the live Deployment and Pod produce no row, a retired ReplicaSet with the old template reproduces the FAIL.

   Live on both installations: drain-signal is emptyDir: {sizeLimit: 16Mi}, agentgateway and ext-proc run with requests.ephemeral-storage: 16Mi and limits.ephemeral-storage: 256Mi; the current Pod's and ReplicaSet's reports are FAIL 0. Deployment kagent/kagent-oauth2-proxy runs gsoci.azurecr.io/giantswarm/oauth2-proxy:v7.15.5, its report FAIL 0 on both.

   Standing: every FAIL left for these two workloads is the retained Deployment entry or a retired, zero-replica ReplicaSet; no running object fails. The retained entry is a Kyverno reporting matter (the policy's context and the reports controller's merge), handed to the policies' owners separately; this issue stays closed on the live objects.