feat: have a converter from NeuVector process rules to new enforcer format

[dottorblaster]

We need a one-way converter that ingests existing NeuVector process profiles and emits equivalent policies in our new runtime-enforcer format. This unblocks migration for users who already have curated NeuVector rules and don't fancy rewriting them by hand (nobody does).

Acceptance criteria

• CLI tool / subcommand (e.g. runtime-enforcer convert --from neuvector ) reads a NeuVector process profile (JSON/YAML) and outputs a valid policy in our new format, with a clear mapping of allow/deny actions and process path/args matching semantics.
• Unmappable or ambiguous rules produce a non-zero exit code and a human-readable diagnostic pointing at the offending entry, rather than silently dropping them.
• Draft document as to how to migrate existing NV 5 rules to runtime-enforcer.

[holyspectral]

Here is the policy converter for admission policy, which could be a good start:
https://github.com/neuvector/neuvector-kubewarden-policy-converter

To me there are a few limitations and we probably have to define the behavior and document them:

1. NV doesn't support per-container policy.
   • It would be possible to map it by looking into workload definition if there is only one container.
   • When there are more than one containers, we probably have to abort and let users to intervene.
2. After converting and applying new WorkloadPolicies, the existing workload won't have the label to specify which runtime-enforcer policy should be assigned to which workload.
   • Adding the labels will cause re-rollout.
   • The best we can do is let users to choose - we can apply labels to workload automatically, which will cause re-rollout, or they want to do them by themselves, then we can provide kubectl commands to patch those resources.
3. Zero-trust mode is not supported.
   • We probably should document it.
4. Rule difference between two products. It's highly possible that runtime-enforcer could see more process events than NV, or at least have some subtle difference. That means false positives are likely at the beginning.
   • We would probably have to guide users to start from monitoring mode first.

@flavio @dottorblaster I'd love to have your input on this one.

[flavio]

1. NV doesn't support per-container policy.
   
   * It would be possible to map it by looking into workload definition if there is only one container.
   * When there are more than one containers, we probably have to abort and let users to intervene.

I agree, we should do nothing in that case. I would not abort though, but rather collect the errors and show them at the end of the migration.

2. After converting and applying new WorkloadPolicies, the existing workload won't have the label to specify which runtime-enforcer policy should be assigned to which workload.
   
   * Adding the labels will cause re-rollout.
   * The best we can do is let users to choose - we can apply labels to workload automatically, which will cause re-rollout, or they want to do them by themselves, then we can provide kubectl commands to patch those resources.

I don't want the migration tool to handle the label, at least not now. I think we should just print instructions at the end of the migration.

3. Zero-trust mode is not supported.
   
   * We probably should document it.

Yes.

4. Rule difference between two products. It's highly possible that runtime-enforcer could see more process events than NV, or at least have some subtle difference.  That means false positives are likely at the beginning.
   
   * We would probably have to guide users to start from monitoring mode first.

Yes.

[venkateshjayagopal]

We implicitly deny process which are not mentioned in our allow list with runtime-enforcer.
NV process profile might have both allow and deny process rules, do we just migrate the allow and drop deny rules?.
What if there are only "deny" rules?. (Probably a bad design, but still possible)

[holyspectral]

We implicitly deny process which are not mentioned in our allow list with runtime-enforcer.
NV process profile might have both allow and deny process rules, do we just migrate the allow and drop deny rules?.
What if there are only "deny" rules?. (Probably a bad design, but still possible)

I think this is similar to the case#1 where the NV rule is incompatible to runtime-enforcer rule. I'd use similar way to address it. WDYT?

[davideiori1]

NV, per rule, handle also its provenance as type. Type can be Learned, User Created and CRD. The values are self-explanatory:

• Learned: when the rule comes from the default learning mode of Neuvector and it is untouched by the user.
• User Created: when the rule is either added or edited
• CRD when it is imported via yaml import action

As long as we do not handle the provenance, we should document that. This is lost info after performing the migration.

[holyspectral]

After checking, currently NV doesn't export the Learned, User Created and CRD fields. After re-importing them, the data will show User Created if I import them in UI, even if it's learned before. If we want to preserve the fields after convert, we'd have to export them first.