how are policy_manifest changes provisioned?

[AndreasAugustin]

Describe the bug

We have seen in one of our projects that in the case of a policy_manifest update the changes are not getting provisioned into the firewall manager.

To Reproduce

The whole stack is deployed

• update the policy_manifest.json in S3
• the changes are not automatically provisioned into the firewall manager.

Expected behavior

The changes are getting provisioned into the FirewallManager

Remark

I had a look into the code.
source/services/policyManager/index.ts starting line 142 there are different events handled. A change of the policy_manifest.json is not handled there.

Please complete the following information about the solution:

• Version: v2.0.0

• Region: **at least 3 regions. **

• Was the solution modified from the version published on this repository? No

• If the answer to the previous question was yes, are the changes available on GitHub?

• Have you checked your service quotas for the services this solution uses? Yes, no issue with the Quotas

• Were there any errors in the CloudWatch Logs? How to enable debug mode? No, AFAIK there is no trigger defined

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Maybe it is intended to add smth like a policy version as TAG. When updating the policy version this would also trigger the lambda and provision the changes. At least it is not documented.

[aijunpeng]

Thanks for reporting the issue. This is by design. Updating these SSM parameters (OU, Region, or Tag parameter) will trigger FMS policies to be updated with your customization in manifest json file. This is documented in https://docs.aws.amazon.com/solutions/latest/automations-for-aws-firewall-manager/customize-policies.html

[AndreasAugustin]

@aijunpeng thank you for the answer. Not 💯 percent clear is to me how you update the policy when you don't need to update the params in parameter store. E.q. you need to add a new policy or smth like that but you keep the settings in the param store because the OU/Region settings do not need to be updated.
In such a case I think it makes sense to also trigger the lambda when just the policy changes.

I know that I could get around this when I would for example add a tag with e.q. version= in the param store and update this one in addition to the policy. But that is a manual task I need to track (possible but error prone).

[WillAWS]

Thanks for the feedback. We have added this feature request to our roadmap and will evaluate it for future releases. In the time being, please continue to use the workaround.