Restrict access to http headers via policy?

[r_weber]

Hey,

I'm trying to address a use case in the best fitting way. What I want to do:

I have traces/spans where custom sensitive http headers are captured. I'm already lost at the capturing part due to the duplication of storage (grail AND classic). So to capture a specific header I created an old-school Request Attribute and marked the RA as "contains confidential data". The RA is captured on Node.Js technology and is perfectly masked for users that do not have the permission to view sensitive data - perfectly fine.

But then there is also the setting "Attribute capturing - Attribute Masking" which per default sets http.request.headers to "Mask Entire value". To my understanding this defines that EVERY http header is masked and again only users with view sensitive data permission can see them.

Without the definition of a RA the header is not in the list of "Request Headers". If I define the RA as "confidential" but the http.requests.headers as "Mask only confidential data" then the RA itself is confidential, however "normal" users can still see the captured "Request Attribute". So the actual value is not masked.

I was now wondering how can I achieve this:

• by default mask all http.request.headers (set Attribute capturing - Attribute Masking to mask entire value)
• allow specific usergroups to only see specific headers within the http.request.headers via policy/policy boundaries
• works in both trace/span/purepath storages

I thought maybe I can assign a security context for spans of specific workloads and fiddle a policy that has a boundary but that doesn't work.

Maybe someone here has another idea?

[Julius_Loman · Accepted solution]

First of all, the Attribute capturing - Attribute Masking applies only to OpenTelemetry Ingested spans (it's actually in this section). 

If the data source is OneAgent and source Request Attribute, the view sensitive data permission is the solution - for Gen2 (old skool purepath storage). For Gen3 (Grail storage) this will work in similar fashion with the fieldset builtin-request-attributes-spans.

So I would use the following policy - this should do both Gen2 and Gen3:

ALLOW storage:fieldsets:read WHERE storage:fieldset-name in ("builtin-sensitive-spans","builtin-request-attributes-spans");
ALLOW environment:roles:view-sensitive-request-data;

I would expect such a policy would be in the default ones, but I think it's not. 

[r_weber]

Thanks @Julius_Loman for the fieldset pointer. I shall try this policy approach.

I assumed that the Attribute capturing - Attribute masking applies only to OTEL ingested. Where I got a bit surprised and wary is the fact that as soon as I defined a RA (sensitive) it also showed on Gen 2 PP under Request Headers AND as RA (on a PurePath view)...where the RA was masked and the Request Header was not.

This confused me and made me look into the Attribute Capturing as well (which is used e.g. for envoy)

[Julius_Loman · Accepted solution]

@r_weber, in my experience, this works the way that HTTP headers are always visible in unchanged form, but only for users with view sensitive information if a request attribute is captured from them. Unless it's a standard header where no sensitive data should be present, such as Host. This applies to Gen2 at least.

So if the source HTTP header was visible in unchanged form and request attribute was masked, this sound either as a bug or it's some kind of general header? What was the header name?

In general, masking has to be improved. Sometimes we need masking even for users with view sensitive data. For example, the Location header can't be masked for users with view sensitive data or not being captured, It often contains very sensitive data, such as authentication tokens. (typical scenario is a deep link to a mobile app after authentication).