Introduction

In Kubernetes, a ServiceAccount is a namespaced resource, so it does not "belong" to multiple namespaces at once. What you can do is create the service account in one namespace and grant it permissions to act on resources in other namespaces through RBAC bindings.

The Core Rule

A service account always has a namespace-qualified identity:

system:serviceaccount:my-namespace:my-service-account

That identity is fixed. You cannot create one ServiceAccount object and physically attach it to several namespaces the way you might attach a cluster-wide role.

This distinction matters because people often mix up:

• where the service account object lives
• where that identity is authorized to do work

The object is namespaced. The permissions can extend beyond that namespace if RBAC grants them.

Cross-Namespace Access with RBAC

Suppose a workload in namespace ops needs to read ConfigMaps from namespace team-a. Create the service account in ops, then bind permissions in team-a.

Service account:

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4  name: reporter
5  namespace: ops

Role in the target namespace:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: configmap-reader
5  namespace: team-a
6rules:
7  - apiGroups: [""]
8    resources: ["configmaps"]
9    verbs: ["get", "list", "watch"]

RoleBinding in the target namespace:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: RoleBinding
3metadata:
4  name: reporter-can-read-configmaps
5  namespace: team-a
6subjects:
7  - kind: ServiceAccount
8    name: reporter
9    namespace: ops
10roleRef:
11  apiGroup: rbac.authorization.k8s.io
12  kind: Role
13  name: configmap-reader

This grants the ops/reporter identity permission inside team-a without moving the service account object out of ops.

One Identity, Many Namespaces

If the same service account needs access in several namespaces, create a RoleBinding in each target namespace.

That pattern is common for:

• controllers that watch several namespaces
• automation jobs that gather data cluster-wide
• platform tools that manage tenant namespaces

If the permissions are the same everywhere, you can define one ClusterRole and bind it separately into multiple namespaces.

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: read-secrets-metadata
5rules:
6  - apiGroups: [""]
7    resources: ["secrets"]
8    verbs: ["get", "list"]

Then create a RoleBinding per namespace that points to that ClusterRole.

What a Pod Can Use

A pod can only specify a service account from its own namespace. For example, a pod in namespace team-a cannot directly set serviceAccountName: reporter if reporter exists only in namespace ops.

That is a different rule from RBAC authorization. Even if ops/reporter has permission in team-a, a pod running in team-a still cannot mount that service account token directly. If workloads in multiple namespaces need service-account-backed identities locally, create one service account per namespace and grant equivalent roles.

When to Use ClusterRoleBinding

If the service account truly needs cluster-wide access, you can bind it with a ClusterRoleBinding:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: reporter-global-read
5subjects:
6  - kind: ServiceAccount
7    name: reporter
8    namespace: ops
9roleRef:
10  apiGroup: rbac.authorization.k8s.io
11  kind: ClusterRole
12  name: view

This is powerful and sometimes necessary, but it widens the blast radius. Prefer namespace-scoped bindings unless the workload genuinely requires cluster-wide reach.

Security Design Guidance

When people ask for one service account across many namespaces, the real need is often one of two things:

• a single workload needs permissions in many namespaces
• many workloads in different namespaces need similar permissions

Those are different designs. For one central workload, a single service account plus multiple bindings is reasonable. For many distributed workloads, one service account per namespace is usually cleaner and safer.

Namespace boundaries exist for isolation. Reusing one identity everywhere can undermine that isolation if you grant more privileges than required.

Common Pitfalls

• Assuming a service account object can live in several namespaces. It cannot; the resource itself is always namespaced.
• Trying to reference a service account from another namespace in a pod spec. Pods can only use service accounts from their own namespace.
• Using a ClusterRoleBinding when namespace-scoped RoleBinding objects would be sufficient. That grants broader access than necessary.
• Forgetting to specify the subject namespace in the RoleBinding. The binding must identify the service account as name plus namespace.
• Solving "similar permissions in many namespaces" with one shared identity when separate service accounts would provide better isolation and auditing.

Summary

• A Kubernetes ServiceAccount belongs to exactly one namespace.
• That identity can still be authorized in other namespaces through RBAC.
• Use RoleBinding in each target namespace for least-privilege cross-namespace access.
• Pods cannot directly use a service account that exists in another namespace.
• Choose between one central identity and many local identities based on workload placement and security boundaries.