feat: prevent containers from running in NRI if we fails to apply policy on it

[holyspectral]

What this PR does / why we need it:

As part of error handling, when we failed to apply protection on a container, we will fail the container creation flow by default. Users can override this behavior via NRI_FAILOPEN env var.

When a container is prevented from starting, logs can be seen in these places:

In our log:

{"time":"2026-03-11T20:57:12.766551002Z","level":"ERROR","msg":"Runtime-enforcer has prevented the container from starting. To change this behavior, set environment variable NRI_FAILOPEN to true","component":"agent","component":"nri-handler","component":"nri-plugin","reason":"failed to add pod container from NRI","containerName":"ubuntu","podName":"ubuntu-deployment-595f9465f7-dnstl","error":"SOME ERROR"}

containerd:

Mar 11 20:59:31 kind-control-plane containerd[122398]: time="2026-03-11T20:59:31.776225421Z" level=error msg="NRI container start failed" error="rpc error: code = Unknown desc = failed to add pod container from NRI: SOME ERROR. Runtime-enforcer has prevented the container 'ubuntu-cronjob-29554377-5tzw4/ubuntu' from starting. To change this behavior, set environment variable NRI_FAILOPEN to true"

kubernetes:

    lastState:                                                          
      terminated:                                                       
        containerID: containerd://2fa1c89c84c448d36d878a44439cc2901bc2939b58be1bc5f3751be31ac4b23d
        exitCode: 128                                                   
        finishedAt: "2026-03-11T20:57:28Z"                              
        message: 'NRI container start failed: rpc error: code = Unknown desc = failed
          to add pod container from NRI: SOME ERROR. Runtime-enforcer has prevented
          the container ''ubuntu-deployment-595f9465f7-dnstl/ubuntu'' from starting.
          To change this behavior, set environment variable NRI_FAILOPEN to true'
        reason: StartError                                              
        startedAt: "1970-01-01T00:00:00Z"         

Which issue(s) this PR fixes

fixes #262

Special notes for your reviewer:

Checklist:

• squashed commits into logical changes
• includes documentation
• adds unit tests
• adds or updates e2e tests

[Andreagit97]

Thank you!

[Andreagit97]

If we return an error from StartContainer, the container won't start. What happens if we return an error here in Synchronize?

[Andreagit97]

How should the final user should set this environment variable? I would expect a helm field in values.yaml, WDYT?

[holyspectral]

yeah this is something we can talk about. Today we already can specify the environment variable via agent.env but we can also make it more specific by providing a separate option. WDYT?

[Andreagit97]

yeah this seems an important feature for users, so I would probably add a new helm field

[Andreagit97]

Can we simplify this a little bit to avoid duplication?

	handleError := func(reason string, err error) error {
		// fail open defaults
		var errNRI error
		msg := "container is starting WITHOUT enforcement due to NRI_FAILOPEN"
		if !p.failOpen {
			errNRI = fmt.Errorf("%s: %w. Runtime-enforcer has prevented the container '%s/%s' from starting. To change this behavior, set environment variable NRI_FAILOPEN to true",
				reason, err, pod.GetName(), container.GetName())
			msg = errNRI.Error()
		}
		p.logger.ErrorContext(
			ctx,
			msg,
			"containerID", container.GetId(),
			"containerName", container.GetName(),
			"podName", pod.GetName(),
			"podID", pod.GetUid(),
		)
		return errNRI
	}

[Andreagit97]

In the end, we can use error verbosity in both cases since a container is not protected

[Andreagit97]

Suggested change

	// if the pod doesn't have the label we do nothing

[Andreagit97]

It's really up to us what we want to do. I'm also fine with returning an error since the pod will start without protection, but the user might think this is protected...