Home > DevSecOps

RBAC & Network Policies

RBAC and Network Policies are two core security layers in Kubernetes. RBAC controls who can do what through permissions and roles. Network Policies control which pods can talk to each other, enforcing micro-segmentation inside the cluster. Together, they form the foundation of Kubernetes access control and workload isolation.

Understanding RBAC in Kubernetes

Kubernetes RBAC (Role-Based Access Control) defines permissions for users, service accounts, and groups. RBAC controls:

• which APIs can be accessed
• which resources can be modified
• which namespaces can be interacted with
• which actions are allowed (get, list, watch, create, delete, patch, update)

RBAC enforces least privilege across every identity in the cluster.

RBAC Components

Roles

A Role defines permissions within one namespace. It specifies a list of allowed actions on resources.

ClusterRoles

A ClusterRole defines permissions cluster-wide. Used for:

• cluster-level resources
• multi-namespace access
• read-only admin views
• aggregated roles

RoleBindings

Bind Roles to users or service accounts inside a namespace.

ClusterRoleBindings

Bind ClusterRoles to identities across the entire cluster.

RBAC is always about binding identities to permission sets.

RBAC Permission Structure

Permissions specify:

• apiGroups
• resources
• verbs
• resourceNames (optional)

Kubernetes permissions are evaluated at every API call.

Best Practices for RBAC

• follow strict least privilege
• every app uses a dedicated service account
• no default service account access
• avoid cluster-admin
• separate human and machine identities
• audit RBAC usage
• log denied access for security visibility

RBAC hardens identity boundaries inside the cluster.

Understanding Network Policies

Network Policies define which pods can communicate. Without policies, all pods can talk freely. When Network Policies are applied, traffic is denied by default unless explicitly allowed.

Network Policies control:

• pod-to-pod connections
• namespace isolation
• ingress rules
• egress rules
• IP block restrictions

They act like firewalls inside Kubernetes.

Network Policy Components

Pod Selector

Defines which pods the policy applies to.

Ingress Rules

Define allowed inbound traffic.

Egress Rules

Define allowed outbound traffic.

Namespace Selector

Match namespaces for cross-namespace communication.

IPBlock

Allow or deny IP ranges outside the cluster.

Network Policies depend on a CNI plugin that supports them (Calico, Cilium, Weave).

Common Network Policy Patterns

• allow frontend → backend
• deny all egress
• isolate namespace
• allow only DNS traffic
• block cross-namespace communication
• restrict sensitive workloads
• allow metrics pods only to scrape specific endpoints

Network Policies enforce micro-segmentation across all workloads.

Full-Length Practical Section

All practicals are hands-on and cover both RBAC and Network Policy enforcement.

Practical 1: Create a Basic Role

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

This Role allows only read permissions on pods.

Practical 2: Bind Role to a User

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: dev
subjects:
  - kind: User
    name: devuser
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

User devuser can now read pods only in dev.

Practical 3: Create a ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-admin
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["*"]

Applies cluster-wide.

Practical 4: Bind ClusterRole to Service Account

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sa-admin-binding
subjects:
  - kind: ServiceAccount
    name: api-sa
    namespace: backend
roleRef:
  kind: ClusterRole
  name: namespace-admin
  apiGroup: rbac.authorization.k8s.io

Service account gets admin privileges for specified resources.

Practical 5: Check RBAC Permissions

kubectl auth can-i create pods --as devuser -n dev

Test RBAC enforcement.

Practical 6: Create Dedicated Service Account for Applications

kubectl create serviceaccount app-sa

Assign minimal privileges.

Practical 7: Deny Default Service Account Usage

Annotate workloads to avoid using default SA.

Practical 8: Create a Namespace Isolation Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: dev
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Blocks all traffic in dev.

Practical 9: Allow Only Frontend to Talk to Backend

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: app
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend

Only frontend pods can access backend pods.

Practical 10: Allow DNS Outbound Only

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns

Restricts outbound traffic except DNS resolution.

Practical 11: Restrict Egress to Internal Services Only

Limit pods to internal API endpoints.

Practical 12: Block Cross-Namespace Traffic

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-cross-ns
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              allow-access: "true"

Namespaces need explicit labels to communicate.

Practical 13: Logging Network Policy Violations

Use CNI plugin logs (Calico/cilium) to observe denied connections.

Practical 14: Verify Policies With Busybox Pod

kubectl exec -it test -- curl http://backend

Confirm permit/deny behavior.

Practical 15: Create a Network Policy for API Service Isolation

Only API gateway can access internal microservices.

Practical 16: Restrict Access to Database Pods

Allow only app pods:

podSelector: { role: database }

From:

podSelector: { role: app }

Practical 17: Create RBAC Policy for Dev-Only Access

Developers can view resources but cannot modify them.

Practical 18: Implement CI/CD RBAC for Deployments

Create service account with permission to apply manifests:

verbs: ["get", "list", "watch", "patch", "update"]

Practical 19: Combine RBAC + Network Policy for Microservices

Identify:

• who can deploy
• which pods can talk
• which namespaces are isolated

Apply both controls for strong segmentation.

Practical 20: Build Full RBAC + Network Policy Security Architecture

Architecture includes:

• namespace boundary enforcement
• deny-all default network policies
• allowlists for communication
• team-based RBAC roles
• CI/CD service account roles
• separation of privileged and unprivileged accounts
• pod-level micro-segmentation
• enforced least privilege everywhere

This provides strong Kubernetes identity and network security.

Intel Dump

• RBAC controls permissions for users, groups, and service accounts
• roles and bindings enforce least privilege
• network policies control pod-to-pod and namespace communication
• default-deny is the foundation of secure Kubernetes networking
• practicals covered real RBAC creation, bindings, policy verification, namespace isolation, micro-segmentation, service account control, and complete cluster access control architecture

HOME LEARN COMMUNITY DASHBOARD