RBAC & Admission Controllers

So now you've set up your cluster and everything's working fine — what's stopping the junior devops guy from taking down production completely innocently 😇

This is where a Kubernetes feature comes in that adds a security layer to define the types of actions that can be taken in your cluster

So basically, what's the difference between RBAC and Admission Controllers

1️⃣ RBAC:

You use it to define the types of commands each role is allowed to use, and it has two types based on scope

1️⃣ Namespace scoped "kind: Role"

For example you could block any create/delete command for the junior devops in the production namespace

2️⃣ Cluster scoped "kind: ClusterRole"

For example you can define permissions at the whole Cluster level, not a specific Namespace — block the junior from deleting any Node at the cluster level.

How do you confirm this?

kubectl auth can-i <command> <resource>

kubectl auth can-i delete namespaces

2️⃣ Admission Controller:

Adds more details that you can't express in RBAC, which is why it's a layer that comes after it

For example:

Restrict to a specific Registry: block any Pod from being created if its Image is coming from outside the company's Private Registry

Force the team to set Resource Limits: reject any Deployment that doesn't specify cpu and memory (Requests & Limits).

Prevent using the latest tag: reject any Container filled in with a Tag like image:nginx:latest.

📌 You might need to install an add-on like Kyverno or OPA Gatekeeper

Examples of my own implementations: Github

🤍** I would appreciate If we connect together on LinkedIn :** Visit