Kubernetes RBAC Simplified

In partnership with

Good day. It's Friday, Aug. 16, and in this issue, we're covering:

• Kubernetes RBAC Simplified

• Create a powerful Kubernetes security duo with Custom Org Policy and Policy Controller

• Monitor your Anthropic applications with Datadog LLM Observability

• DevOps Exercises - 2624 exercises and questions

• OpenShift vs. Kubernetes: Understanding the differences

• DigitalOcean Load Balancer: Scaling to 1,000,000+ Connections

You share. We listen. As always, send us feedback at [email protected]

Use Case

Kubernetes RBAC Simplified

Kubernetes RBAC and security are inseparable, as weak access control can expose your cluster to security threats, making it vulnerable to unauthorized access and potential breaches. It is not a 'good to have' or an afterthought; it is a fundamental necessity.

Some of you may already know this. Let's quickly revise how RBAC works.

Step 1: Define Roles (Role or ClusterRole): What actions are allowed within a namespace (Role) or across the entire cluster (ClusterRole).

Step 2: Creating Service Accounts or Users/Groups: Set up service accounts within Kubernetes or manage external users/groups to take on these roles.

Step 3: Bind Roles to Accounts, Users, or Groups: Use RoleBindings to connect roles to service accounts or users within a namespace, or ClusterRoleBindings for cluster-wide permissions.

Here is the simplified visualization of Kubernetes RBAC:

To further understand how RBAC operates, let’s break down the key roles in Kubernetes:

• Cluster-admin: Acts as a superuser with full control over all resources across the cluster and namespaces.

• Admin: Grants complete read and write access within a specific namespace, including creating roles and bindings but not modifying the namespace itself.

• Edit: Allows read and write permissions within a namespace, excluding the ability to view or modify roles or bindings.

• View: Provides read-only access within a namespace, without permission to view or change roles or bindings.

As we are talking about the access control, security control is a more aligned context. Let me introduce Oneleet — a trusted partner for real-world security controls and SOC 2 attestation.

Want SOC 2 compliance without the Security Theater?

Question 🤔 does your SOC 2 program feel like Security Theater? Just checking pointless boxes, not actually building security?

In an industry filled with security theater vendors, Oneleet is the only security-first compliance platform that provides an “all in one” solution for SOC 2.

We’ll build you a real-world Security Program, perform the Penetration Test, integrate with a 3rd Party Auditor, and provide the Compliance Software … all within one platform.

Schedule a demo for pricing

Creating an RBAC role is straightforward, so let’s not go there. Instead, let’s talk about more crucial elements:

How to Check Defined Permissions:

Always verify what your service accounts can do—blind spots lead to security breaches.

Use kubectl auth can-i 

These commands check if the app-sa service account in the prod-app namespace can get secrets, list pods, and create deployments.

kubectl auth can-i get secrets --namespace=prod-app --as=system:serviceaccount:prod-app:app-sa

kubectl auth can-i list pods --namespace=prod-app --as=system:serviceaccount:prod-app:app-sa

kubectl auth can-i create deployments --all-namespaces --as=system:serviceaccount:prod-app:app-sa

Why Default service account shouldn’t be used ?

Default service accounts often have broad permissions that can be a security risk. Create and use custom service accounts to better control and limit access.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: frontend-sa
  namespace: prod-app

Assign this service account to your frontend application pod:

apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
  namespace: prod-app
spec:
  serviceAccountName: frontend-sa

Disabling auto mounting of service account token

Only mount tokens when absolutely necessary for the pod's operation. This way you reduce the significant risk of token exposures.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
  namespace: prod-app
spec:
  serviceAccountName: backend-sa
  automountServiceAccountToken: false

Implementing Least Privilege access

Assign only the permissions that are absolutely necessary for a role to perform its tasks. This minimizes potential damage if a service account is compromised.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod-app
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

Define roles for different permissions, not for different service accounts

This way, you avoid role duplication and can easily update permissions in one place without worrying about multiple service accounts having differing access levels.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod-app
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "update", "delete"]

Security is everyone’s responsibility. RBAC just sets the boundaries.

p.s. if you think someone else you know may like this newsletter, share with them to join here

Tool Of The Day

Lets you search AWS IAM actions and export the results as JSON. It's a simple interface that makes finding the right permissions much easier than digging through AWS docs.

Try it out !

Trends & Updates

Resources & Tutorials

Do you have any suggestions on topics you'd like us to cover? Tell us Here.

Did someone forward this email to you? Sign up here