id: benchmark/caring/kubernetes-rbac/findings
title: Kubernetes RBAC Benchmark Findings And Canon Pressure
status: candidate
benchmark: benchmark/caring/kubernetes-rbac
stable_findings:
  - id: finding/native-role-is-rule-bundle
    severity: high
    summary: Kubernetes Role and ClusterRole are native rule bundles, not automatically CARING canonical roles.
    canon_pressure:
      - Keep the native role warning visible in CARING validation.
      - Add benchmark assertions that reject direct Role to CARINGCanonicalRole mappings without rationale.
  - id: finding/namespace-not-tenant-boundary
    severity: high
    summary: Namespace is a useful scope signal but does not by itself prove tenant isolation.
    canon_pressure:
      - Treat tenant-boundary claims as reviewable evidence bundles across access, network, data, runtime, and governance.
      - Add a reusable tenant-boundary review pattern if this recurs in other benchmarks.
  - id: finding/workload-create-derives-execution
    severity: high
    summary: Workload creation permissions can derive runtime execution, mounted identity use, volume access, and secret exposure paths.
    canon_pressure:
      - Clarify ownership of DerivedCapability between CARING, Access Control, Security, and DevSecOps.
      - Add effective-access checks for workload-mediated permission paths.
  - id: finding/serviceaccount-is-service-subject
    severity: medium
    summary: ServiceAccount should map to a service subject and workload identity, not to a human actor or organization role.
    canon_pressure:
      - Strengthen subject and principal distinctions in access reviews.
      - Preserve actor, subject, principal, and workload identity as separate concepts.
gaps:
  - id: gap/caring-access-descriptor-schema
    title: Machine-readable CARING descriptor schema
    description: The benchmark uses structured descriptors, but there is not yet a formal schema for CARINGAccessDescriptor.
    proposed_route: Create schema under a future CARING validation workplan.
  - id: gap/effective-access-calculus
    title: Effective access derivation rules
    description: The canon needs reusable derivation rules for workload creation, mounted identities, secrets, impersonation, bind, and escalate.
    proposed_route: Add validation rules after more benchmark cases are exercised.
  - id: gap/tenant-boundary-evidence-profile
    title: Tenant boundary evidence profile
    description: Namespace boundary claims need a reusable evidence profile spanning access, network, runtime, data, and governance controls.
    proposed_route: Candidate pattern or profile, not an immediate standard change.
conflicts:
  - id: conflict/native-role-name
    summary: Kubernetes native Role conflicts with the everyday meaning of role and with CARINGCanonicalRole.
    resolution: Preserve native construct name and require explicit mapping to capability profile or canonical role.
  - id: conflict/scope-overload
    summary: Kubernetes namespace, resource scope, governance scope, tenant scope, and CARING scope can be conflated.
    resolution: Record scope facets separately and only approve tenant-boundary claims after evidence review.
proposed_changes:
  - id: proposal/caring-descriptor-schema
    owner: standard/caring
    change_type: new-schema
    proposal: Add a CARING access descriptor schema with required fields for subject, organization relation, canonical role, scope, plane, capabilities, exposure mode, lifecycle state, restrictions, descriptor class, and native evidence.
  - id: proposal/kubernetes-rbac-validation-rules
    owner: standard/caring
    change_type: benchmark-validation
    proposal: Add CARING validation rules for native role warning, namespace tenant-boundary claims, workload-derived execution, and secret exposure.
  - id: proposal/tenant-boundary-review-pattern
    owner: model/governance
    change_type: new-pattern
    proposal: Add a review pattern for tenant-boundary claims that requires evidence from access control, network, runtime, data, security, and governance.
  - id: proposal/derived-capability-ownership
    owner: standard/caring
    change_type: open-question
    proposal: Decide whether DerivedCapability remains CARING-owned or becomes shared with Access Control and Security through a model profile.
follow_up_tasks:
  - id: task/formalize-caring-descriptor-schema
    target_workplan: proposed
    summary: Create the CARING access descriptor schema and validate this benchmark against it.
  - id: task/add-kubernetes-rbac-case-corpus
    target_workplan: proposed
    summary: Add concrete Kubernetes YAML manifests for the four benchmark cases and expected parsed observations.
  - id: task/expand-effective-access-engine
    target_workplan: proposed
    summary: Prototype derivation rules for pod creation, service-account mounting, secrets, bind, escalate, and impersonate.