Open pauly4it opened 2 years ago
Yeah, violations
is currently assumed to be a set of strings only. While we could extend this to support more response formats, I'm not sure what the added value in this case would be? 🙂 That allowed is false
is already implied by the presence of violations, so also adding that to each violation entry does not seems a little redundant.
One thing that might be useful though is if we had a case for adding other types of metadata to a violation, like severity or something like that. But whatever we'd go with, we'd need to document properly what works and what doesn't.
Regardless of that — we could definitely print something more informational than a stacktrace here. Just something like the below would be an improvement:
Unrecognized format in OPA response.
Expected: {"allow": <boolean>, "violations": <array<string>>}
Got: {"allow": <boolean>, "violations": <array<object>>}
After setting up the CloudFormation hook and creating a stack with an S3 bucket with public access, the following was logged to CloudWatch for the hook:
For reference, the OPA agent returned the following: