feat: manager emits Windows ImageJob pods

[fseldow]

What this PR does / why we need it:

Summary

copyAndFillTemplateSpec now branches on the node's kubernetes.io/os:

Windows nodes produce a HostProcess pod spec:

• Pod-level HostProcess security context, runAsUserName: NT AUTHORITY\SYSTEM, hostNetwork: true.
• Drops the Linux-only SharedSecurityContext (capabilities / seccompProfile / readOnlyRootFilesystem are invalid on Windows).
• Omits the CRI hostPath volume + mount — a HostProcess pod reaches the containerd named pipe directly.
• Rewrites the shared-data emptyDir mount to its Windows form (C:\run\eraser.sh\shared-data).

Linux nodes keep existing behavior (refactored into fillLinuxPodSpec).

Supporting changes

• pkg/utils: non build-tagged LinuxSharedDataPath / WindowsSharedDataPath constants + SharedDataPathForOS helper so the Linux-run manager can emit the Windows path; WindowsHostProcessPodSecurityContext + WindowsHostProcessUserName.
• New imagejob_controller_test.go covering Linux spec, Windows spec, and node OS detection.

Validation

• GOOS=linux go build ./... / go vet ./... pass
• go test ./controllers/imagejob/... ./pkg/utils/... pass
• gofmt clean

Follow-ups (out of scope here)

• Align the Windows shared-data path with the worker IPC constants (coordination with Charles).
• Windows Dockerfile stage / PLATFORM extension.

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #

Special notes for your reviewer:

[charleswool]

This could tie binary name to container name. Right now the scanner container's name is hardcoded as trivy-scanner regardless of the configured image. Meaning the custom scanner must ship a binary literally called trivy-scanner.exe. which is going to be confusing.

Better in the dockerfile's ENTRYPOINT or configurable per component. The problem is we don't have the windows dockerfile yet....

Should we consider fix the hardcoded trivy-scanner in imagecollector_controller.go:421?

[fseldow]

will leave it in next pr.
For discussion, how do you think we could pass the scanner name?
though scanner filed in configmap?

[fseldow]

if it is through configmap. Windows and linux may need different configs. I may have two options:

1. Still share one configmap and one controller. But add windows level config

components:
  scanner:
    image: {repo: .../remover, tag: v1.5}      #default
    windows:                                     # Windows override
      image: {repo: .../remover-win, tag: v1.5}
manager:
  runtime:
    address: unix:///...                         
    windowsAddress: npipe://./pipe/containerd-containerd

Advantage: one controller pod + support empty node filter
Disadvantage: more complex configmap exposed to customer

2. We setup two controller, each controller uses its own configmap. one for linux and another for windows.

eraser-controller-manager-xxx (eraser-manager-config)
eraser-controller-manager-windows-xxx (eraser-manager-config-win)

Advantage: no complex config, less change on configmap structure
Disadvantage: if customer sets incorrect node filter in one of the configmaps. Windows/linux scanner may not work as expected

[charleswool]

Also can we run a standalone windows e2e testing and add the testing results similar to the Standalone E2E test results sections in #1229 description?

[fseldow]

