You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/edot-collector/config/authentication-methods.md
+56-4Lines changed: 56 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,11 @@ Authentication in the EDOT Collector is handled through extensions that implemen
27
27
28
28
The EDOT Collector supports the following authentication extensions:
29
29
30
-
### Elastic API Key Authentication (`apikeyauth`)
30
+
### Elastic API key authentication (`apikeyauth`)
31
31
32
32
The `apikeyauth` extension is an Elastic-specific authentication method that validates Elasticsearch API keys against your {{es}} cluster. This extension is ideal for authenticating requests from EDOT SDKs and other Collectors that use Elasticsearch API keys.
The `bearertokenauth` extension is an contrib OpenTelemetry authentication method that supports static bearer tokens. This extension is useful for token-based authentication scenarios.
37
37
@@ -71,6 +71,44 @@ service:
71
71
extensions: [apikeyauth]
72
72
```
73
73
74
+
#### Using `apikeyauth` with EDOT SDKs and central configuration
75
+
76
+
The `apikeyauth` authenticator is also used by the `apmconfig` extension when EDOT SDKs retrieve central configuration from the EDOT Collector.
77
+
78
+
EDOT SDKs send their own {{es}} API key to the Collector in the `Authorization` header (for example: `Authorization: ApiKey <Base64(id:key)>`).
79
+
80
+
The Collector does not store or embed the API key. Instead, the `apikeyauth` extension validates the incoming key by calling {{es}} and checking that it has:
81
+
82
+
* `application: "apm"`
83
+
84
+
* privilege: `config_agent:read`
85
+
86
+
* `resources: ["*"]`
87
+
88
+
A minimal configuration for this use case looks like:
89
+
90
+
```yaml
91
+
extensions:
92
+
apikeyauth:
93
+
endpoint: "${ELASTIC_ENDPOINT}"
94
+
application_privileges:
95
+
- application: "apm"
96
+
privileges: ["config_agent:read"]
97
+
resources: ["*"]
98
+
99
+
apmconfig:
100
+
opamp:
101
+
protocols:
102
+
http:
103
+
auth:
104
+
authenticator: apikeyauth
105
+
106
+
service:
107
+
extensions: [apikeyauth]
108
+
```
109
+
110
+
Use `resources: ["*"]` to grant read access for all APM services. A literal dash (`"-"`) is not valid.
111
+
74
112
#### Configuration options
75
113
76
114
The following configuration options are available for the `apikeyauth` extension:
@@ -147,7 +185,9 @@ These use cases show how to configure the `apikeyauth` and `bearertokenauth` ext
147
185
148
186
### Authenticating EDOT SDKs
149
187
150
-
When using EDOT SDKs, configure the `apikeyauth` extension to validate API keys:
188
+
When EDOT SDKs retrieve central configuration from the Collector, they authenticate using an {{es}} API key. The Collector validates this key using the `apikeyauth` extension.
189
+
190
+
For example:
151
191
152
192
```yaml subs=true
153
193
extensions:
@@ -172,6 +212,18 @@ service:
172
212
extensions: [apikeyauth]
173
213
```
174
214
215
+
::::{note}
216
+
EDOT SDKs authenticate by sending their API key in the `Authorization` header. The EDOT Collector doesn't store the API key, it only validates it.
217
+
218
+
Ensure the API key has:
219
+
220
+
* `application: "apm"`
221
+
* `privileges: ["config_agent:read"]`
222
+
* `resources: ["*"]`
223
+
224
+
These privileges allow SDKs to read their central configuration through the Collector.
225
+
::::
226
+
175
227
### Securing collector-to-collector communication
176
228
177
229
Use bearer token authentication for secure communication between collectors:
@@ -195,7 +247,7 @@ service:
195
247
196
248
### Multi-tenant authentication
197
249
198
-
For multi-tenant environments, use the `apikeyauth` extension with tenant-specific headers:
250
+
For multi-tenant environments, use the `apikeyauth` extension with additional cache key headers to ensure privileges are validated for each tenant:
Copy file name to clipboardExpand all lines: docs/reference/edot-collector/config/default-config-standalone.md
+30-10Lines changed: 30 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -291,10 +291,32 @@ The EDOT Collector can be configured to use [APM Agent Central Configuration](do
291
291
292
292
To activate the central configuration feature, add the [`apmconfig`](https://github.com/elastic/opentelemetry-collector-components/blob/main/extension/apmconfigextension/README.md). For example:
293
293
294
-
:::{include} ../_snippets/edot-collector-auth.md
295
-
:::
294
+
```yaml
295
+
extensions:
296
+
apikeyauth:
297
+
endpoint: "${ELASTIC_ENDPOINT}"
298
+
application_privileges:
299
+
- application: "apm"
300
+
privileges: ["config_agent:read"]
301
+
resources: ["*"]
302
+
303
+
apmconfig:
304
+
opamp:
305
+
protocols:
306
+
http:
307
+
auth:
308
+
authenticator: apikeyauth
309
+
```
310
+
311
+
::::{note}
312
+
The EDOT Collector doesn't store or embed the {{es}} API key.
296
313
297
-
Create an API Key following [these instructions](docs-content://deploy-manage/api-keys/elasticsearch-api-keys.md). The API key must have `config_agent:read` permissions and resources set to `-`.
314
+
Each EDOT SDK sends its own API key in the `Authorization` header (for example: `Authorization: ApiKey <Base64(id:key)>`).
315
+
316
+
The `apikeyauth` extension only validates incoming API keys against {{es}}, ensuring they include the `apm` to `config_agent:read` privilege and `resources: ["*"]`.
317
+
::::
318
+
319
+
Create an API Key following [these instructions](docs-content://deploy-manage/api-keys/elasticsearch-api-keys.md). The API key must include the application privilege `config_agent:read` with resources set to `"*"`.
298
320
299
321
## Secure connection
300
322
@@ -323,25 +345,23 @@ extensions:
323
345
324
346
In addition to TLS, you can configure authentication to ensure that only authorized agents can communicate with the extension and retrieve their corresponding remote configurations.
325
347
326
-
The `apmconfig` extension supports any configauth authenticator. Use the `apikeyauth` extension to authenticate with Elasticsearch API keys:
348
+
The `apmconfig` extension supports any `configauth` authenticator. Use the `apikeyauth` extension to authenticate with {{es}} API keys:
327
349
328
350
```yaml
329
351
extensions:
330
352
apikeyauth:
331
-
endpoint: "<YOUR_ELASTICSEARCH_ENDPOINT>"
353
+
endpoint: "${ELASTIC_ENDPOINT}"
332
354
application_privileges:
333
355
- application: "apm"
334
-
privileges:
335
-
- "config_agent:read"
336
-
resources:
337
-
- "-"
356
+
privileges: ["config_agent:read"]
357
+
resources: ["*"]
358
+
338
359
apmconfig:
339
360
opamp:
340
361
protocols:
341
362
http:
342
363
auth:
343
364
authenticator: apikeyauth
344
-
...
345
365
```
346
366
347
367
Create an API key with the minimum required application permissions through {{kib}} under **Observability** → **Applications** → **Settings** → **Agent Keys**, or by using the Elasticsearch Security API:
0 commit comments