Describe the bug

In auto-remediate a PR will be created with the remediated files, and creating commit would require create a git tree

The problem tree.path mustn't start with / hence it will fail to create a tree nor a commit neither the PR

Environment

• Validator v1.3, failure occurred after this fix

To Reproduce

• create a weave action in your repository and try to validate any resources with auto remediate on

Expected behavior

• A PR should be created after the checks for violations are complete with the remediated files

Actual Behavior

• The checks for violations are complete but PR fails to create

Additional Context (screenshots, logs, etc)

Log of fail

2023/05/31 20:12:24 failed to create tree, error: POST https://api.github.com/repos/waleedhammam/test-validator/git/trees: 422 tree.path cannot start with a slash []

Background

RiotGames has OPA Gatekeeper installed on their clusters with roughly 15 policies enforced. They are trying to enforce the same set of policies in their CI. Initially, the plan was to use checkov to replicate the policies in the CI, but since the policies were already written in Rego, so we are looking for using our own weave-iac-validator to enforce the policies.

The current plan is to have an end-to-end flow for one policy before we transform all policies to weave policy.

Note: RiotGames is using GitHub Enterprise, so we will have to test things out in the customer environment to make sure the flow works there. Luke Mallon is our person there and will be helping us out through this experiment.

Objective

For this ticket, we are looking to transform the following policy: allow-privilege-escalation-container. to our weave policy CR. Below is template.yaml and constraint.yaml for their policy.

Template.yaml

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8spspallowprivilegeescalationcontainer
  annotations:
    description: >-
      Controls restricting escalation to root privileges. Corresponds to the
      `allowPrivilegeEscalation` field in a PodSecurityPolicy. For more
      information, see
      https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privilege-escalation
spec:
  crd:
    spec:
      names:
        kind: K8sPSPAllowPrivilegeEscalationContainer
      validation:
        openAPIV3Schema:
          type: object
          description: >-
            Controls restricting escalation to root privileges. Corresponds to the
            `allowPrivilegeEscalation` field in a PodSecurityPolicy. For more
            information, see
            https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privilege-escalation
          properties:
            exemptImages:
              description: >-
                Any container that uses an image that matches an entry in this list will be excluded
                from enforcement. Prefix-matching can be signified with `*`. For example: `my-image-*`.

                It is recommended that users use the fully-qualified Docker image name (e.g. start with a domain name)
                in order to avoid unexpectedly exempting images from an untrusted repository.
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8spspallowprivilegeescalationcontainer

        import data.lib.exempt_container.is_exempt

        violation[{"msg": msg, "details": {}}] {
            c := input_containers[_]
            not is_exempt(c)
            input_allow_privilege_escalation(c)
            msg := sprintf("Privilege escalation container is not allowed: %v", [c.name])
        }

        input_allow_privilege_escalation(c) {
            not has_field(c, "securityContext")
        }
        input_allow_privilege_escalation(c) {
            not c.securityContext.allowPrivilegeEscalation == false
        }
        input_containers[c] {
            c := input.review.object.spec.containers[_]
        }
        input_containers[c] {
            c := input.review.object.spec.initContainers[_]
        }
        # has_field returns whether an object has a field
        has_field(object, field) = true {
            object[field]
        }
      libs:
        - |
          package lib.exempt_container

          is_exempt(container) {
              exempt_images := object.get(object.get(input, "parameters", {}), "exemptImages", [])
              img := container.image
              exemption := exempt_images[_]
              _matches_exemption(img, exemption)
          }

          _matches_exemption(img, exemption) {
              not endswith(exemption, "*")
              exemption == img
          }

          _matches_exemption(img, exemption) {
              endswith(exemption, "*")
              prefix := trim_suffix(exemption, "*")
              startswith(img, prefix)
          }

Constraint.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowPrivilegeEscalationContainer
metadata:
  name: psp-allow-privilege-escalation-container
spec:
  enforcementAction: warn
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]

Note: This is probably the same stock policy found in OPA gatekeeper policy library here: https://open-policy-agent.github.io/gatekeeper-library/website/allow-privilege-escalation

We need to enable auto-remediation functionality on Azure DevOps.

Note: We need to ask corporate-it for the best way to acquire Azure DevOps account to be able to test it out.

In our efforts to support RiotGames end-to-end policy scenario, we might need to change how the validator work. This is ticket to track changes needed to get in place for it:

• Handle the recursive paths in helm / kustomize / resources directories.
• Fix handling helm charts by ignoring non-yaml files.
• Ignore hidden files.

Problem
I need to be able to configure policysets to be applied to numerous different building within a git repository. Each cluster has multiple varying components/applications and it would be ideal to apply on the specific policies to those clusters and applications in order to not fail them for policies which do not apply to their specifics.

Solution

In a git repository today I can only specify a single path to an to the iac-validator, however this means that If I need to target more than one directory I need to devise a loop or I need to consume more than I would like by referencing the parent directory, returning me the results of data I didn't want to test.

Ideally I would have the ability to both specify:

• ClI commands for --included-paths and --excluded paths so I can refine what I target in testing

• A .weaveignore or a validator.yaml that would automatically be read form the root of the directory or via --config flags so that I can predefine what tests each cluster build runs in a manifest.

Additional context

This is being used both locally and in CI, though it is wrapped in some logic so that I can get both the results of each application that I test and also the the clusters total violation count (all applications together). I might follow up with some more details if they are needed

We want to move this repo under the weaveworks github organisation and move the Weave-validator image under weaveworks docker hub.

Create docs to be used to demo Policy capabilities end-to-end. We want to showcase how it will be used in commit-time validations and how the user can benefit from auto-remediation. And how the agent can block the same violating deployment in runtime.