@charleswool Ran a standalone Windows E2E against a real AKS Windows node (mirroring the harness style from #1229, since upstream has no Windows CI). Keeping the runner script out of this PR — it lives on a separate branch of my fork.

Unlike the #1229 transport spike, this drives the actual controller path this PR changes: ImageList -> imagejob controller -> copyAndFillTemplateSpec (Windows branch) -> a HostProcess pod on the Windows node -> the remover connecting to containerd over the named pipe and deleting the requested image. The remover is this repo''s own binary (cri.NewRemoverClient -> utils.GetConn -> gRPC over the pipe), not crictl.

Standalone E2E test results

Harness — where the tooling lives

Manual E2E runner	hack/windows-e2e.ps1 (on my fork''s windows-e2e-harness branch, not part of this PR)

The runner deploys the PR-head manager with a Windows-only node filter, seeds an unused image on the Windows node via a one-shot pod, waits for containerd to reclaim the exited seed container, triggers an ImageList job, then asserts on the emitted pod shape and the remover''s result.

Environment

Cluster	AKS 1.35 (kubelet v1.35.6)
Node	Windows Server 2022 Datacenter, build 10.0.20348
Runtime	containerd 1.7.20+azure
Pod	HostProcess, base mcr.microsoft.com/windows/nanoserver:ltsc2022
Identity	runAsUserName: NT AUTHORITY\SYSTEM
Endpoint	npipe://./pipe/containerd-containerd

Live results — commit e32bb7d6, the head of this PR

=== code under test ===
e32bb7d6 Merge branch ''main'' into feat/windows-ready-imagejob-pods

=== target windows node ===
  node    : akswin000000
  osImage : Windows Server 2022 Datacenter
  runtime : containerd://1.7.20+azure

=== deploy manager from PR head (windows node filter) ===
  manager : <registry>/eraser-manager:e2e-e32bb7d6

=== seed an unused image on the windows node ===
  seeded  : mcr.microsoft.com/windows/servercore:ltsc2022 (waiting for the exited container to be reclaimed)

=== emitted pod shape (what this PR produces) ===
  hostNetwork    : true
  os.name        : windows
  hostProcess    : true
  runAsUserName  : NT AUTHORITY\SYSTEM
  command        : %CONTAINER_SANDBOX_MOUNT_POINT%\remover.exe
  imagelist arg  : --imagelist=C:\run\eraser.sh\imagelist\images
  has CRI mount  : False

=== remover result over the named pipe ===
remover starting     imageListPtr=C:\run\eraser.sh\imagelist\images  criPath=npipe://./pipe/containerd-containerd
CRI client created successfully
successfully parsed image list file  count=1
removed image  mcr.microsoft.com/windows/servercore:ltsc2022  (sha256:f02b623b...)
  pod phase : Succeeded (exit 0)

RESULT: PASS

Note

An image still referenced by a container record (e.g. right after the seed pod exits, before containerd reclaims it) is correctly skipped by the remover as in-use — the harness waits for that reclaim before triggering. This matches the remover''s existing "image is running" guard and is not Windows-specific.

I also separately verified an empty node filter on a mixed Linux+Windows cluster: a single ImageJob fans out to both nodes and both remover pods complete (exit 0) — the Linux node takes the untouched Linux path (hostPath CRI socket mount, /run/eraser.sh/...) and the Windows node takes the HostProcess path (npipe, C:\run\eraser.sh\...).

[codecov]

Codecov Report

❌ Patch coverage is 75.47170% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/utils/security_context.go	0.00%	8 Missing ⚠️
controllers/imagejob/imagejob_controller.go	88.88%	3 Missing and 2 partials ⚠️

Flag	Coverage Δ
unittests	5.97% <75.47%> (-8.87%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
pkg/utils/utils.go	19.07% <ø> (+7.24%)	⬆️
controllers/imagejob/imagejob_controller.go	14.16% <88.88%> (ø)
pkg/utils/security_context.go	0.00% <0.00%> (ø)

... and 40 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ashnamehrotra]

resource limits should be supported for windows as well. Could we confirm the Kubernetes/containerd version and the specific repro for the startup error?

[fseldow]

containerd 1.7.20+azure
K8S version 1.35.6

The issue only happens when memory limit is set 30mi.

State:          Terminated
      Reason:       Error
      Exit Code:    -1073741571
      Started:      Wed, 26 Aug 2026 21:36:03 -0700
      Finished:     Wed, 26 Aug 2026 21:36:03 -0700
    Ready:          False

sorry my bad, it is caused by too small memory limit in my test. Will remain the resource limits

[fseldow]

update the logic. If found memory limit < 256Mi, then force raise it to 256Mi

[Copilot]

Pull request overview

Adds Windows HostProcess pod generation for ImageJobs while preserving Linux behavior.

Changes:

• Adds OS-specific pod shaping, paths, security contexts, and memory limits.
• Adds Windows pod validation and controller tests.
• Adds a manual AKS Windows E2E script.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pkg/utils/utils.go	Adds Linux and Windows path constants.
pkg/utils/security_context.go	Adds HostProcess security context helpers.
controllers/imagejob/imagejob_controller.go	Generates OS-specific worker pod specs.
controllers/imagejob/imagejob_controller_test.go	Tests Linux and Windows pod generation.
controllers/imagejob/imagejob_windows_validation_test.go	Tests Kubernetes API validation.
hack/windows-e2e.ps1	Exercises manual removal on an AKS Windows node.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[fseldow]

will leave the scanner in next pr.
windows will not be able to use trivy as scanner. We will only support BYO scanner image for windows.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

controllers/imagejob/imagejob_controller.go:650

• Deriving the executable from c.Name breaks the documented custom-scanner path. The image collector always names that container trivy-scanner even when components.scanner.image points to an arbitrary custom scanner, and Linux currently relies on the image's entrypoint. A valid Windows custom image whose executable is not trivy-scanner.exe will therefore start a nonexistent path. Preserve a HostProcess-compatible configured command/entrypoint or carry an explicit executable path instead of deriving it from the Kubernetes container name.

		c.Command = []string{windowsSandboxMountEnv + `\` + c.Name + ".exe"}

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (1)

controllers/imagejob/imagejob_controller.go:650

• This replaces every configured image entrypoint with an executable name derived from the Kubernetes container name. The scanner image is explicitly configurable for custom scanners (config/manager/controller_manager_config.yaml:43-55), but the config exposes no command/path field (api/unversioned/eraserconfig_types.go:147-157), so a valid Windows BYO scanner whose executable is not trivy-scanner.exe will fail before startup. Since BYO images are the intended Windows scanner path, preserve an image-provided HostProcess-aware entrypoint or add an explicit Windows executable/command contract instead of inferring it from c.Name.

		c.Command = []string{windowsSandboxMountEnv + `\` + c.Name + ".exe"}