---
title: "RBAC, Namespaces and Cluster Roles"
source: "https://www.tigera.io/blog/rbac-namespaces-and-cluster-roles/"
---

[Technical Blog](https://www.tigera.io/category/technical-blog/)

# RBAC, Namespaces and Cluster Roles

By [Scott Coulton](https://www.tigera.io/blog/author/scott-coultonmicrosoft-com/) on Dec 10, 2018 • 4 min read

In this blog post, we are going to look at why it’s a good idea to separate our applications from each other via namespaces and give them the appropriate level of access within the cluster to run. This will prevent the leakage of resources that are namespaced like configmaps or secrets to applications that should not see them.

We are going to assume that you have a Kubernetes cluster available to you. If not you can create one on [AKS](http://docs.microsoft.com/en-us/azure/aks/?WT.mc_id=blog-k8s-sccoulto) on the cloud or locally via [Minikube.](http://kubernetes.io/docs/setup/minikube/)So we will first look at namespaces to separate our applications.

## Namespaces

Let’s look at the default namespaces available to us.

We do this by issuing `kubectl get namespaces`

Kubernetes will place any pods in the default namespace unless another one is specified.

For the next part of the blog, we will create a namespace to use for the rest of the blog. We will do that by issuing

```
`cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Namespace metadata: name: webapp-namespace EOF`
```

Then if we check our namespaces again via `kubectl get namespaces` if we were successful then we should see the new namespace.

## Cluster roles, Service accounts, and Role bindings

Now we have our namespace set up we are going to create a service account and give it full access to that namespace only.

We are now going to create a service account for the namespace that we created earlier.

```
`cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata: name: webapp-service-account namespace: webapp-namespace EOF`
```

Then we will create a role giving us full permissions to the namespace

```
`cat <<EOF | kubectl apply -f - kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: webapp-role namespace: webapp-namespace rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] EOF`
```

Then we will create a role binding to tie it all together

```
`cat <<EOF | kubectl apply -f - kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: webapp-role-binding namespace: webapp-namespace subjects: - kind: ServiceAccount name: webapp-service-account namespace: webapp-namespace roleRef: kind: Role name: webapp-role apiGroup: rbac.authorization.k8s.io EOF`
```

Now lets deploy our application into our new namespace.

```
`cat <<EOF | kubectl apply -f - apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: webapp-deployment namespace: webapp-namespace spec: selector: matchLabels: app: webapp replicas: 1 template: metadata: labels: app: webapp spec: containers: - name: webapp image: scottyc/webapp:latest ports: - containerPort: 3000 hostPort: 3000 EOF`
```

Then we can check our pods simulating the privileges of the service-account we will set up our kubeconfig to only use our service account

We will first get the secret for that service account

```
`SECRET_NAME=$(kubectl get sa webapp-service-account --namespace webapp-namespace -o json | jq -r .secrets[].name)`
```

Then create a ca certificate

```
`kubectl get secret --namespace webapp-namespace "${SECRET_NAME}" -o json | jq -r '.data["ca.crt"]' | base64 --decode > ca.crt`
```

Then get the user token from our secret

```
`USER_TOKEN=$(kubectl get secret --namespace webapp-namespace "${SECRET_NAME}" -o json | jq -r '.data["token"]' | base64 --decode)`
```

Now will will setup our kubeconfig file

```
`context=$(kubectl config current-context) CLUSTER_NAME=$(kubectl config get-contexts "$context" | awk '{print $3}' | tail -n 1) ENDPOINT=$(kubectl config view -o jsonpath="{.clusters[?(@.name == "${CLUSTER_NAME}")].cluster.server}") kubectl config set-cluster "${CLUSTER_NAME}" --kubeconfig=admin.conf --server="${ENDPOINT}" --certificate-authority=ca.crt --embed-certs=true kubectl config set-credentials "webapp-service-account-webapp-namespace-${CLUSTER_NAME}" --kubeconfig=admin.conf --token="${USER_TOKEN}" kubectl config set-context "webapp-service-account-webapp-namespace-${CLUSTER_NAME}" --kubeconfig=admin.conf --cluster="${CLUSTER_NAME}" --user="webapp-service-account-webapp-namespace-${CLUSTER_NAME}" --namespace webapp-namespace kubectl config use-context "webapp-service-account-webapp-namespace-${CLUSTER_NAME}" --kubeconfig="${KUBECFG_FILE_NAME}"`
```

note if you want to cheat there is a shell script [here](http://github.com/scotty-c/kubernetes-security-workshop/blob/master/rbac-namespaces-clusterroles/scripts/kubectl.sh)

We will then load the file in our terminal

```
`export KUBECONFIG=admin.conf`
```

Now let’s check our permissions by seeing if we can list pods in the default namespace

```
`kubectl get pods`
```

Now let’s check our namespace

```
`kubectl get pods --namespace=webapp-namespace`
```

(Check [here](http://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects) for more info about RBAC subjects)

Now we have limited the blast radius of our application to only the namespace that it resides in.

So there will be no way that we can leak configmaps or secrets from other applications that are not in this namespace.

Also made sure that the user or owner of the web application cant hop namespaces and accidentally deploy as the user does not have access.

Remembering the networking is not namespaced so connectivity between applications will still have no issues.

Scott Coulton is a guest blogger with 10 years of experience in the managed services and hosting space. Rolling out systems and network solutions for national and multinational companies with a wide variety of technologies, including Microsoft, AWS, Puppet, Docker and Linux.

————————————————-

[**Free Online Training**](https://www.tigera.io/events/)

Access Live and On-Demand Kubernetes Tutorials

[**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home)

Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption

[How-To](https://www.tigera.io/tags/how-to/)[Open Source](https://www.tigera.io/tags/open-source/)

Add Tigera as a preferred source on Google to see more of our content in your search results.

[![Add as a preferred source on Google](https://www.tigera.io/app/themes/tigera2021/dist/img/google-preferred-source-light.png)](https://www.google.com/preferences/source?q=tigera.io)

## Related posts

[![From Merged PR to Governed Pod: Automating AI Agent Deployment on Kubernetes](https://www.tigera.io/app/uploads/2026/10/From-Merged-PR-to-Governed-Pod-featured.png)](https://www.tigera.io/blog/from-merged-pr-to-governed-pod-automating-ai-agent-deployment-on-kubernetes/)

#### [From Merged PR to Governed Pod: Automating AI Agent Deployment on Kubernetes](https://www.tigera.io/blog/from-merged-pr-to-governed-pod-automating-ai-agent-deployment-on-kubernetes/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Oct 13, 2026

In short, automating the AI agent lifecycle is this year’s pitch: Google Cloud’s walkthrough of 30th July 2026 turns the whole thing into a conversation with a coding agent. On Kubernetes the deploy half of...

[Read more](https://www.tigera.io/blog/from-merged-pr-to-governed-pod-automating-ai-agent-deployment-on-kubernetes/)

[![Save the Address, Save the Cloud: A Hands-on KubeVirt Live Migration Workshop](https://www.tigera.io/app/uploads/2026/07/Save-the-Address-Save-the-Cloud-A-Hands-on-KubeVirt-Live-Migration-Workshop.png)](https://www.tigera.io/blog/save-the-address-save-the-cloud-a-hands-on-kubevirt-live-migration-workshop/)

#### [Save the Address, Save the Cloud: A Hands-on KubeVirt Live Migration Workshop](https://www.tigera.io/blog/save-the-address-save-the-cloud-a-hands-on-kubevirt-live-migration-workshop/)

By [Reza Ramezanpour](https://www.tigera.io/blog/author/rezar/)
on Jul 9, 2026

In the previous post in this series, we covered why Virtual Machine (VM) Live Migration in Kubernetes is difficult: a VM’s IP is its identity, and the “new” VM on the destination node has to...

[Read more](https://www.tigera.io/blog/save-the-address-save-the-cloud-a-hands-on-kubevirt-live-migration-workshop/)

[![What’s new in Calico: Spring 2026 Release](https://www.tigera.io/app/uploads/2026/06/Whats-New-in-Calico-NEW-TEMPLATE-2026.png)](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/)

[Company Blog](https://www.tigera.io/category/company-blog/)

#### [What’s new in Calico: Spring 2026 Release](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/)

By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/)
on Jun 2, 2026

Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs...

[Read more](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/)

<!-- plugin=object-cache-pro client=phpredis metric#hits=6615 metric#misses=24 metric#hit-ratio=99.6 metric#bytes=2080985 metric#prefetches=415 metric#store-reads=34 metric#store-writes=18 metric#store-hits=423 metric#store-misses=13 metric#sql-queries=32 metric#ms-total=1095.46 metric#ms-cache=19.32 metric#ms-cache-avg=0.3789 metric#ms-cache-ratio=1.8 sample#redis-hits=139452521 sample#redis-misses=11293458 sample#redis-hit-ratio=92.5 sample#redis-ops-per-sec=30 sample#redis-evicted-keys=0 sample#redis-used-memory=156971824 sample#redis-used-memory-rss=118763520 sample#redis-memory-fragmentation-ratio=0.8 sample#redis-connected-clients=1 sample#redis-tracking-clients=0 sample#redis-rejected-connections=0 sample#redis-keys=133586 -->