It's so specific to our architecture that there would be little value in open sourcing it.

That being said, there are some lessons we learned along the way that I do think are worth sharing.

As I mentioned above the API proxy supports REST and gRPC API calls.

For REST based APIs, we developed a YAML syntax for declaratively specifying (per route) the input/output keys that needed to be encrypted/decrypted. This is accomplished using a JsonPath like syntax, along with attributes for each key that specified the type of data, as well as letting us perform limited validation on the data.

However this approach provided little visibility into what fields are not being encrypted, leaving room for mistakes.

This is where gRPC/Protobufs come in to play, it's the newest addition at the API Proxy level, but is not new to our internal architecture.

Using protocol buffers as our IDL has been a huge help in terms of our data auditing capabilities. Unlike our YAML based solution before, with protobufs we can see every single field that is expected as an input or output of an API call.

We've utilized this feature by creating wrapper message types that indicate when a field contains data that needs to be encrypted/decrypted, and have helper libraries that can traverse an instantiated protobuf message, perform the encrypt/decrypt operation, and swap out the original value(s) for the one(s) returned from the encryption service.

Once we have the library to perform the traversal and the compiled protobufs, integrating it into the API Proxy (along with grpc-gateway to translate to REST/Json) is actually pretty straight forward.