High Security Mode in New Relic doesn’t just mask data; it fundamentally re-architects how data is collected and transmitted, prioritizing privacy over granular detail.
Let’s see this in action. Imagine you have a standard New Relic application setup. You’re collecting requests, database queries, external calls, and even the arguments passed to your functions.
# Standard New Relic instrumentation (conceptual)
NewRelic::Agent.record_metric('Custom/UserLogin', duration)
NewRelic::Agent.record_span('External/API/getUser', {
:host => 'api.example.com',
:method => 'GET',
:path => '/users/123',
:request_params => { 'fields' => 'email,name' } # Sensitive data here!
})
Now, let’s enable High Security Mode. This is typically done via configuration, either in newrelic.yml or through environment variables.
newrelic.yml example:
common: &common
license_key: YOUR_LICENSE_KEY
high_security: true # <-- This is the key setting
# ... other settings
Environment variable example:
export NEW_RELIC_HIGH_SECURITY=true
export NEW_RELIC_LICENSE_KEY=YOUR_LICENSE_KEY
Once enabled, the agent’s behavior changes before data even leaves your application. Instead of sending raw request parameters or function arguments, New Relic automatically sanitizes them.
What actually happens:
When High Security Mode is enabled, the New Relic agent overrides its default data collection and sanitization mechanisms. Instead of sending potentially sensitive data like request parameters, HTTP headers, or custom event attributes as-is, it applies a strict, pre-defined set of masking rules. This is a network-level security feature designed to prevent accidental exposure of PII or other confidential information during transmission and storage. The agent’s internal processors that would normally capture and format this data are bypassed in favor of a more generalized, less detailed collection process.
The core problem High Security Mode solves is data leakage. In many applications, request payloads, URL parameters, and even internal function arguments can inadvertently contain personally identifiable information (PII), API keys, passwords, or other sensitive credentials. Without robust, application-level sanitization, these details could be sent to New Relic and potentially exposed in dashboards or logs. High Security Mode provides a system-wide safeguard, ensuring that such data is never transmitted in the first place.
How it works internally:
At its heart, High Security Mode enforces a strict data filtering policy at the agent level. When enabled, the agent’s instrumentation code that would normally capture detailed request attributes (like request_params, request.headers, response.headers, etc.) is modified. Instead of collecting and formatting these attributes, it either discards them entirely or replaces them with generic placeholders. This applies to both transaction traces and custom events. The agent also restricts the types of data that can be sent in custom events, often limiting them to predefined, non-sensitive categories or requiring explicit whitelisting. The goal is to reduce the attack surface by minimizing the amount of sensitive information that ever enters the New Relic data pipeline.
Levers you control:
While High Security Mode is largely an "on/off" switch for strict sanitization, you still have some control over what does get sent.
attributes.include/attributes.exclude: Even in High Security Mode, you can use these configurations to explicitly include certain types of attributes that might otherwise be excluded. For instance, if you need to track a specific, non-sensitive custom attribute, you can include it. However, the values of these attributes will still be subject to masking if they fall into sensitive categories.- Custom Events: You can send custom events, but the types of data you can include within them are heavily restricted. You’ll typically be limited to numerical or boolean values and short string identifiers.
- Error Reporting: Error messages themselves are generally not masked, but any context or data attached to an error event might be.
The one thing most people don’t know:
High Security Mode doesn’t just mask data; it also affects the granularity of transaction traces. While you’ll still see the overall duration of operations and the services called, the detailed breakdown of which specific arguments were passed to those operations or which exact headers were present in an HTTP request will be absent. This is a deliberate trade-off: maximum security means sacrificing some diagnostic detail that might have revealed the root cause of a subtle bug related to specific input values. You’re trading fine-grained debugging for system-wide data privacy.
The next thing you’ll likely run into is understanding how to re-enable specific, necessary data points without compromising security, usually through careful use of attributes.include and custom event design.