Currently, the module relies upon the creation of an S3 bucket (which is done whether or not the user indicates that snapshots should be taken). This dependency is present in the default policy. If the user were to pass in a policy, thus overwriting the policy created by default, it would have to be overly permissive, as there would be no way to anticipate the S3 resource created by the module. This same drawback applies to a scenario whereby the user passes in an execution role ARN, thus preventing any policy or role from being created. Even adopting this last approach is awkward: it requires a targeted, two-step apply to first create the role and policy and then create the synthetic.
A more nuanced approach to modifying the policy, such as augmenting rather than overwriting the default, is even trickier. Leaving the issue of dynamic policy generation aside, the merging of two decoded JSON strings isn't trivial (in Terraform).
Currently, the module relies upon the creation of an S3 bucket (which is done whether or not the user indicates that snapshots should be taken). This dependency is present in the default policy. If the user were to pass in a policy, thus overwriting the policy created by default, it would have to be overly permissive, as there would be no way to anticipate the S3 resource created by the module. This same drawback applies to a scenario whereby the user passes in an execution role ARN, thus preventing any policy or role from being created. Even adopting this last approach is awkward: it requires a targeted, two-step apply to first create the role and policy and then create the synthetic.
A more nuanced approach to modifying the policy, such as augmenting rather than overwriting the default, is even trickier. Leaving the issue of dynamic policy generation aside, the merging of two decoded JSON strings isn't trivial (in Terraform).