Fix approval policies
@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