Skip to content

test: prove Crossplane mutate-existing target evaluation with correct Cilium discovery #3633

Description

@devantler

🤖 Generated by the Agentic Engineer

Problem

The Crossplane egress regression's mutate-existing widening fixture currently exits nonzero because the offline Kyverno CLI cannot discover its CiliumNetworkPolicy target. That is fail-closed, but it does not prove that the target was mutated and the resulting spec was rejected by the egress contract. A benign target mutation cannot currently provide the corresponding positive control either.

This is separate from #3632's Kyverno 1.19 compatibility repair, which removes a duplicate registration of the same object through both --resource and --target-resource. The deployed policy and the existing egress verdict guards remain unchanged.

Verified synthetic reproduction

With Kyverno 1.19.0, create these files:

namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test

target.yaml:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: example-egress
  namespace: policy-test
spec:
  endpointSelector: {}
  egress: []

policy.yaml:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: mutate-existing-example
spec:
  rules:
  - name: mark-target
    match:
      resources:
        kinds: [Namespace]
        names: [policy-test]
    mutate:
      targets:
      - apiVersion: cilium.io/v2
        kind: CiliumNetworkPolicy
        name: example-egress
        namespace: policy-test
      patchStrategicMerge:
        metadata:
          labels:
            example.com/reviewed: "true"

Run this entirely offline; no cluster, registry access, or credentials are needed:

kyverno apply policy.yaml --resource namespace.yaml \
  --target-resource target.yaml --output mutated --remove-color

Expected: the rule passes and the emitted CiliumNetworkPolicy target has the reviewed label. Observed: exit 1, a target lookup error ending in : not found, and pass: 0, fail: 0, warn: 0, error: 1, skip: 0. The CLI also prints a generic mutation-success message before the error; that message is not evidence of target evaluation.

Kyverno 1.19 creates its offline client from all supplied input objects using Kubernetes' kind-to-resource pluralization. However, fakeDiscoveryClient.FindResources at v1.19.0 derives the lookup key with lower(kind) + "s". CiliumNetworkPolicy is therefore queried as ciliumnetworkpolicys while the input is registered as ciliumnetworkpolicies by createFakeClientFromResources. The target loader uses that discovery path. Supplying a correct CiliumNetworkPolicy CRD through the supported --crd-paths flag also reproduced the lookup failure; it does not replace this fake-discovery mapping.

The existing Platform fixture also returned an engine lookup error on the previous 1.18.2 CLI. Do not describe that older error as a correctly evaluated negative verdict.

Acceptance criteria

  • Find a supported offline engine/discovery path that preserves the actual CiliumNetworkPolicy kind, API version, namespace, and correct plural; if an upstream Kyverno fix is required, track it and consume the verified release.
  • Add a positive mutate-existing control with a real Namespace trigger and real CiliumNetworkPolicy target. Require the named rule to pass with zero engine errors and assert on the emitted target object, including its exact identity and expected harmless mutation.
  • Add a widening mutation of the same real target and prove it fails specifically at the egress spec verdict after successful mutation evaluation. A missing target, skipped/excluded rule, parse failure, discovery error, or generic nonzero CLI exit must not satisfy this negative control.
  • Preserve admission-time mutation coverage, the original generated-policy constraints, all deployed manifests, and the fail-closed response to engine errors. Do not rename the real target kind or relax the egress contract to make a fixture pass.
  • Validate with the CI-pinned Kyverno version and keep the reproduction deterministic, offline, and free of production render data.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions