Morning – I’m poking around in the foundational_security_free policy right now and getting an error when I run the postgres__api_gateway_method_settings macro through dbt. Can’t find it on GitHub.
error: more than one row returned by a subquery used as an expression
This comes from stages with multiple entries in the method_settings column of aws_apigateway_rest_apis, which is strange since the JSONB_TEXT_EACH function should just be able to handle that?
Hey! Thanks for reporting this. I’m looping in Jonathan, one of our data analysts, to take a look at this tomorrow when he is back.
aws plugin v22.8.2 but the tables (or at least this column) look the same from what I can tell
aurora postgres 13.8
can’t extract the example data from the corp network but this is what the rows look like from an extracted example record:
(*/*, {"LoggingLevel":null, "CachingEnabled":false ...})
(~1/POST, {"LoggingLevel":"OFF", "CachingEnabled":false ...})
Hi @handy-bee!
Thanks for pointing that out (and suggesting a solution). We’ve just released version 1.0.1 for the AWS Compliance (Free) addon, which includes the fix to the postgres__api_gateway_method_settings macro.
You can find the details here: AWS Compliance (Free) v1.0.1 Docs.
Could you give it a spin and let us know if it’s all good now?
Sure, I’ll let you know shortly.
Works!
There are some CloudTrail mismatches I think between the new versions of the provider and our v22 version causing some issues. In the postgres__log_metric_filter_and_alarm() macro, advanced_event_selectors changed types in the version change, I think.
How should we treat those? Ideally, the policies would be versioned with the providers, but I realize that makes a lot of work for the same thing.
@handy-bee - Between V22 and V23 of the AWS plugin, we changed the schema of that table to ensure that all data was being persisted in the database. As such, we had to change the macro, but our policies are only designed to be compatible with specific versions of the plugin. We have an open issue to expose that compatibility via the hub.
The aws-compliance-free version v1.0.1 is designed and tested to be compatible with v23.3.1 of the AWS plugin. We know that staying up to date with the plugin version can be difficult at times, but know that work is currently underway to eliminate much of that work by ensuring that changes to primary keys will not break schemas.
Makes total sense. Also, “shiny new features” is a great way to drive adoption of the new versions of software. We use that technique internally all the time, so I get that approach too.