ability to add an auth module as part of the receiver component

[nagarajatantry]

Is your feature request related to a problem? Please describe.
We are using the http endpoint as one of the receiver endpoints. Our company mandates to add an authentication layer which seems to be missing today.

Describe the solution you'd like
Couple of thoughts

• We can add a Processor in our pipeline, which will perform authentication. In this solution, header information needs to be available for this component.
  Config Snippet example

  receivers:
   otlp:
    protocols:
      http: 
        endpoint: "0.0.0.0:8443"
        tls_settings:
          key_file: /key.pem # path to private key
          cert_file: /cert.pem # path to certificate
  processors:
   auth:
   batch:
   queued_retry:
  
  exporters:
   logging:
     logLevel: debug
  
  service:
  
   pipelines:
     traces:
       receivers: [otlp]
       processors: [auth, batch, queued_retry]
       exporters: [logging]
  
  

• Ability to add a Preprocessor module before the Receiver component.

Describe alternatives you've considered
At present thinking of using nginix proxy, to do the auth.

[jpkrohling]

I'm currently working on an authentication processor, but it'll be executed as a regular processor, not before the receivers. What kind of auth backend did you have in mind? Right now, the processor I'm writing supports verifying a bearer token against a OIDC provider, which should be flexible enough. It requires an OIDC server, which seems fair to me, as most people are (or should) using an auth server anyway.

@open-telemetry/collector-approvers, is this something that would be considered for this repository? Or would it be more suitable for the contrib repository?

[nagarajatantry]

My use case is to validate the JSON web token which is present in the header in a custom key. Are the headers available in the regular processor?

[jpkrohling]

By custom key, do you mean that you are using a header other than HTTP's regular Authorization header? If so, would you mind sharing the reasoning?

[tigrannajaryan]

Triagged. Needs further discussions.

[jpkrohling]

@bogdandrutu @tigrannajaryan can we have the discussions here, in this issue? The minutes for the last SIG meeting says:

as we have a few questions about how exporters can take advantage of this

I also asked this on Gitter, but still couldn't get any concrete questions...

[nagarajatantry]

By custom key, do you mean that you are using a header other than HTTP's regular Authorization header? If so, would you mind sharing the reasoning?

Yes.. My service is fronted by a proxy layer which does the actual authentication using the Authorization header. Once it is successful it injects a value in the header which my service needs to authenticate. this is to ensure that the request is coming from the proxy layer.

[jpkrohling]

@tigrannajaryan: would you please share what aspects needs discussion? I have a working branch which can serve as a concrete base for the discussion, but at this moment, I have no idea what needs to be discussed...

[bogdandrutu]

@jpkrohling @tannaga is the requirement I am hearing for you:
Need ability to configure gRPC/HTTP receivers to propagate some "Headers" to the context?

Today I heard also about some custom auth needed by AWS for the exporters as well.

Self brainstorming:

• Define how the custom code necessary to be executed by the Receiver/Exporter gets injected to the component.
• Define the interface and what data should the component expose to the auth module.

Because we need this for the exporter as well (no way to have a processor to do this) I think we should go with the model where we define an interface for "Auth" that components can support to configure. There is a question about how this gets configured to the component because yaml static file cannot be used, so there needs to be a custom build of the collector.

Another idea that I have is that we can have the Service support registration for "Auth" plugins (that implement the interface that we need) and pass this to the component (when creating via the create params) based on the type of the component.

[jpkrohling]

Need ability to configure gRPC/HTTP receivers to propagate some "Headers" to the context?

Not quite sure. The gRPC receivers do propagate the HTTP headers down to the context already, which is what I'm using in the prototype:

https://github.com/jpkrohling/opentelemetry-collector/blob/cd26dc1dd30d90697580fad495b0898e44909749/processor/authenticationprocessor/oidc_authenticator.go#L68-L71

I'd still need to check other gRPC receivers, as well as other plain HTTP receivers, though.

Today I heard also about some custom auth needed by AWS for the exporters as well.

What kind of custom auth do they need? Nowadays, the world has converged to OIDC as a standard for auth, and I'm sure AWS does support this type of authentication. The only other auth mechanism that I would consider supporting from day 1 is basic HTTP auth. Authorization might be a totally different thing, though.

• Define how the custom code necessary to be executed by the Receiver/Exporter gets injected to the component.
• Define the interface and what data should the component expose to the auth module.

I don't think we need any auth custom code to be executed by receivers/exporters. We might need it for auth/z, but this can be discussed separately.

Because we need this for the exporter as well (no way to have a processor to do this) I think we should go with the model where we define an interface for "Auth" that components can support to configure

I might be misunderstanding you, and you might be talking about authorization instead of authentication, but the gRPC exporters are able to send auth tokens on a per-RPC basis:

opentelemetry-collector/config/configgrpc/configgrpc.go

