Description

In https://github.com/openshift/sandboxed-containers-operator/pull/518 we introduced a default kata agent policy file which is specific for CoCo. This policy disable some endpoints of the agent like  `ExecProcessRequest`.

The new initdata () configuration/feature provides means to inject a custom agent policy in the podvm at launch time. We had to adjust some links and files for the default policy work on its absence on initdata (https://github.com/openshift/sandboxed-containers-operator/pull/553) or take initdata's policy when available (https://gitlab.cee.redhat.com/cpaas-midstream/osc-operator/-/merge_requests/722).

The problem is that when you not set a agent policy in the initdata, the default policy isn't applied either, as a result, the pod fails to start.

Steps to reproduce

1. Configure your peer-pods-cm configmap with an initdata file where the `policy.rego` is absent. In other words, don't set any agent policy in initdata like in below:

2. algorithm = "sha384"
   version = "0.1.0"[data]
   "aa.toml" = '''
   [token_configs]
   [token_configs.coco_as]
   url = 'http://kbs-service.trustee-operator -system:8080'
   [token_configs.kbs]
   url = 'http://kbs-service.trustee-operator-system:8080'
   cert = """
   """
   '''"cdh.toml"  = '''
   socket = 'unix:///run/confidential-containers/cdh.sock'
   credentials = []
   
   [kbc]
   name = 'cc_kbc'
   url = 'http://kbs-service.trustee-operator-system:8080'
   '''

2. Create a CoCo pod. Can be a simple pod from unsigned image.

Expected result

The CoCo pod should start.

Actual result

The CoCo pod fail.

Impact

If the user doesn't provide a agent policy on installation of OSC then he/she won't be able to make it work.

If we don't fix this problem then there is impact on documentation because we will need to clearly state a policy is required on initdata (https://issues.redhat.com/browse/KATA-3426), moreover, we will need to explicitly say what's the default policy be.

Env

OSC 1.9.0-14 build.