# Serves: R-SEC-02 (CI holds no broad cluster access)
#
# THIS POLICY IS THE SECURITY BOUNDARY. The RBAC in conformance/incluster/rbac.yaml is not.
#
# Kubernetes places NO `use` check on a Pod/Job's `serviceAccountName`. Any principal that can
# `create jobs` in namespace `conformance` can therefore create a Job that runs as
# `conformance-runner` — a privileged SA (nodes/patch, pods/exec, namespaces/patch) — with an
# arbitrary command. So the CI trigger credential, however narrow its own Role looks, IS the
# privileged identity unless something constrains the SHAPE of what it may create.
#
# That is what this does: for Jobs created by `conformance-trigger` ONLY, admit exactly the
# committed conformance run and deny everything else. The operator chose this model
# (docs/plans/l2-l3-conformance-ci-wiring.md §4, primary model) over the zero-credential
# GitOps-native alternative.
#
# ENFORCE AND FAIL-CLOSED, NOT SUBSTITUTED. Note this does NOT use
# ${KYVERNO_VALIDATION_ACTION} like the other admission policies: a security boundary that an
# environment overlay can downgrade to Audit is not a boundary. `failurePolicy: Fail` means a
# Kyverno outage blocks conformance Jobs rather than silently admitting unconstrained ones.
# Blocking CI is the correct failure direction here; admitting arbitrary privileged code is not.
#
# SCOPE: it constrains ONLY `conformance-trigger`. Jobs created by humans, by Flux, or by any
# other SA are untouched — so a broken policy cannot wedge the rest of the cluster.
#
# IMAGE PINNING — HONEST LIMIT, READ BEFORE RELYING ON THIS. The plan specifies pinning the
# exact `CONFORMANCE_RUNNER_IMAGE` digest. That image does not exist yet, so this enforces the
# enforceable half: the image must live under the conformance repository path AND be
# digest-pinned (`@sha256:`), never a mutable tag. Residual surface: anyone who can PUSH to that
# registry path could publish a different digest. TIGHTEN THIS when the image is built by
# replacing the `image` pattern below with the literal digest — a one-line change, reviewed in a
# PR, which is exactly where a change to the security boundary belongs.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: conformance-trigger-job-shape
  annotations:
    policies.kyverno.io/title: Constrain what the conformance CI trigger may create
    policies.kyverno.io/category: Supply chain
    policies.kyverno.io/severity: critical
    homelab.keithjackson.dev/requirements: R-SEC-02
    homelab.keithjackson.dev/scope: admission-only