Lines 200 to 208 in 1e65674

	if gcs.PerRPCAuth != nil {
	if strings.EqualFold(gcs.PerRPCAuth.AuthType, PerRPCAuthTypeBearer) {
	sToken := gcs.PerRPCAuth.BearerToken
	token := BearerToken(sToken)
	opts = append(opts, grpc.WithPerRPCCredentials(token))
	} else {
	return nil, fmt.Errorf("unsupported per-RPC auth type %q", gcs.PerRPCAuth.AuthType)
	}
	}

Given that we have a common HTTP client as well, it would be trivial to add a similar support to it. In fact, a workaround that works already is to add a header named Authorization with similar contents to what the gRPC's PerRPCAuth has.

In a future iteration, we might need the capacity to propagate headers from the receiver to the exporter without an authentication processor in the middle, for the use case of chained collectors:

otelcol as agent sends auth token -> 
  otelcol as data-center aggregator, no auth -> 
    otelcol as backend, needs auth

That all said, here's my proposal based on the prototype I have:

Add a new authentication processor that:

1. allows users to configure the HTTP/gRPC header to read auth data from. Default: "[Aa]uthorization", as defined by the HTTP[/2] spec
2. allows users to use either basic HTTP or OIDC as authentication mechanisms
   1. when using HTTP, a htpasswd file shall be used
   2. when using OIDC, a OIDC server shall be specified to validate tokens
3. auth mechanism shall place the subject (required) and group information (when available) into the context, for usage in subsequent components (like a future auth/z processor)

Sample YAML files following the proposal:

receivers:
  examplereceiver:

processors:
  authentication:
    sourceheader:
      grpc: authentication
      http: "X-Auth-Token"
    oidc:
      issuer_url: http://localhost:1234
      client_id: ec013524-d001-11ea-a711-482ae389cd6a
      issuer_ca_path: /etc/pki/ca-trust/source/anchors/cacert.crt
      username_claim: username
      groups_claim: membership
  authentication/basic:
    basic:
      htpasswd: /etc/auth/htpasswd

exporters:
  exampleexporter:

service:
  pipelines:
    traces:
      receivers: [examplereceiver]
      processors: [authentication]
      exporters: [exampleexporter]

[bogdandrutu]

@alolita can you tell us about AWS requirements for auth?

[jpkrohling]

@alolita ping ?

[jpkrohling]

@bogdandrutu how can we move forward with this?

[jpkrohling]

As discussed during yesterday's call, @alolita's use case isn't about authenticating incoming requests, but rather, about adding authentication data to outgoing requests, at the exporters level.

As such, I'm opening a PR with the proposal I have, which I believe supports the cases discussed.

[jpkrohling]

@pavolloffay has suggested an alternative approach to this and I would like to discuss it here: instead of having a processor, we could have a new set of options for gRPC and HTTP servers, like this:

type GRPCServerSettings struct {
    Auth *Authentication `mapstructure:"auth,omitempty"`
}

type HTTPServerSettings struct {
    Auth *Authentication `mapstructure:"auth,omitempty"`
}

type Authentication struct {
    OIDC *OIDC `mapstructure:"oidc,omitempty"`
}

type OIDC struct {
	IssuerURL string `mapstructure:"issuer_url"`
	Audience string `mapstructure:"audience"`
	IssuerCAPath string `mapstructure:"issuer_ca_path"`
	UsernameClaim string `mapstructure:"username_claim"`
	GroupsClaim string `mapstructure:"groups_claim"`
}

The ToServerOption/ToServer would then be charged with installing the appropriate interceptors/handlers, so that the authentication step happens before the receiver actually sees the payload. The benefit is that no unnecessary processing is done for unauthenticated calls.

[bogdandrutu]

I thought about this as well. Cannot find enough pros/cons for either of the solutions, so I don't have a strong opinion, but would like to understand why you think that is better?

[jpkrohling]

Mostly this:

The benefit is that no unnecessary processing is done for unauthenticated calls.

Meaning: if a big trace is coming over the wire for an unauthenticated call, it won't be unmarshalled, saving some CPU cycles.

[jpkrohling]

I updated the PR with this new approach and it's ready for review.

[CoderPoet]

Excuse me, I wonder if there will be any follow-up feature progress in this issue.

Such as:

1. How to attach the Subject from the getSubjectFromClaims function to the telemetry data.
2. How to export telemetry data from different tenants to different stores

[CoderPoet]

Excuse me, I wonder if there will be any follow-up feature progress in this issue.

Such as:

1. How to attach the Subject from the getSubjectFromClaims function to the telemetry data.
2. How to export telemetry data from different tenants to different stores

This PR may have answered my questions, and I'm looking forward to seeing how it goes

[secat]

@jpkrohling is there a plan to add the configauth to confighttp?

[jpkrohling]

Yes, eventually. Right now, there's some work going on the client-side auth (exporters) and on propagating the auth data from receivers down the pipeline. If you have the bandwidth, a PR for confighttp based on what we have for configgrpc would be appreciated!

[jpkrohling]

I believe this is now completed.