Pod Access Control

Pod Access Control

Configure least-privilege access control for Kubernetes workloads by scoping RBAC bindings, isolating namespaces, enforcing resource quotas, and restricting service exposure.

Service Accounts

Every workload pod must use a dedicated, named service account — not the default service account. Default service accounts often carry excessive privileges and make it impossible to apply fine-grained RBAC per workload.

Required for: all profiles (mandatory)

yamlCopy code
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: app-ns
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: app-ns
spec:
  template:
    spec:
      serviceAccountName: app-sa

RBAC Bindings

No ClusterRoleBindings

Workload pods must not use ClusterRoleBindings. Cluster-wide role bindings grant excessive privileges that enable lateral movement across the entire cluster. Use namespace-scoped RoleBindings instead.

Required for: Telco (mandatory), Far-Edge (mandatory), Extended (mandatory), Non-Telco (optional)

yamlCopy code
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-role-binding
  namespace: app-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: app-role
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: app-ns

No Cross-Namespace RoleBindings

Workload RoleBindings must only exist in the workload's own namespace. Cross-namespace role bindings violate tenant isolation and create unintended privilege escalation paths.

Required for: all profiles (mandatory)

CRD-Scoped Roles

If a workload creates Custom Resource Definitions, it must supply a Role that only grants access to those CRDs — not to other API resources. This enforces least-privilege for custom resource access.

Required for: Extended (mandatory), all others (optional)

yamlCopy code
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-crd-role
  namespace: app-ns
rules:
  - apiGroups: ["app.example.com"]
    resources: ["myresources"]
    verbs: ["get", "list", "watch", "create", "update", "delete"]

Namespace Management

Workload resources must be deployed to declared namespaces. Do not use:

• default
• Any namespace prefixed with openshift-
• Any namespace prefixed with istio- or aspenmesh-

These namespaces are reserved for platform components and service mesh infrastructure.

Required for: all profiles (optional, recommended best practice)

Resource Quotas

Workload namespaces must have a ResourceQuota applied to prevent unbounded resource consumption. Without quotas, a single workload can starve other applications of CPU and memory.

Required for: Extended (mandatory), all others (optional)

yamlCopy code
apiVersion: v1
kind: ResourceQuota
metadata:
  name: app-quota
  namespace: app-ns
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"

Resource Requests

All containers must specify CPU and memory resource requests. Requests enable the Kubernetes scheduler to make informed placement decisions and prevent resource contention.

Required for: Telco (mandatory), Far-Edge (mandatory), Extended (mandatory), Non-Telco (optional)

yamlCopy code
containers:
  - name: app
    image: registry.example.com/app:v1.2.3
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi

Service Types

Services must not use NodePort. NodePort services expose applications directly on host ports, creating security risks and potential port conflicts with host services. Use ClusterIP (default) or LoadBalancer instead.

Required for: all profiles (mandatory)

yamlCopy code
apiVersion: v1
kind: Service
metadata:
  name: app-svc
  namespace: app-ns
spec:
  type: ClusterIP
  selector:
    app: app
  ports:
    - port: 8080
      targetPort: 8080

Implementation Checklist

• Each pod uses a dedicated, named service account (not default)
• No ClusterRoleBindings are used by workload pods
• RoleBindings exist only in the workload's own namespace
• CRD roles only grant access to CRDs, not other API resources
• Workloads are deployed to declared namespaces (not default, openshift-*, istio-*)
• Workload namespaces have ResourceQuota applied
• All containers specify CPU and memory resource requests
• Services do not use NodePort

Certsuite Test Mapping

References

• Using RBAC Authorization
• Configure Service Accounts for Pods
• Resource Quotas
• Managing Resources for Containers
• Red Hat Best Practices for Kubernetes Guide
• Red Hat Best Practices Test Suite for Kubernetes (certsuite)