Kubernetes Role-Based Access Control (RBAC) in defense cloud environments carries higher stakes than commercial implementations. IL4/IL5 environments under DISA STIG requirements, DoD cloud authorization frameworks, and multi-mission application isolation all demand precise, auditable RBAC architectures that minimize privilege escalation risk.
This guide covers practical RBAC design patterns and configuration examples for defense cloud Kubernetes deployments.
RBAC Fundamentals in Defense Context
Kubernetes RBAC uses four primary objects:
- Role: Grants permissions within a namespace
- ClusterRole: Grants permissions cluster-wide or can be bound within namespaces
- RoleBinding: Binds a Role to subjects in a namespace
- ClusterRoleBinding: Binds a ClusterRole to subjects cluster-wide
In defense cloud environments, the guiding principle is least privilege — users and service accounts receive only the specific permissions required for their function, nothing more.
Role Design Patterns for Defense Applications
Mission Application Pattern
Each mission application namespace gets dedicated roles with minimal permissions:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: mission-app-alpha
name: app-reader
rules:
- apiGroups: [""]
resources: ["pods", "configmaps", "services"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: mission-app-alpha
name: app-operator
rules:
- apiGroups: [""]
resources: ["pods", "configmaps"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "update", "patch"]
# Note: No delete permissions - requires separate approval workflowService Account Isolation
Every application component gets its own service account — never share service accounts across applications:
apiVersion: v1
kind: ServiceAccount
metadata:
name: telemetry-processor
namespace: mission-app-alpha
annotations:
# AWS EKS: IRSA for pod-level AWS permissions
eks.amazonaws.com/role-arn: arn:aws-us-gov:iam::123456789012:role/telemetry-processor-role
automountServiceAccountToken: false # Opt-in only, never auto-mount
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: mission-app-alpha
name: telemetry-processor
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["telemetry-config"] # Named resource restriction
verbs: ["get", "watch"]Namespace Isolation Strategy
Defense applications often require isolation between classification boundaries, mission systems, and administrative tiers. A layered namespace architecture:
/cluster
/namespace: kube-system # Platform, no user workloads
/namespace: platform-monitoring # Platform admins only
/namespace: mission-app-alpha # Mission A team
/namespace: mission-app-bravo # Mission B team (separate clearances)
/namespace: shared-services # Approved shared utilitiesEnforce namespace isolation with NetworkPolicies alongside RBAC:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: mission-app-alpha
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
egress: [] # No outbound unless explicitly allowed
ingress: [] # No inbound unless explicitly allowedDISA STIG RBAC Requirements
The Kubernetes STIG (DISA STIG for Kubernetes) mandates several specific RBAC configurations:
- V-242436: Kubernetes must use RBAC (disable ABAC) — ensure
--authorization-modeincludesRBAC - V-242384: Service accounts must not have cluster-admin bindings
- V-242448: Prohibit auto-mounting of service account tokens unless explicitly required
- V-242446: Minimize ClusterRoleBindings — review quarterly, remove unused bindings
Check your cluster's RBAC configuration:
# Find all ClusterRoleBindings granting cluster-admin
kubectl get clusterrolebindings -o json | \
jq '.items[] | select(.roleRef.name=="cluster-admin") |
{name: .metadata.name, subjects: .subjects}'
# Find service accounts with wildcard permissions
kubectl auth can-i --list --as=system:serviceaccount:mission-app-alpha:telemetry-processorAudit Logging for RBAC Events
Every RBAC authorization decision must be logged for audit. Configure the API server audit policy:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
users: ["system:serviceaccount:mission-app-alpha:*"]
verbs: ["create", "update", "patch", "delete"]
resources:
- group: ""
resources: ["secrets", "configmaps"]
- level: Metadata
verbs: ["get", "list", "watch"]
resources:
- group: ""
resources: ["secrets"]
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: ""
resources: ["endpoints", "services"]See Rutagon's zero trust network access guide and cybersecurity ATO process for broader security architecture context.
Explore our cybersecurity capabilities.
FAQ
What is the difference between Role and ClusterRole in defense Kubernetes environments?
A Role grants permissions scoped to a single namespace — appropriate for mission application teams who should only access their namespace. A ClusterRole grants permissions across all namespaces or at the cluster level — appropriate only for platform administrators with proper clearance and need-to-know. Defense environments should minimize ClusterRole usage.
How do you prevent privilege escalation in Kubernetes RBAC?
Kubernetes has escalation protection built in — users cannot grant permissions they don't themselves possess. However, indirect escalation paths exist through pods with elevated service accounts, writable configmaps with shell scripts, and deployment controllers. Admission controllers (OPA Gatekeeper, Kyverno) block known escalation patterns at the API server level.
Should defense cloud Kubernetes workloads use IRSA or node-level IAM?
IRSA (IAM Roles for Service Accounts) is strongly preferred in EKS GovCloud environments — it provides pod-level AWS permissions with no credential sprawl, no node-level over-permissioning, and full CloudTrail auditability of which pod made which API call. Node-level IAM instance profiles grant permissions to everything running on that node, violating least-privilege principles.
How frequently should Kubernetes RBAC bindings be audited in DoD environments?
DISA STIG guidance and DoD CCRI preparation typically expects quarterly RBAC reviews at minimum. High-risk bindings (ClusterRoleBindings, any wildcard permissions) should be reviewed more frequently. Automated tooling (OPA Gatekeeper policies) can alert on new ClusterRoleBindings in real time, reducing reliance on periodic audits.
What is the best way to handle break-glass access in defense Kubernetes?
Break-glass (emergency admin) access should use a tightly controlled emergency ClusterRoleBinding that is created, used, and immediately deleted — never left in place. Log every use through the audit policy. Require two-person authorization to activate break-glass credentials. Some organizations use Just-In-Time (JIT) access management platforms that provision temporary elevated access with automatic expiration and full audit trail.