feat: support configurable namespace for activation job pods #344

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.