If I have activities that fetch/store secrets (out of Hashicorp Vault) or PII, how can I flag those feels to keep Temporal from logging them or making them visible in workflow run history?
I can obviously serialize/deserialize my input/output in my workflows and activities, encrypting/decrypting on the way, but the headaches of key management and rotation around that hurt my head a bit.
We do plan to provide a DataConverter implementation that implements encryption. You still will have to deal with key management yourself.
Until then you have to implement your own version of DataConverter as Ryland described in his posts.
I can obviously serialize/deserialize my input/output in my workflows and activities, encrypting/decrypting on the way, but the headaches of key management and rotation around that hurt my head a bit.
DataConverter is the supported way to serialize/deserialize your input/output without polluting your activity and workflow code. You want to manage your own keys. Otherwise you would be trusting a third party with all the secrets.
Secrets end up being exposed in logs, core dumps, backtraces, source code, etc…
Security is not about making things secure but preparing for failure and Vault allows you create secrets when you need them and invalidate them as soon as you use them. This way you don’t have to worry about them leaking.
Achieving this centralization is a huge improvement in security posture, but it’s not the end of the journey. This is because applications don’t keep secrets ! It turns out, most applications do a worse job keeping secrets than our close friends. Applications frequently log configuration, leaving them in log files or centralized logging systems. Often secrets will be captured in exception tracebacks or crash reports sent to external monitoring systems, or they will be leaked via debugging endpoints and diagnostic pages after hitting an error. The list of ways applications leak secrets goes on, but the point is applications should not be treated as perfectly secure.
Vault presents an answer to these problems in the form of “Dynamic Secrets”. A dynamic secret is generated on demand and is unique to a client, instead of a static secret, which is defined ahead of time and shared. Vault associates each dynamic secret with a lease and automatically destroys the credentials when the lease expires.