Spike: about how to convert all weaveworks Rego policies

[flavio]

Spike: about how to convert all these policies to Kubewarden

Define:

• repo structure
• what the tool should be doing

[viccuad]

Weaveworks uses the docker image weaveworks/polctl for automation on auto-generating, testing, documenting, and releasing the policies, repo here.

The repo uses openpolicyagent/opa to test the policies. Since we already use opa to build as a wasm target, I find it a good compromise to keep that workflow.

Weavework policies are marked with spec.standards. The list of available standards are in ./standards
(example), and the policies have spec.standards. For now, transform these into metadata.annotations.

The policies are Rego gatekeeper policies.

Acceptance criteria

The end result is a forked monorepo with the following format:

$ tree
.
├── LICENSE
├── artifacthub-repo.yml
├── policy1/
│   └── 0.1.0/
│       ├── README.md
│       ├── tests/
|       │   └── deployment.yaml
│       ├── policy.rego
│       ├── Makefile
│       ├── metadata.yml
│       └── artifacthub-pkg.yml
└── policy2/
    ...

Example for one policy in https://github.com/viccuad/rego-policies.

For that:

• Per policy in examples/,policies/, do a 1-time conversion:

  • Reuse our OPA Rego Makefile from disallow-service-loadbalander-policy. Should be
    adapted to run rego tests with opa from ./tests. Not all policies have a
    ./tests/policy_test.rego.
  • Compile a README.md from policy.yaml, by reusing the following fields in a template:
    • metadata.name with weave.policies prefix removed.
    • spec.name, description, how_to_solve, tags.
  • Compile a metadata.yml from policy.yaml, by reusing the following fields from the Weaveworks policy:
    - spec.id, without the prefix weave.policies, as annotations
    io.kubewarden.policy.title, io.kubewarden.policy.ociUrl: ghcr.io/kubewarden/policies/<id>, io.kubewarden.policy.url: https://github.com/kubewarden/<id>.
    - io.kubewarden.policy.url and io.kubewarden.policy.source hardcoded to the Rego monorepo for these policies. (e.g: https://github.com/kubewarden/rego-policies).
    - spec.category as annotations io.kubewarden.policy.category, without prefix weave.category.
    - spec.severity as annotations io.kubewarden.policy.severity
    - spec.standards as annotation io.kubewarden.policy.standards, where each
    element in the controls array is a new annotation, and it is commented out until we evaluate further. The list of available standards are in ./standards (example).
    - spec.description as annotation io.kubewarden.policy.description
    - spec.targets into rules and the annotation io.artifacthub.resources by computing the list of resources. This translation is not trivial.
  • Adapt the policy.rego:
    • Use the same package for all rego files, including tests (e.g: package policy).
  • Reuse ./tests/, which will get run by the make tests
  • artifacthub-pkg.yml following artifacthub docs. Generated by our Makefile.

• Weavework policies are marked with spec.standards. The list of available
  standards are in ./standards (example).

• Manually mark the converted policies with annotation
  io.kubewarden.policy.category: Best practices RBAC for those policies listed in
  from ./goodpractices.

• CI & CD: I found no way to programatically create jobs. Hence the jobs will go through all repos when they are called.
  To release, for each policy folder, if no git tag matching the policy id and version, build and push the annotated-policy.wasm as usual.

Unresolved

• Evaluate the spec.standards. For these to be valid, the data structure of the k8s deployment needs to match the expected lyout. (E.g: expecting users to deploy things segregated by namespaces, and is a specific way).
• Not all policies have rego tests. Skipping them could diminish the numbers greatly.

[jvanz]

The proposed initial approach looks fine to me. I think we can start writing a script to perform some of this migration and see what happens.

[flavio]

Sounds good to me. I think we can move forward and start 2 spikes:

1. Create the migration script. Focus on policies that have unit tests so far
2. Create the monorepo structure, populate it with the script. See how it scales

[fabriziosestito]

Spike completed.

The output has been tracked by the issues:
#805
#806