feat: support configurable namespace for activation job pods

[amasolov]

Summary

When a rulebook activation fires, the EDA activation worker creates a Kubernetes Job in the same namespace where EDA is deployed. There is currently no way to direct those activation job pods into a separate namespace, which is a common requirement for security isolation, resource quota management, and NetworkPolicy boundaries.

Current behaviour

The kubernetes.Engine._set_namespace() method in eda-server reads the namespace from the ServiceAccount token file (/var/run/secrets/kubernetes.io/serviceaccount/namespace). All Jobs, Pods, Secrets, and Services created by the activation worker land in the EDA namespace. The operator CRD's activation_worker.node_selector and activation_worker.tolerations only control the worker Deployment itself, not the spawned job pods.

Proposed behaviour

A new optional CRD field (e.g. activation_worker.activation_job_namespace) that, when set:

1. Operator side (eda-server-operator)

• Injects the target namespace as an environment variable (e.g. EDA_ACTIVATION_JOB_NAMESPACE) into the activation worker Deployment via the EDA configmap.
• Creates a RoleBinding in the target namespace granting the EDA ServiceAccount permissions to manage Jobs, Pods, Secrets, and Services (the same verbs the existing activation worker role provides).
• Optionally creates the target Namespace if it does not exist.

2. Server side (eda-server)

• _set_namespace() reads the env var as an override, falling back to the SA token file.
• All create_namespaced_* and list_namespaced_* calls use the configured namespace.

Motivation

• Security isolation: activation job pods run user-supplied rulebooks and decision environments. Separating them from the EDA control plane reduces blast radius.
• Resource quotas: a dedicated namespace allows independent ResourceQuota and LimitRange policies for activation workloads.
• NetworkPolicy: cross-namespace policies can restrict activation pods to only communicate with the EDA API (websocket callback) and required external services.

Implementation considerations

• The EDA CRD is namespace-scoped, so cross-namespace RBAC must be managed explicitly by the operator.
• Activation job pods connect back to the EDA API via websocket. NetworkPolicies must allow this traffic path.
• The operator reconcile loop must keep the RoleBinding in sync (create on first reconcile, update if the SA name changes, clean up on CR deletion).
• Related upstream server PRs: ansible/eda-server#1520 (pod metadata), ansible/eda-server#1545 (tolerations), ansible/eda-server#1534 (resource limits).
• Related RFE: AAPRFE-2827.

[amasolov]

Implementation PRs are up:

• Operator: feat: add configurable namespace for activation job pods #345 — adds activation_job_namespace CRD field, injects EDA_ACTIVATION_JOB_NAMESPACE env var, creates cross-namespace Role + RoleBinding.
• Server: feat: support activation job namespace override via env var eda-server#1546 — reads the env var override in _set_namespace(), falling back to the SA token file.

These two PRs together implement the namespace isolation feature described in this issue. The operator manages the RBAC lifecycle (create on reconcile, clean up when unset), and the server honours the override transparently.

Related PRs for pod scheduling on the server side:

• feat: optional Kubernetes pod metadata for activation jobs eda-server#1520 (nodeSelector, SA, labels, annotations)
• feat: add tolerations support for activation job pods eda-server#1545 (tolerations)