Yes — this error is usually an RBAC issue in the Kubernetes worker itself, not necessarily a failure in the actual Kubernetes Job. In Prefect 2.20, the Kubernetes worker tries to read the

kube-system

namespace to derive a cluster UID. That value is used to build Prefect’s infrastructure PID for the submitted job. Your worker’s service account does not have permission to

get namespaces

, so Prefect logs the submission as failed:

text
namespaces "kube-system" is forbidden: User "system:serviceaccount:pactrispro:prefect-worker" cannot get resource "namespaces"

What’s confusing here is that the Job may already have been created successfully, so you can see: - Prefect logs a submission error - the Kubernetes Job still starts - and the flow may run anyway So the likely issue is: the worker can create the job, but fails afterward when trying to compute/read metadata used for tracking it properly. Why this happens in Prefect 2.20 - Prefect 2.x Kubernetes worker reads

kube-system

to get a stable cluster identifier - that requires cluster-scoped permission to read namespaces - without it, the worker raises the 403 you’re seeing Most likely fixes 1. Grant the worker permission to read namespaces This is the direct RBAC fix. Your worker service account needs cluster-level permission for

namespaces/get

. Example:

yaml
apiVersion: <http://rbac.authorization.k8s.io/v1|rbac.authorization.k8s.io/v1>
kind: ClusterRole
metadata:
  name: prefect-worker-cluster-reader
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get"]
---
apiVersion: <http://rbac.authorization.k8s.io/v1|rbac.authorization.k8s.io/v1>
kind: ClusterRoleBinding
metadata:
  name: prefect-worker-cluster-reader-binding
subjects:
- kind: ServiceAccount
  name: prefect-worker
  namespace: pactrispro
roleRef:
  apiGroup: <http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>
  kind: ClusterRole
  name: prefect-worker-cluster-reader

2. Set a cluster UID manually A cleaner workaround in Prefect 2.x is to provide the cluster UID via environment variable so Prefect doesn’t need to read

kube-system

. Try setting:

bash
PREFECT_KUBERNETES_CLUSTER_UID=my-cluster-uid

Depending on your integration version, this may also be recognized as:

bash
PREFECT_INTEGRATIONS_KUBERNETES_CLUSTER_UID=my-cluster-uid

You’d add that env var to the worker deployment/pod. Why the flow still runs If the Job submission happened before the metadata lookup failed, Kubernetes will still run the Job. The error is then about Prefect’s ability to fully register/track that infrastructure submission, not necessarily about the Job launch itself. That matches your observation exactly: - “job starts by crashing” from Prefect’s perspective - then “proceeds to run successfully” in the cluster What I’d check next 1. Confirm whether the Kubernetes Job object is created before the error is emitted. 2. Inspect worker logs around the failure to see whether the 403 happens after job creation. 3. Either: - add

namespaces/get

RBAC, or - set

PREFECT_KUBERNETES_CLUSTER_UID

explicitly Recommendation Since you’re on Prefect 2.20, I’d start with the env var workaround if you want the smallest change. If your platform team is okay with cluster-scoped read access to namespaces, the RBAC fix is also fine. If you want, I can help you with either: - a full minimal RBAC manifest for a Prefect 2.20 Kubernetes worker, or - the exact place to set

PREFECT_KUBERNETES_CLUSTER_UID

in your worker Helm/deployment config.