I’m working on several AWS integrations. One of the key technologies for many of the integration possibilities in AWS is the SNS service. It’s their operational pub/sub message bus. It’s fast, it’s distributed, it’s wonderful.
SNS is also a PITA to interface with from a native HTTP client, like open data stream - there’s way too little documentation on their Wire/L7 protocol. We’re abstracting that part out and make it easy for folks to set up so they can take advantage of native AWS pub/sub with Reveal(x).
I was working through a more advanced configuration, using SNS message filtering - SNS will dispatch/route messages (like - wait for it! Security events) based on filter strings that you can pass. Cool, right?
But passing them into the service from triggers got painful - the POST payload syntax isn’t clear at all (in fact, it’s actually a query string that you POST up into a REST payload .
I was at risk of having to bail on the message filtering totally, which I really didn’t want to do because it’s too useful a pattern to ignore.
So what’s a SecOps Engineer to do? Use our keyless decryption to dump that payload and figure out the correct syntax for the filtering service.
Knowing that the AWS cli uses REST under the covers, first I face-palmed, and then did the following:
Fired up the CLI on my Linux host in AWS
Setup secret sharing, confirmed that we were getting secrets moving back and forth
Did a wee little trigger to dump the HTTP_REQUEST payload
Basked in the glory of a sparkling victory at the hands of our client-side PFS decryption.
A single copy/paste later and yeeeee haw, we’re now rolling with some extra smart native integrations in the cloud