Re:Keeping secrets out of logs (2024)
by aduwah on Sunday September 07, 2025 @03:42PM
(#45161490)
Great article!
I will definitely reference it in my upcoming discussions. I had some hard time defending having an EU based o11y stack for our EU based infra. I found it hard to articulate on the spot that there are myriads of places where sensitive/personal data can get in the logs and cause leaks, or make GDPR angry.
[ Parent
| on HN ]
Re:Keeping secrets out of logs (2024)
by jazzyjackson on Sunday September 07, 2025 @04:11PM
(#45161706)
Why do I have to know how many letters are in observability? is this some kind of in group signaling?
Just wait until you see our secret handshake
you don't need to know, just consider it a new word that's a synonym, and happens to kind of look like o-<tall spiky letters like i and l>-y
Re:Keeping secrets out of logs (2024)
by halffullbrain on Sunday September 07, 2025 @07:48PM
(#45163307)
I read the piece expecting precisely that; How to keep PII out of logs, which require a lot of adamant snipers with a lot of lead bullets. Passwords: Handled by IAM services. Tokens: Application frameworks which not to divulge. But Brian's phone number stashed in an innocuous case metadata field. Gaah!
Some of the same techniques apply, like using domain primitives, but some PII (like names and addresses) is eventually templated into flatter (text) values, and processed by other layers which do not recognize 'brands' as suggested.
Data scanners: Regexes are fine for SSNs and the like, but to be really effective, one would need a full-on Named Entity Recognition in the pipeline, perhaps just as a canary. (Wait, that might actually work?)
Dataflow analysis and control applies in a BIG way, e.g. separating an audit log for forensics, where you really NEED the PII, from a technical log which the SREs can dig into without being suspected of stealing sensitive info. Start there.