- Newest
- Most votes
- Most comments
That isn't possible, unfortunately. The IAM authorisation model doesn't permit inspecting all the parameters that are passed to API calls. Instead, only the specific aspects and attributes of an operation that are supported for inspection in the context of an operation are evaluated against the configured IAM policies. Authorisation checks also and the "Action" values in policies don't always map 1:1 to APIs, so it would be complex to make all the API parameters available even in theory.
The supported actions and condition keys are documented in the AWS Service Authorization Reference. For CreateHostedZone, the actions table https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html#amazonroute53-actions-as-permissions shows that there are no operation-specific condition keys, such as the name of the zone, available for evaluation.
Relevant content
- Accepted Answerasked 2 years ago
- asked 8 months ago
AWS OFFICIALUpdated 5 months ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated 2 months ago
A better way to do this might be to use Config Rules to check for the existence of specific hosted zones and then perform a remediation task.
I'd argue it's best to enforce access restrictions when it's possible. It actively signals to anyone attempting to violate rules that they are doing so and prevents a noncompliant situation from being created. If the violation is first permitted and later remedied, it may take time to become known to the originator of the problem, it will put CFN stacks in a drifted state, Terraform would recreate the same problem when deployed again, etc. Simply blocking undesired actions avoids all those issues, but in this case, blocking the action is unfortunately impossible.