Skip to content

Fix approval policies

Philippe Lafoucrière requested to merge fix_approvals_policies into main

@byronboots I found extremely suspicious to not have any violation reported by your last additions. I investigated by downloading the result (artitfacts) of the last sync job and started to look for a project that could be a false negative. I found gitlab-com/gdpr-request which is categorized as red_data and had "merge_requests_author_approval": true.
I tested a part of the compliance.sh script shipping with gib, by defining the build_input function in my shell:

build_input() {
  local dir=$1
  {
    jq '{"project": .}' $dir/project.json
    [ -f $dir/properties.yml ] && yq e -o=j $dir/properties.yml
    [ -f $dir/ci-config.json ] && jq -r '.merged_yaml' $dir/ci-config.json | yq e -o=j '{"ci-config": .}' -
    # All IDs need to be deleted to compare set in rego
    [ -f $dir/protected_branches.json ] && jq '{"protected_branches": . | del(.. | .id?)}' $dir/protected_branches.json
    [ -f $dir/approvals.json ] && jq '{"approvals": .}' $dir/approvals.json
  } | jq -s add
}

That way I could reproduce the input as seen by opa:

{
[redacted]
  "approvals": {
    [redacted]
    "merge_requests_author_approval": true,
  }
}

and if I apply our policies on this input, the "author_can_approve" violation isn't raised. This is because this API returns true booleans, which are different from the strings "true" and "false".

This MR is fixing the policies by using booleans instead. Sorry I didn't catch up this during the initial review.

refs #95

Merge request reports