|
1 | | -## Problem Statement : ## |
2 | | - Process only valid telemetry requests coming from valid secure-agents. |
3 | | - |
4 | | - OTEL Collector (deployed in enterprise cloud) will recieve telemetry requests from agentdeployed on user's on-prem these telemetry requests will arrive via internet thus it is required to filter malicious requests (DOS attack). |
| 1 | +## 1. PROBLEM STATEMENT ## |
| 2 | + **Process only valid telemetry requests coming from valid secure-agents.** |
5 | 3 |
|
| 4 | +OTEL Collector (deployed in enterprise cloud) will recieve HTTP/gRPC telemetry-requests (telemetry-signals) from informatica-secure-agent via internet , thus it is required to filter malicious requests (DOS attack) and allow the data from validated telemetry-signals to be exported to downtream component. |
| 5 | +## 2. GUIDELINES PROVIDED BY OTEL ON CUSTOM AUTHENTICATOR IMPLEMENTATION ## |
| 6 | +(ref :[official otel doc] https://opentelemetry.io/docs/collector/custom-auth/) |
| 7 | + |
| 8 | +The OpenTelemetry Collector allows receivers and exporters to be connected to authenticators, providing a way to both authenticate incoming connections at the receiver’s side, as well as adding authentication data to outgoing requests at the exporter’s side. |
| 9 | + |
| 10 | +This mechanism is implemented on top of the extensions framework provided by OTEL Collector.Authenticators are regular extensions that also satisfy one or more interfaces mentioned below : |
| 11 | + |
| 12 | +**Server Authenticator Interface :** |
| 13 | +(single interface for gRPC and HTTP) |
| 14 | +<pre> 1. <a>go.opentelemetry.io/collector/config/configauth/ServerAuthenticator</a></pre> |
| 15 | + |
| 16 | +**Client Authenticator Interfaces :** |
| 17 | +<pre> |
| 18 | + 1. <a>go.opentelemetry.io/collector/config/configauth/GRPCClientAuthenticator</a> |
| 19 | + 2. <a>go.opentelemetry.io/collector/config/configauth/HTTPClientAuthenticator</a> |
| 20 | +</pre> |
| 21 | + |
| 22 | + |
| 23 | +**Typs of Authenticators :** |
| 24 | + |
| 25 | +**1> Server Authenticator :** |
| 26 | + Used in receivers, intercept incoming HTTP/gRPC request (telemetry-signal), authentication data is expected to be contained in incoming telemetry-signals , this is used for authentication of telemetry signal. |
| 27 | + |
| 28 | +**2> Client Authenticator :** |
| 29 | + Used in exporters, perform client-side authentication for outgoing telemetry signals, add authentication-data to telemetry-signal which is exported to downstream component e.g. Elastic-APM. |
| 30 | + |
| 31 | +## 2.1 Server Authenticator : ## |
| 32 | +It is an GOLang "extension" framework interface-implementation with a _**Authenticate()**_ funtion , receiving the payload-headers as parameter. |
| 33 | + |
| 34 | +If the authenticator is able to authenticate the incoming connection, then **return a nil error** , otherwise return concrete-error. |
| 35 | + |
| 36 | +As an extension, the authenticator should make sure to initialize all the resources it needs during the **Start()** phase, and is expected to clean them up upon **Shutdown()**. |
| 37 | + |
| 38 | +refer : |
| 39 | +<pre><a>https://github.com/open-telemetry/opentelemetry-collector/blob/main/extension/auth/server.go</a> |
| 40 | +<a>https://github.com/open-telemetry/opentelemetry-collector/blob/main/service/extensions/extensions.go</a></pre> |
| 41 | + |
| 42 | +**The Authenticate call is part of the hot path for incoming requests and will block the pipeline if it does not complete execution.** |
| 43 | +Thus it becomes critical to properly handle any blocking operations. Concretely, respect the deadline set by the context, in case one is provided. |
| 44 | + |
| 45 | +## 3.IMPLEMENTATION CONSIDERATIONS ## |
| 46 | + **1> Securing communication between OTEL collector and session service :** |
| 47 | + |
| 48 | + This is performed using one-way ssl ,session service sending server certificate and certificate being validated on otel-collector , ca-certificate would be used to validate SSL certificate provided by sesison-service , ca-certificate setting is optional , in case it is not set go will use system level settings for validating server certs (which might not work correctly) . This certificate is assumed to be mounted in a directory on the file system which is specified in collector run configuration (infa_auth.ca_cert_path) |
| 49 | + |
| 50 | + **2> Securing communication between agent and OTEL collector :** |
| 51 | + |
| 52 | + TO-DO |
| 53 | + |
| 54 | + **3> Securing communication between OTEL collector and Elastic APM server:** |
| 55 | + |
| 56 | + TO-DO |
| 57 | + |
| 58 | + **4> NO session caching :** |
| 59 | + |
| 60 | + Any session info fetched including session expiry time , will not be cached , session service GET agent sesison API |
| 61 | + would be invoked for each arriving telemetry-signal |
| 62 | + |
| 63 | +## 4.IMPLEMENTATION DETAILS ## |
| 64 | + |
6 | 65 |
|
7 | | -## _BUILDING collector binary_ ## |
| 66 | +## 5._BUILDING collector binary_ ## |
8 | 67 |
|
9 | 68 | ```sh |
10 | 69 | ./builder --config=/mnt/c/tmp/otel_build_config.yaml |
|
0 commit comments