Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spike: about how to convert all weaveworks Rego policies #766

Open
flavio opened this issue Jun 11, 2024 · 2 comments
Open

Spike: about how to convert all weaveworks Rego policies #766

flavio opened this issue Jun 11, 2024 · 2 comments
Assignees
Milestone

Comments

@flavio
Copy link
Member

flavio commented Jun 11, 2024

Spike: about how to convert all these policies to Kubewarden

Define:

  • repo structure
  • what the tool should be doing
@flavio flavio added this to the 1.14 milestone Jun 11, 2024
@viccuad viccuad self-assigned this Jun 14, 2024
@viccuad
Copy link
Member

viccuad commented Jun 21, 2024

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.

@viccuad viccuad modified the milestones: 1.14, 1.15 Jun 28, 2024
@jvanz
Copy link
Member

jvanz commented Jul 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Pending review
Development

No branches or pull requests

3 participants