Kubernetes RBAC configured with minimal permissions; no wildcard verbs or cluster-admin

Wildcard verbs (verbs: ['*']) or cluster-admin bindings grant a service account the ability to read secrets, delete deployments, modify RBAC rules, or escalate its own privileges — effectively root access on the cluster (CWE-284, OWASP A01). NIST 800-53 AC-6 requires least-privilege access control. CIS Kubernetes 5.1.1 explicitly prohibits wildcard verbs and cluster-admin bindings for workload service accounts. A compromised pod with cluster-admin can exfiltrate every secret in the cluster within seconds.

Audit existing RBAC with kubectl get clusterrolebindings,rolebindings -A -o yaml | grep -A5 cluster-admin and replace over-permissive roles with narrow, explicit ones. Replace wildcard roles in k8s/rbac.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: api-role
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["db-credentials"]
    verbs: ["get"]

For every service account, ask: what specific API calls does this workload make? Grant only those verb-resource pairs. Use kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa> to audit effective permissions.

• ID: infrastructure-hardening.access-control-rbac.rbac-minimal

• Severity: high

• What to look for: Enumerate every Role, ClusterRole, RoleBinding, and ClusterRoleBinding manifest. For each Role/ClusterRole, list all verb and resource combinations. Count how many roles use wildcard verbs (*) or wildcard resources (*). Count how many service accounts are bound to cluster-admin.

• Pass criteria: 100% of RBAC Roles and ClusterRoles specify explicit verbs and explicit resource names with 0 wildcard verbs (*) and 0 wildcard resources. No service account is bound to the cluster-admin ClusterRole. Each service account has no more than 5 verb-resource combinations. Report: "X Roles and Y ClusterRoles reviewed, 0 wildcards, 0 cluster-admin bindings."

• Fail criteria: Any Role or ClusterRole uses wildcard verbs (verbs: ['*']), grants wildcard resources, or a service account is bound to cluster-admin ClusterRole.

• Skip (N/A) when: The project does not use Kubernetes or RBAC is not applicable.

• Detail on fail: Quote the offending Role. Example: "Service account 'app-sa' is bound to ClusterRole 'cluster-admin'" or "Role 'app-role' grants verbs: ['*'] on resources: ['*'] — overly permissive"

• Remediation: Define roles with only required verbs and resources:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    name: app-role
  rules:
    - apiGroups: [""]
      resources: ["configmaps"]
      verbs: ["get", "list"]
    - apiGroups: [""]
      resources: ["secrets"]
      resourceNames: ["app-secret"]
      verbs: ["get"]
    - apiGroups: ["batch"]
      resources: ["jobs"]
      verbs: ["create", "get"]
  
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: app-binding
  subjects:
    - kind: ServiceAccount
      name: app-sa
      namespace: default
  roleRef:
    kind: Role
    name: app-role
    apiGroup: rbac.authorization.k8s.io
  

  Never bind a service account to cluster-admin for production workloads.