spec:
  validationFailureAction: Enforce
  failurePolicy: Fail
  background: false
  rules:
    - name: trigger-may-create-only-the-committed-conformance-run
      # resources AND subjects in the SAME filter entry — that is how Kyverno ANDs them.
      # As two separate `all` entries it is a schema error ("match resources not specified")
      # and the whole policy loads as INVALID, which the CLI reports as a SKIP.
      match:
        all:
          - resources:
              kinds:
                - Job
              namespaces:
                - conformance
            subjects:
              - kind: ServiceAccount
                name: conformance-trigger
                namespace: conformance
      validate:
        message: >-
          conformance-trigger may create ONLY the committed conformance run: a single container,
          digest-pinned conformance-runner image, serviceAccountName conformance-runner,
          command ["./run.sh"], no host namespaces, non-root with privilege escalation disabled,
          and only the `workspace` and `results` volumes. See
          platform/kyverno/admission/conformance-trigger-job-shape.yaml.
        pattern:
          spec:
            template:
              spec:
                serviceAccountName: conformance-runner
                =(hostNetwork): "false"
                =(hostPID): "false"
                =(hostIPC): "false"
                containers:
                  - image: "gitea.home.keithjackson.dev/home-network/conformance-runner@sha256:*"
                    command:
                      - "./run.sh"
                    securityContext:
                      runAsNonRoot: true
                      allowPrivilegeEscalation: false
                      =(privileged): "false"

    - name: trigger-volumes-must-be-workspace-or-results
      # resources AND subjects in the SAME filter entry — that is how Kyverno ANDs them.
      # As two separate `all` entries it is a schema error ("match resources not specified")
      # and the whole policy loads as INVALID, which the CLI reports as a SKIP.
      match:
        all:
          - resources:
              kinds:
                - Job
              namespaces:
                - conformance
            subjects:
              - kind: ServiceAccount
                name: conformance-trigger
                namespace: conformance
      validate:
        message: >-
          conformance-trigger Jobs may mount only the `workspace` and `results` volumes. An extra
          volume is how a constrained pod reaches a host path, a secret, or another SA's token.
        # foreach, NOT a `pattern` list: a Kyverno array pattern asserts "at least one element
        # matches", which would happily admit a Job carrying `workspace` PLUS a hostPath. This
        # asserts EVERY volume is one of the two allowed names.
        foreach:
          - list: "request.object.spec.template.spec.volumes"
            deny:
              conditions:
                all:
                  - key: "{{ element.name }}"
                    operator: AnyNotIn
                    value: ["workspace", "results"]

    - name: trigger-args-must-be-the-committed-flags
      # resources AND subjects in the SAME filter entry — that is how Kyverno ANDs them.
      # As two separate `all` entries it is a schema error ("match resources not specified")
      # and the whole policy loads as INVALID, which the CLI reports as a SKIP.
      match:
        all:
          - resources:
              kinds:
                - Job
              namespaces:
                - conformance
            subjects:
              - kind: ServiceAccount
                name: conformance-trigger
                namespace: conformance
      validate:
        message: >-
          conformance-trigger Job args may contain only the conformance run's own flags
          (--layer, --requirements, --include-scope, --strict-coverage) and their plain values.
          Anything else — a shell, a path, a redirect — is denied.
        foreach:
          - list: "request.object.spec.template.spec.containers[0].args"
            deny:
              conditions:
                all:
                  - key: "{{ regex_match('^(--layer|--requirements|--include-scope|--strict-coverage|[A-Za-z0-9][A-Za-z0-9,._-]*)$', element) }}"
                    operator: Equals
                    value: false

    # =========================================================================================
    # ADDED 2026-09-29 — THE THREE RULES ABOVE WERE BYPASSABLE VIA `initContainers`.
    #
    # Every rule above reads `spec.template.spec.containers` (rule 1's pattern, rule 3's
    # `containers[0].args`) or `volumes` (rule 2). NONE of them read `initContainers`. So the
    # exact escalation this policy exists to stop — the privileged `conformance-runner` SA
    # executing an arbitrary command, because Kubernetes places no `use` check on
    # `serviceAccountName` — was reachable one field over, with `containers[0]` left fully
    # compliant. MEASURED with the pinned CLI (kyverno v1.19.0) before this rule existed:
    #
    #   a Job with serviceAccountName conformance-runner and an initContainer
    #   `docker.io/library/alpine:latest`, `privileged: true`, running `kubectl get secrets -A`
    #     ->  pass: 3, fail: 0, warn: 0, error: 0, skip: 0        # ADMITTED
    #
    # `=(privileged): "false"` in rule 1 only ever applied to `containers[0]`.
    #
    # WHY THIS PINS A PATH IN THE IMAGE RATHER THAN VETTING A SCRIPT. An init container IS
    # needed — the suite has to be cloned at the commit under test. But while the clone logic
    # lived inline as `command: ["/bin/bash","-c"]` + `args: [<script>]`, no policy could tell
    # the committed script from an attacker's: both are just `args` on a shell. So the clone
    # logic moved into the runner image at a fixed path
    # (conformance/incluster/conformance-clone -> /usr/local/bin/conformance-clone) and this
    # rule pins `command` to that path with NO args. An admitted init container therefore
    # carries no caller-supplied code at all — only the commit SHA, in env, which the entrypoint
    # itself validates against ^[0-9a-f]{40}$.
    #
    # `deny` conditions rather than a `pattern`: a Kyverno array pattern asserts "at least one
    # element matches", which would admit the committed clone step PLUS an arbitrary second
    # init container — the same class of hole rule 2's comment describes for volumes.
    # =========================================================================================
    - name: trigger-initcontainers-must-be-the-committed-clone-step
      # resources AND subjects in the SAME filter entry — that is how Kyverno ANDs them.
      # As two separate `all` entries it is a schema error ("match resources not specified")
      # and the whole policy loads as INVALID, which the CLI reports as a SKIP.
      match:
        all:
          - resources:
              kinds:
                - Job
              namespaces:
                - conformance
            subjects:
              - kind: ServiceAccount
                name: conformance-trigger
                namespace: conformance
      validate:
        message: >-
          conformance-trigger Jobs may carry at most ONE initContainer, and it must be the
          committed clone step: the digest-pinned conformance-runner image,
          command ["/usr/local/bin/conformance-clone"], NO args, non-root, no privilege
          escalation, not privileged. An initContainer running a shell with a caller-supplied
          script is arbitrary code execution as the privileged conformance-runner SA — the
          escalation the rest of this policy exists to prevent. See
          conformance/incluster/conformance-clone.
        foreach:
          - list: "request.object.spec.template.spec.initContainers"
            deny:
              conditions:
                any:
                  # At most one. The committed run needs exactly one clone step; a second
                  # init container has no legitimate purpose and is how you smuggle one in.
                  - key: "{{ length(request.object.spec.template.spec.initContainers) }}"
                    operator: GreaterThan
                    value: 1
                  # Digest-pinned under the conformance repository path — same rule as
                  # containers[0], same honest limit (see IMAGE PINNING in the header).
                  - key: "{{ regex_match('^gitea\\.home\\.keithjackson\\.dev/home-network/conformance-runner@sha256:.+$', element.image) }}"
                    operator: Equals
                    value: false
                  # The baked-in entrypoint, exactly — not a shell, not a second path.
                  # `join` so this compares a STRING: Equals/NotEquals on arrays is not
                  # dependable, and `["/bin/sh","-c",...]` must not pass by matching element 0.
                  - key: "{{ join(' ', not_null(element.command, `[]`)) }}"
                    operator: NotEquals
                    value: "/usr/local/bin/conformance-clone"
                  # NO ARGS. This is the whole point: args on an init container are
                  # caller-supplied code. Only env may be passed, and the entrypoint validates it.
                  - key: "{{ length(not_null(element.args, `[]`)) }}"
                    operator: GreaterThan
                    value: 0
                  # not_null(), NOT `||`: JMESPath treats `false` as falsy, so
                  # `element.securityContext.allowPrivilegeEscalation || `true`` would rewrite
                  # the COMPLIANT value false into true and deny every good Job.
                  - key: "{{ not_null(element.securityContext.runAsNonRoot, `false`) }}"
                    operator: NotEquals
                    value: true
                  - key: "{{ not_null(element.securityContext.allowPrivilegeEscalation, `true`) }}"
                    operator: NotEquals
                    value: false
                  - key: "{{ not_null(element.securityContext.privileged, `false`) }}"
                    operator: NotEquals
                    value: false

    # =========================================================================================
    # ADDED 2026-09-29, same review as the rule above: `ephemeralContainers` is the third
    # container list on a PodSpec, and it was as unread as `initContainers` was.
    #
    # Upstream Kubernetes is BELIEVED to reject `ephemeralContainers` in a Job's pod template
    # (the field is settable only through the `pods/ephemeralcontainers` subresource), which
    # would make this rule dead weight. THAT WAS NOT VERIFIED against this cluster, and
    # "probably rejected upstream" is not a boundary. The rule costs one condition, is a no-op
    # when the field is absent, and removes the need to be right about it. If the API server
    # does reject it, nothing changes; if it does not, this is the same hole again.
    # =========================================================================================
    - name: trigger-may-not-declare-ephemeral-containers
      # resources AND subjects in the SAME filter entry — see the note on the rules above.
      match:
        all:
          - resources:
              kinds:
                - Job
              namespaces:
                - conformance
            subjects:
              - kind: ServiceAccount
                name: conformance-trigger
                namespace: conformance
      validate:
        message: >-
          conformance-trigger Jobs may not declare ephemeralContainers. The committed
          conformance run has no use for one, and an ephemeral container is a third container
          list running as the privileged conformance-runner SA with an arbitrary command.
        deny:
          conditions:
            all:
              - key: "{{ length(not_null(request.object.spec.template.spec.ephemeralContainers, `[]`)) }}"
                operator: GreaterThan
                value: 0

    # =========================================================================================
    # ADDED 2026-09-29 — `env` WAS THE NEXT UNREAD FIELD, and it is the same mistake a third time.
    #
    # The pattern is now unmistakable: this policy pins `command` and `args`, so injection moves
    # to whatever adjacent field nobody enumerated. It was `initContainers`, then
    # `ephemeralContainers`, and `env` was still wide open — an admitted Job could set ANY
    # environment variable on either container.
    #
    # That is not hypothetical. Both programs the Job runs read their environment:
    #   * /usr/local/bin/conformance-clone takes CONFORMANCE_GIT_SHA, and accepts
    #     CONFORMANCE_REPO_URL / CONFORMANCE_SRC only when they EQUAL the values baked into the
    #     image (it dies on a mismatch rather than honouring a redirect — which is why the
    #     specific "clone an attacker's repo and run its ./run.sh as conformance-runner" path is
    #     already closed there, in the image, not here);
    #   * run.sh takes CONF_ARTIFACTS and CONF_EMIT_ARTIFACTS_TGZ.
    # And bash itself takes BASH_ENV, which it sources before a non-interactive script — so
    # `command: ["./run.sh"]` plus one env var is enough to change what actually executes.
    # Defence in depth belongs here too: the entrypoint's own validation should not be the only
    # thing standing between a caller-chosen env var and the privileged SA.
    #
    # NOT CONSTRAINED, and deliberately: the VALUES, and which Secret a `valueFrom` reads.
    # Values are legitimately environment-specific (TMPDIR/HOME differ by image), and
    # conformance-runner can already read Secrets in this namespace via its own RBAC, so
    # pinning the source Secret would buy nothing. Names are the vector that matters, because a
    # name is what a program keys its behaviour on.
    # =========================================================================================
    - name: trigger-env-names-must-be-the-committed-set
      # resources AND subjects in the SAME filter entry — see the note on the rules above.
      match:
        all:
          - resources:
              kinds:
                - Job
              namespaces:
                - conformance
            subjects:
              - kind: ServiceAccount
                name: conformance-trigger
                namespace: conformance
      validate:
        message: >-
          conformance-trigger Jobs may set only the committed environment variables. The runner
          container may set CONF_ARTIFACTS, CONF_EMIT_ARTIFACTS_TGZ, TMPDIR and HOME; the clone
          init container may set CONFORMANCE_GIT_SHA, CONFORMANCE_REPO_URL, CONFORMANCE_SRC,
          GITEA_USERNAME, GITEA_TOKEN, TMPDIR and HOME. An arbitrary env var changes what the
          pinned command does — BASH_ENV alone is arbitrary code execution as the privileged
          conformance-runner SA. Widening this list is a reviewed one-line change.
        foreach:
          - list: "request.object.spec.template.spec.containers[0].env"
            deny:
              conditions:
                all:
                  - key: "{{ element.name }}"
                    operator: AnyNotIn
                    value:
                      - CONF_ARTIFACTS
                      - CONF_EMIT_ARTIFACTS_TGZ
                      - TMPDIR
                      - HOME
          # Flattened across init containers: the rule above already caps them at one, but this
          # must not silently stop checking if that cap is ever relaxed.
          - list: "request.object.spec.template.spec.initContainers[].env[]"
            deny:
              conditions:
                all:
                  - key: "{{ element.name }}"
                    operator: AnyNotIn
                    value:
                      - CONFORMANCE_GIT_SHA
                      - CONFORMANCE_REPO_URL
                      - CONFORMANCE_SRC
                      - GITEA_USERNAME
                      - GITEA_TOKEN
                      - TMPDIR
                      - HOME

    - name: trigger-may-not-use-envfrom
      # resources AND subjects in the SAME filter entry — see the note on the rules above.
      match:
        all:
          - resources:
              kinds:
                - Job
              namespaces:
                - conformance
            subjects:
              - kind: ServiceAccount
                name: conformance-trigger
                namespace: conformance
      validate:
        message: >-
          conformance-trigger Jobs may not use envFrom. It injects an entire ConfigMap or Secret
          as environment variables, whose KEYS are not visible in the Job at all — which would
          make the env-name allowlist above unenforceable by inspection.
        deny:
          conditions:
            any:
              - key: "{{ length(not_null(request.object.spec.template.spec.containers[0].envFrom, `[]`)) }}"
                operator: GreaterThan
                value: 0
              - key: "{{ length(not_null(request.object.spec.template.spec.initContainers[].envFrom[], `[]`)) }}"
                operator: GreaterThan
                value: 0