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
When the target allocator is configured to watch Prometheus custom
resources in the cluster to discover targets, it is currently hard-coded
to require a ClusterRole with a policy rule of listing namespaces. This
prevents usage in environments where configuring ClusterRoles is not
permitted i.e. in namespace-as-a-service setups where only Roles can be
created.
This change introduces two fields in the prometheusCR specification to
allow configuring the namespaces that can be interacted with by the
target allocator.
- allowNamespaces is a comma-separated list of namespaces for the target
allocator to watch. If set to an empty string, it will list all
list all namespaces in the cluster. This is mutually exclusive with
denyNamespaces. Defaults to an empty string.
- denyNamespaces is a comma-separated list of namespaces for the target
allocator to not watch. If set to an empty string, it will not exclude
any namespaces. This is mutually exclusive with allowNamespaces.
Defaults to an empty string.
Fixes: #3086
Signed-off-by: Charlie Le <[email protected]>
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
2
+
change_type: enhancement
3
+
4
+
# The name of the component, or a single word describing the area of concern, (e.g. collector, target allocator, auto-instrumentation, opamp, github action)
5
+
component: target allocator
6
+
7
+
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
8
+
note: |
9
+
Add support for setting the allowNamespaces and denyNamespaces in the target allocator.
10
+
11
+
# One or more tracking issues related to the change
12
+
issues: [3086]
13
+
14
+
# (Optional) One or more lines of additional information to render under the primary note.
15
+
# These lines will be padded with 2 spaces and then inserted directly into the document.
16
+
# Use pipe (|) for multiline entries.
17
+
subtext: |
18
+
allowNamespaces can be set to an empty string to watch all namespaces (default) or to a comma-separated list of namespaces to watch.
19
+
denyNamespaces can be set to an empty string to deny watching any namespaces (default) or to a comma-separated list of namespaces to deny watching.
Copy file name to clipboardexpand all lines: apis/v1beta1/targetallocator_types.go
+6
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,12 @@ type TargetAllocatorPrometheusCR struct {
12
12
// Enabled indicates whether to use a PrometheusOperator custom resources as targets or not.
13
13
// +optional
14
14
Enabledbool`json:"enabled,omitempty"`
15
+
// AllowNamespaces Namespaces to scope the interaction of the Target Allocator and the apiserver (allow list). This is mutually exclusive with DenyNamespaces.
// DenyNamespaces Namespaces to scope the interaction of the Target Allocator and the apiserver (allow list). This is mutually exclusive with AllowNamespaces.
Before the TargetAllocator can start scraping, you need to set up Kubernetes RBAC (role-based access controls) resources. This means that you need to have a `ServiceAccount` and corresponding cluster roles so that the TargetAllocator has access to all of the necessary resources to pull metrics from.
194
+
Before the TargetAllocator can start scraping, you need to set up Kubernetes RBAC (role-based access controls) resources. This means that you need to have a `ServiceAccount` and corresponding ClusterRoles/Roles so that the TargetAllocator has access to all the necessary resources to pull metrics from.
195
195
196
-
You can create your own `ServiceAccount`, and reference it in `spec.targetAllocator.serviceAccount` in your `OpenTelemetryCollector` CR. You’ll then need to configure the `ClusterRole` and `ClusterRoleBinding` for this `ServiceAccount`, as per below.
196
+
You can create your own `ServiceAccount`, and reference it in `spec.targetAllocator.serviceAccount` in your `OpenTelemetryCollector` CR. You’ll then need to configure the `ClusterRole` and `ClusterRoleBinding` or `Role` and `RoleBinding` for this `ServiceAccount`, as per below.
197
+
198
+
#### Cluster-scoped RBAC
197
199
198
200
```yaml
199
201
targetAllocator:
@@ -204,11 +206,11 @@ You can create your own `ServiceAccount`, and reference it in `spec.targetAlloca
204
206
```
205
207
206
208
> 🚨 **Note**: The Collector part of this same CR *also* has a serviceAccount key which only affects the collector and *not*
207
-
the TargetAllocator.
209
+
> the TargetAllocator.
208
210
209
-
If you omit the `ServiceAccount` name, the TargetAllocator creates a `ServiceAccount` for you. The `ServiceAccount`’s default name is a concatenation of the Collector name and the `-targetallocator` suffix. By default, this `ServiceAccount` has no defined policy, so you’ll need to create your own `ClusterRole` and `ClusterRoleBinding` for it, as per below.
211
+
If you omit the `ServiceAccount` name, the TargetAllocator creates a `ServiceAccount` for you. The `ServiceAccount`’s default name is a concatenation of the Collector name and the `-targetallocator` suffix. By default, this `ServiceAccount` has no defined policy, so you’ll need to create your own `ClusterRole` and `ClusterRoleBinding` or `Role` and `RoleBinding` for it, as per below.
210
212
211
-
The role below will provide the minimum access required for the Target Allocator to query all the targets it needs based on any Prometheus configurations:
213
+
The ClusterRole below will provide the minimum access required for the Target Allocator to query all the targets it needs based on any Prometheus configurations:
212
214
213
215
```yaml
214
216
apiVersion: rbac.authorization.k8s.io/v1
@@ -242,7 +244,7 @@ rules:
242
244
verbs: ["get"]
243
245
```
244
246
245
-
If you enable the the `prometheusCR` (set `spec.targetAllocator.prometheusCR.enabled` to `true`) in the `OpenTelemetryCollector` CR, you will also need to define the following roles. These give the TargetAllocator access to the `PodMonitor` and `ServiceMonitor` CRs. It also gives namespace access to the `PodMonitor` and `ServiceMonitor`.
247
+
If you enable the `prometheusCR` (set `spec.targetAllocator.prometheusCR.enabled` to `true`) in the `OpenTelemetryCollector` CR, you will also need to define the following ClusterRoles. These give the TargetAllocator access to the `PodMonitor` and `ServiceMonitor` CRs. It also gives namespace access to the `PodMonitor` and `ServiceMonitor`.
246
248
247
249
```yaml
248
250
apiVersion: rbac.authorization.k8s.io/v1
@@ -263,8 +265,81 @@ rules:
263
265
verbs: ["get", "list", "watch"]
264
266
```
265
267
266
-
> ✨ The above roles can be combined into a single role.
268
+
> ✨ The above ClusterRoles can be combined into a single ClusterRole.
269
+
270
+
#### Namespace-scoped RBAC
271
+
272
+
If you want to have the TargetAllocator watch a specific namespace, you can set the allowNamespaces field
273
+
in the TargetAllocator's prometheusCR configuration. This is useful if you want to restrict the TargetAllocator to only watch Prometheus
274
+
CRs in a specific namespace, and not have cluster-wide access.
275
+
276
+
```yaml
277
+
targetAllocator:
278
+
enabled: true
279
+
serviceAccount: opentelemetry-targetallocator-sa
280
+
prometheusCR:
281
+
enabled: true
282
+
allowNamespaces: foo
283
+
```
284
+
285
+
In this case, you will need to create a Role and RoleBinding instead of a ClusterRole and ClusterRoleBinding. The Role
286
+
and RoleBinding should be created in the namespace specified by the allowNamespaces field.
267
287
288
+
```yaml
289
+
apiVersion: rbac.authorization.k8s.io/v1
290
+
kind: Role
291
+
metadata:
292
+
name: opentelemetry-targetallocator-role
293
+
rules:
294
+
- apiGroups:
295
+
- ""
296
+
resources:
297
+
- pods
298
+
- services
299
+
- endpoints
300
+
- configmaps
301
+
- secrets
302
+
- namespaces
303
+
verbs:
304
+
- get
305
+
- watch
306
+
- list
307
+
- apiGroups:
308
+
- apps
309
+
resources:
310
+
- statefulsets
311
+
verbs:
312
+
- get
313
+
- watch
314
+
- list
315
+
- apiGroups:
316
+
- discovery.k8s.io
317
+
resources:
318
+
- endpointslices
319
+
verbs:
320
+
- get
321
+
- watch
322
+
- list
323
+
- apiGroups:
324
+
- networking.k8s.io
325
+
resources:
326
+
- ingresses
327
+
verbs:
328
+
- get
329
+
- watch
330
+
- list
331
+
- apiGroups:
332
+
- monitoring.coreos.com
333
+
resources:
334
+
- servicemonitors
335
+
- podmonitors
336
+
- scrapeconfigs
337
+
- probes
338
+
verbs:
339
+
- get
340
+
- watch
341
+
- list
342
+
```
268
343
269
344
### Service / Pod monitor endpoint credentials
270
345
@@ -420,4 +495,3 @@ Shards the received targets based on the discovered Collector instances
420
495
421
496
### Collector
422
497
Client to watch for deployed Collector instances which will then provided to the Allocator.
factory:=informers.NewMonitoringInformerFactories(map[string]struct{}{v1.NamespaceAll: {}}, map[string]struct{}{}, mClient, allocatorconfig.DefaultResyncTime, nil) //TODO decide what strategy to use regarding namespaces
0 commit comments