MeteorOps | DevOps Dictionary

Kubernetes Role

Kubernetes Role is a namespaced RBAC object that defines which actions are allowed on Kubernetes resources inside one namespace. In practical terms, a Role can say that a user, service account, or group may read Pods, update ConfigMaps, or manage Jobs in a specific namespace, but it does nothing until you attach it with a RoleBinding.

What a Kubernetes Role does

A Role is part of Kubernetes RBAC, which stands for Role-Based Access Control. RBAC controls access to the Kubernetes API by checking whether a subject is allowed to perform a verb on a resource.

A Role answers questions such as:

Can this service account list Pods in the payments namespace?
Can this developer update Deployments in the staging namespace?
Can this CI/CD pipeline create Jobs, but not delete Secrets?

Roles help you give teams and automation the minimum permissions they need inside a namespace, without granting wider cluster access.

How it works

A Role contains one or more policy rules. Each rule defines:

apiGroups: the API group for the resource, such as apps for Deployments or an empty string for core resources like Pods and Services.
resources: the resource types the rule applies to, such as pods, deployments, configmaps, or secrets.
verbs: the allowed actions, such as get, list, watch, create, update, patch, or delete.
resourceNames: an optional restriction to specific named resources.

After you create a Role, you bind it to a subject with a RoleBinding. The subject can be a Kubernetes ServiceAccount, an authenticated user, or a group.

Simple example

This Role allows read-only access to Pods in a namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

On its own, this Role grants nothing. You need a RoleBinding like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: staging
  name: read-pods-for-ci
subjects:
  - kind: ServiceAccount
    name: ci-runner
    namespace: staging
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

With both objects in place, the ci-runner service account can read Pods in the staging namespace, but it cannot modify them and cannot access Pods in other namespaces.

Common use cases

CI/CD access: allow a deployment pipeline to update Deployments and read rollout status in one namespace.
Team isolation: let each engineering team manage workloads only in its own namespace.
Read-only debugging: give developers permission to inspect Pods, logs, Events, and Services in staging or production.
Controller permissions: give an operator or in-cluster controller access to the resources it needs to manage.
Secret restrictions: prevent broad access to Secrets unless a workload or operator clearly requires it.

Role vs ClusterRole

A Role is limited to one namespace. A ClusterRole is cluster-scoped.

Use a Role when the permissions should apply only inside one namespace, such as dev, staging, or payments.
Use a ClusterRole when permissions apply to cluster-scoped resources, such as Nodes, PersistentVolumes, or Namespaces.
Use a ClusterRole with a RoleBinding when you want to reuse the same permission template across namespaces while still binding it to one namespace at a time.

For most application team access, start with a Role. Move to ClusterRole only when the permission truly needs cluster-level scope.

Benefits

Least privilege: grant only the actions a user or workload needs.
Namespace boundaries: keep team and environment access separated inside shared clusters.
Auditability: RBAC rules make access easier to review in Git and during security checks.
Automation-friendly: Roles work well with GitOps, Terraform, Helm, and Kubernetes-native controllers.

If you manage Kubernetes access through infrastructure code, you can define Roles and RoleBindings alongside your workloads. For example, teams often manage RBAC together with manifests when they deploy Kubernetes resources using Terraform.

Limitations and common mistakes

A Role does not grant access by itself: you need a RoleBinding.
A Role is namespace-scoped: it cannot grant access to cluster-scoped resources like Nodes.
Wildcard permissions can be risky: rules like resources: ["*"] and verbs: ["*"] are hard to control over time.
Secrets require extra care: read access to Secrets can expose database passwords, API keys, and tokens.
RBAC is additive: Kubernetes does not support deny rules in standard RBAC. If any binding grants an action, the subject has that permission.

Real-world example

Assume a startup runs one shared EKS cluster with separate namespaces for frontend, backend, and data. The backend team needs to restart Deployments and inspect logs in the backend namespace, but should not access the data namespace.

You can create a Role in the backend namespace that allows:

get, list, and watch on Pods
get on Pod logs
get, list, watch, and patch on Deployments

Then you bind that Role to the backend team’s Kubernetes group. The team can debug and restart its own services without gaining broad production access.

Operational guidance

Use separate service accounts for different workloads and pipelines.
Keep Roles small and specific instead of creating one large admin-style Role.
Review RBAC before and after cluster upgrades, especially when API versions change. This is a useful step during Kubernetes upgrades for startups and production teams.
Store Roles and RoleBindings in version control.
Use kubectl auth can-i to test permissions before giving access to users or automation.

For example:

kubectl auth can-i list pods \
  --as=system:serviceaccount:staging:ci-runner \
  --namespace=staging

This command checks whether the ci-runner service account can list Pods in the staging namespace.

Related concepts

RoleBinding: attaches a Role or ClusterRole to a user, group, or service account within a namespace.
ClusterRole: defines permissions that can apply cluster-wide or be reused across namespaces.
ClusterRoleBinding: attaches a ClusterRole at the cluster level.
ServiceAccount: an identity used by Pods, controllers, and automation inside the cluster.
Namespace: the boundary that scopes a Role.

Roles are a core part of secure Kubernetes operations. Whether you are deploying application workloads, running controllers, or managing cloud resources through Kubernetes tools such as Crossplane, clear RBAC boundaries help keep access predictable. If your platform team is building Kubernetes-driven infrastructure workflows, the same access patterns apply when you deploy AWS resources using Crossplane on Kubernetes.

DevOps Dictionary