Add CARING Kubernetes RBAC benchmark

infospace/standards/caring/benchmarks/kubernetes-rbac/benchmark.yaml

@@ -0,0 +1,102 @@
+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.