Observation
When attempting to create gen_rules that match on CloudQuery resources aws_regions, we see the following error
rror handling successful: type <class 'ValueError'>, returning response <Response status_code=500, "text/html; charset=utf-8"> with data {
"drf": "<Response status_code=500, \"text/html; charset=utf-8\">",
"message": "ARN is required for AWS resource data.",
"exceptionType": "<class 'ValueError'>",
"stackTrace": " File \"/opt/pysetup/.venv/lib/python3.11/site-packages/rest_framework/views.py\", line 506, in dispatch\n response = handler(request, *args, **kwargs)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\n File \"/workspace-builder/workspace_builder/views.py\", line 116, in post\n raise e\n\n File \"/workspace-builder/workspace_builder/views.py\", line 99, in post\n run_components(context, components)\n\n File \"/workspace-builder/component.py\", line 356, in run_components\n component.run_func(context)\n\n File \"/workspace-builder/indexers/cloudquery.py\", line 593, in index\n platform_handler.parse_resource_data(resource_data,\n\n File \"/workspace-builder/enrichers/aws.py\", line 49, in parse_resource_data\n raise ValueError(\"ARN is required for AWS resource data.\")\n",
We did validate that the AWS ACCESS KEY had the role to describe regions, and so we aren't quite sure why this arises.
Possible Suggestions
a) Additional testing of the permissions is required first, likely with the CQ CLI directly, to determine if its an access issue, CQ issue, or RunWhen workspace builder issue
b) we should log this error and continue on, instead of crashing, if we can. I'm not sure if we can preemptively check that this state will occur, and I'm not sure how much control we will have through the CQ discovery process.
Any other details or context
Observation
When attempting to create gen_rules that match on CloudQuery resources aws_regions, we see the following error
We did validate that the AWS ACCESS KEY had the role to describe regions, and so we aren't quite sure why this arises.
Possible Suggestions
a) Additional testing of the permissions is required first, likely with the CQ CLI directly, to determine if its an access issue, CQ issue, or RunWhen workspace builder issue
b) we should log this error and continue on, instead of crashing, if we can. I'm not sure if we can preemptively check that this state will occur, and I'm not sure how much control we will have through the CQ discovery process.
Any other details or context