Unable to run the targetAllocator in namespace mode #3086
Assignees
Labels
area:rbac
Issues relating to RBAC
area:target-allocator
Issues for target-allocator
enhancement
New feature or request
good first issue
Good for newcomers
Comments
|
the target allocator already has a servicemonitor and podmonitor namespace selectro, we just need to expose it in the operator here. |
jaronoff97
added
enhancement
|
Hi @jaronoff97 I'd love to know if this is still being worked on? |
|
@RichardChukwu I don't believe so... cc @alita1991 are you still interested in working on this? |
|
I would love to contribute on this 😄 I submitted a PR here, let me know what do you think #3573 |
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 3, 2025
It's currently not possible to deploy the TA without cluster-wide permisisons. This change introduces a new env variable to the TA, WATCH_NAMESPACE, which allows for specifying which namespaces to watch. This approach is similar to how the opentelemetry-operator can be scoped to watch a single namespace. This does mean that cluster-wide resource like node metrics (cAdvisor) are no longer accessible, but this is acceptable since we only want the TA to know about targets that exist a specific namespaces. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 3, 2025
It's currently not possible to deploy the TA without cluster-wide permisisons. This change introduces a new env variable to the TA, WATCH_NAMESPACE, which allows for specifying which namespaces to watch. This approach is similar to how the opentelemetry-operator can be scoped to watch a single namespace. This does mean that cluster-wide resource like node metrics (cAdvisor) are no longer accessible, but this is acceptable since we only want the TA to know about targets that exist a specific namespaces. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 15, 2025
It's currently not possible to deploy the TA without cluster-wide permisisons. This change introduces a new env variable to the TA, WATCH_NAMESPACE, which allows for specifying which namespaces to watch. This approach is similar to how the opentelemetry-operator can be scoped to watch a single namespace. This does mean that cluster-wide resource like node metrics (cAdvisor) are no longer accessible, but this is acceptable since we only want the TA to know about targets that exist a specific namespaces. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 15, 2025
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: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 15, 2025
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: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 16, 2025
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. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to by this '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA are created in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 17, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to by this '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA are created in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 18, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to by this '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA are created in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 18, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to by this '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA are created in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 18, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to by this '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA are created in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 18, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to by this '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA are created in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 18, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. Validation is performed at the admission webhook and TA startup to validate that both fields are not set at the same time. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to the '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
CharlieTLe
added a commit
to CharlieTLe/opentelemetry-operator
that referenced
this issue
Mar 18, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. Validation is performed at the admission webhook and TA startup to validate that both fields are not set at the same time. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to the '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: open-telemetry#3086 Signed-off-by: Charlie Le <[email protected]>
swiatekm
pushed a commit
that referenced
this issue
Mar 18, 2025
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 list of namespaces for the target allocator to watch. If set to an empty list, it will list all namespaces in the cluster. This is mutually exclusive with denyNamespaces. Defaults to an empty list. - denyNamespaces is a list of namespaces for the target allocator to not watch. If set to an empty list, it will not exclude any namespaces. This is mutually exclusive with allowNamespaces. Defaults to an empty list. Validation is performed at the admission webhook and TA startup to validate that both fields are not set at the same time. A new end to end test was created, e2e-targetallocator/targetallocator-namespace, to test setting allowNamespaces and denyNamespaces. The first part of the test sets up a a collector and TA in a namespace suffixed with '-top-secret'. The TA in this namespace is configured with the allowNamespaces to the '-top-secret' namespace. Then a check is performed to make sure that it can discover the service monitor that is created by the otel-operator. This setup also doesn't make use of any ClusterRole as it only creates a Role to perform its task of discovering targets in its own namespace. The second part of the test sets up another collector and TA in a separate namespace without the '-top-secret' namespace with a ClusterRole. The denyNamespaces is set to the namespace suffixed with the '-top-secret' namespace, and later we check that we can't discover the ServiceMonitor that is in the 'top-secret' namespace. We also check that it can still discover the ServiceMonitor that is in its own namespace. Documentation was added to the otel-allocator README on how to set allowNamespaces to configure the scope that the TA is allowed to interact with. Fixes: #3086 Signed-off-by: Charlie Le <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Component(s)
target allocator
Describe the issue you're reporting
Hi,
I'm trying to run the targetAllocator in namespace mode, but I encountered the following errors:
Config
The collector is configured to run with a serviceAccount bound to a Role, limiting access to a namespace only.
The text was updated successfully, but these errors were encountered: