id: benchmark/caring/kubernetes-rbac
title: CARING Kubernetes RBAC Benchmark
status: candidate
standard: standard/caring
created_by_workplan: ITC-WP-0010
purpose: Stress-test CARING descriptor shape against Kubernetes RBAC without treating Kubernetes native names as canon roles.
source_corpus:
  - id: kubernetes-rbac-reference
    title: Kubernetes RBAC Reference
    source_type: vendor-documentation
    url: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
    role: primary-native-model-reference
  - id: kubernetes-service-account-concepts
    title: Kubernetes Service Accounts
    source_type: vendor-documentation
    url: https://kubernetes.io/docs/concepts/security/service-accounts/
    role: workload-identity-reference
  - id: local-caring-standard
    title: InfoTechCanon CARING Access Governance Standard
    source_type: canon-standard
    path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
    role: descriptor-vocabulary
cases:
  - id: namespace-pod-reader
    title: Namespace-Scoped Pod Reader
    native_objects:
      - Role
      - RoleBinding
      - ServiceAccount
      - Namespace
    stress_focus:
      - declared-access
      - scope-mapping
      - native-role-warning
    expected_outputs:
      - Role maps to a scoped capability profile over get/list/watch pods.
      - RoleBinding maps to a grant from subject to capability profile.
      - Namespace is recorded as Kubernetes scope, not tenant boundary.
  - id: workload-creator-derived-execution
    title: Workload Creator With Derived Execution Capability
    native_objects:
      - Role
      - RoleBinding
      - ServiceAccount
      - Pod
      - Secret
    stress_focus:
      - declared-access
      - effective-access
      - derived-capability
      - induced-access
    expected_outputs:
      - Create pod is declared as workload creation access.
      - Execute workload is derived from the ability to create pods.
      - Mounted service-account and secret exposure are induced access candidates.
  - id: cluster-secret-reader
    title: ClusterRole Secret Reader
    native_objects:
      - ClusterRole
      - ClusterRoleBinding
      - ServiceAccount
      - Secret
    stress_focus:
      - cluster-scope
      - exposure-mode
      - governance-review
    expected_outputs:
      - ClusterRole maps to cluster-scoped data exposure capability.
      - ClusterRoleBinding broadens scope beyond a namespace.
      - Secret read access produces security and governance findings.
  - id: namespace-as-tenant-boundary
    title: Namespace Used As Tenant Boundary Claim
    native_objects:
      - Namespace
      - Role
      - RoleBinding
      - NetworkPolicy
      - ResourceQuota
    stress_focus:
      - tenant-boundary-warning
      - cross-model-evidence
      - review-criteria
    expected_outputs:
      - Namespace alone cannot prove tenant isolation.
      - Tenant-boundary claim requires access, network, data, runtime, and governance evidence.
      - Missing evidence creates a canon pressure finding instead of an approved boundary claim.
expected_outputs:
  - Native concept map covering Role, ClusterRole, RoleBinding, ClusterRoleBinding, ServiceAccount, Namespace, verbs, resources, and scopes.
  - CARING mapping that separates native role objects from canonical roles, capability profiles, grants, scopes, planes, and exposure modes.
  - Access descriptors that distinguish declared access, effective access, derived capability, and induced access.
  - Findings that identify gaps, conflicts, and proposed canon changes without changing standards silently.
review_criteria:
  - id: descriptor-completeness
    criterion: Every benchmark case has at least one CARING access descriptor with subject, scope, plane, capabilities, exposure mode, lifecycle state, and native evidence.
  - id: native-role-warning
    criterion: Kubernetes Role and ClusterRole are never accepted as CARINGCanonicalRole without an explicit mapping rationale.
  - id: namespace-boundary-check
    criterion: Namespace isolation is treated as a claim requiring evidence, not as a tenant boundary by default.
  - id: effective-access-analysis
    criterion: Create or update workload permissions are reviewed for derived execution, mounted identity, secret, and volume exposure.
  - id: canon-pressure-routing
    criterion: Gaps become reviewable proposed changes, tasks, or open questions rather than immediate model changes.