Read on Twitter
Building APIs are hard. Building platforms are hard. Building an entire cloud is hard. Even when I don’t like something AWS does, I try to offer constructive feedback. But I’ve had an experience with one API that is so outwardly user hostile that I can’t help whinge about it
I’ve been working on something to propagate an IP block list out to public facing endpoints at a client. The AWS tool of choice for this is Firewall Manager.
Firewall Manager effectively lets you create a Web ACL, which can contain various firewall-y rules, and have it (more or less) automatically apply to a bunch of resources. A clearly useful solution for a large enterprise on AWS.
My block list is source from an API, and I had no trouble building a serverless solution that would pull IP addresses from the endpoint, and create the necessary rule group.
The problems began when creating the Firewall Manager policy. There’s an API call to create the policy, and an associated cloudformation resource as well.
API call -> https://docs.aws.amazon.com/fms/2018-01-01/APIReference/API_PutPolicy.html
CloudFormation resource -> https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-fms-policy.html
CloudFormation resource -> https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-fms-policy.html
What follows is a list of things I’ve found that pissed me off using it.
In the console, you can specify multiple resources to target - CloudFront, API Gateway and ALB. There are two places to you can put this in ‘ResourceType’ and ‘ResourceTypeList’. The former is mandatory, which makes no sense. One in the former, and the overflow in the latter?
Nope - that didn’t work. So instead I used the console and created one manually and pulled the configuration data back to see what it looked like (this will become a common occurrence).
How silly of me - if you want to use ‘ResourceTypeList’ you need to use ‘ResourceTypeList’ as the value of ‘ResourceType’. This isn’t documented anywhere. WTF?
Next part was working out how to configure it to use my rule group. From the docs - we use the property ‘SecurityServicePolicyData’ - which itself has two properties - the type (which in my case is WAFV2) and…
A massive JSON string that goes in the line called ManagedServiceData…. Which while annoying, isn’t exactly uncommon. Step Functions for example, takes a JSON string in the Amazon States Language. Whatever. I can deal with this…
OK… great, this is completely undocumented, with only a small sample in the docs. Back to the console, where I set up more or less what I want and query it back using the CLI to inspect it.
I then set up a multi-line YAML string to make it easy to embed and parameterise the JSON sins I’m about to commit. I submit it...
and receive this.
I’m immediately taken aback at how I can ‘fail to satisfy constraint: Member must satisfy regular expression pattern: .*’. It’s at this point I remember regex tends not to match line-breaks.
So now I convert it to a one-line string and escape the quotes appropriately. I resubmit and it works. Great, it can’t understand line breaks in the the property value (for what it’s worth - step functions does). None of this is documented.
For gods sake... if you are going to force me to submit a JSON string in a property, you can at least let me use a multi-line yaml string.
So we’ve got one instance of undocumented usage (how to actually use ResourceType & ResourceTypeList), and the complete tire-fire that is the ManagedServiceData.
I can only imagine that the reason these ‘features’ are undocumented is that the designer was so embarrassed by it that documenting it would be to call too much negative attention towards it.
As it stands, I pissed away an evening trying to work this all out.
