Masking email addresses in logs is not just good hygiene — it’s a security necessity. Compliance rules, privacy standards, and security audits all demand it. Yet in most systems, sensitive data still leaks into log files by accident. Sometimes it comes from debug prints buried deep in code. Sometimes from upstream services you don’t control. The problem is rarely catching it before it’s written out. That’s where Open Policy Agent (OPA) comes in.
Why Mask Emails in Logs
Email addresses qualify as personally identifiable information (PII). Storing them in plain text inside logs risks data breaches, internal misuse, and compliance violations under laws like GDPR and CCPA. Even if logs are access-controlled, they’re often shipped to external systems, copied into backups, and shared during troubleshooting. One overlooked file can end up everywhere.
Masking means detecting the sensitive pattern before it’s logged and replacing it with a safe placeholder. For email addresses, most teams use formats like ***@domain.com or masked@example.com. The goal is to preserve the rest of the log while removing the sensitive part.
Using Open Policy Agent (OPA) for Log Masking
OPA lets you enforce data-handling rules outside of application code. Instead of retrofitting every logging statement, you define a central policy. That policy runs wherever logs are processed — before they’re written to disk, streamed to a data store, or sent to a log aggregation service.
A Rego policy for masking email addresses can match patterns with regex and output a transformed string. That policy can run inside your services, in sidecars, or in log processing pipelines. For example, you can configure an OPA policy that:
- Scans each log line for an email address pattern.
- Replaces the local part with asterisks.
- Passes the masked line forward to your logging backend.
The benefit: the same policy applies across all services without rewriting code. One update to the OPA rule and your entire stack respects it.
Example Rego Pattern for Email Masking
package log.masking
mask_email_address(s) = output {
pattern := `([a-zA-Z0-9._%+-]+)@([a-zA-Z0-9.-]+\.[a-zA-Z]{2,})`
re_match(pattern, s)
output := regex.replace_string(pattern, s, "***@$2")
}
You can call this rule as part of your log pipeline. Anything matching the pattern gets replaced instantly.
Integrating at Scale
To make masking effective, integrate OPA into your logging infrastructure — not just in one service. If you use Kubernetes, run OPA as a sidecar to intercept logs. If you stream logs via Fluent Bit or Vector, send lines through OPA before pushing to storage. This ensures policies are consistent and always enforced.
Testing and Auditing the Policies
A masking policy must be tested like any other security control. Run sample logs through it. Inspect the outcomes. Confirm that valid emails are masked and that other log data remains untouched. Audit regularly. Update regex to handle edge cases. Policies are living code.
Email masking with OPA transforms security from reactive to automatic. Once deployed, it reduces the risk of sensitive data leakage without slowing development. It also places control in the hands of policy managers, who can adapt rules without waiting for code deployments.
You can ship a proof-of-concept in under an hour. You can see it live in minutes. With hoop.dev, you can connect OPA-powered policies directly into your pipelines and watch email masking happen in real time — no guesswork, no risk, just clean logs.