Add CARING Kubernetes RBAC benchmark

infospace/standards/caring/benchmarks/kubernetes-rbac/README.md

@@ -0,0 +1,30 @@
+---
+id: benchmark/caring/kubernetes-rbac/readme
+title: CARING Kubernetes RBAC Benchmark Workspace
+status: candidate
+created_by_workplan: ITC-WP-0010
+---
+
+# CARING Kubernetes RBAC Benchmark
+
+This workspace analyzes Kubernetes RBAC as a CARING benchmark, not as a
+shortcut profile. It is designed to stress access-governance orthogonality
+across Access Control, Organization, Governance, Security, Landscape,
+DevSecOps, Network, Observability, Task, and Tagging.
+
+The benchmark keeps Kubernetes native constructs separate from CARING meaning:
+
+- `Role` and `ClusterRole` are rule bundles or capability profiles, not
+  automatically CARING canonical roles.
+- `RoleBinding` and `ClusterRoleBinding` are grants or assignments.
+- `ServiceAccount` is a service subject and a workload identity anchor.
+- `Namespace` is a useful scope signal, but it is not automatically a tenant
+  boundary.
+
+Indexed benchmark artifacts:
+
+- `benchmark.yaml`
+- `native-concepts.yaml`
+- `caring-mapping.yaml`
+- `access-descriptors.yaml`
+- `findings-and-canon-pressure.yaml`

infospace/standards/caring/benchmarks/kubernetes-rbac/access-descriptors.yaml

@@ -0,0 +1,164 @@
+id: benchmark/caring/kubernetes-rbac/access-descriptors
+title: Kubernetes RBAC CARING Access Descriptors
+status: candidate
+benchmark: benchmark/caring/kubernetes-rbac
+descriptor_classes:
+  - declared_access
+  - effective_access
+  - derived_capability
+  - induced_access
+descriptors:
+  - id: descriptor/namespace-pod-reader/declared
+    case_id: namespace-pod-reader
+    descriptor_class: declared_access
+    subject: serviceaccount:tenant-a:report-viewer
+    organization_relation: customer-operated-service
+    canonical_role: Viewer
+    scope: namespace:tenant-a
+    plane: Runtime
+    capabilities:
+      - get pods
+      - list pods
+      - watch pods
+    exposure_mode: metadata-and-runtime-state
+    lifecycle_state: steady-state-observation
+    conditions:
+      - bound by RoleBinding in namespace tenant-a
+    restrictions:
+      - no pod mutation
+      - no secret read
+      - namespace is not accepted as tenant boundary without additional evidence
+    native_evidence:
+      - Role/report-viewer
+      - RoleBinding/report-viewer-binding
+      - ServiceAccount/report-viewer
+  - id: descriptor/workload-creator/declared
+    case_id: workload-creator-derived-execution
+    descriptor_class: declared_access
+    subject: serviceaccount:tenant-a:job-runner
+    organization_relation: customer-operated-automation
+    canonical_role: Doer
+    scope: namespace:tenant-a
+    plane: Runtime
+    capabilities:
+      - create pods
+      - get pods
+      - delete pods
+    exposure_mode: workload-specification-control
+    lifecycle_state: job-execution
+    conditions:
+      - bound by RoleBinding in namespace tenant-a
+    restrictions:
+      - no direct secret get/list/watch declared
+    native_evidence:
+      - Role/job-runner
+      - RoleBinding/job-runner-binding
+      - ServiceAccount/job-runner
+  - id: descriptor/workload-creator/effective
+    case_id: workload-creator-derived-execution
+    descriptor_class: effective_access
+    subject: serviceaccount:tenant-a:job-runner
+    organization_relation: customer-operated-automation
+    canonical_role: Doer
+    scope: namespace:tenant-a
+    plane: Runtime
+    capabilities:
+      - create workload
+      - select pod service account
+      - influence mounted volumes
+      - execute container image
+    exposure_mode: mediated-runtime-execution
+    lifecycle_state: job-execution
+    conditions:
+      - pod admission and service-account mount behavior determine actual reach
+    restrictions:
+      - effective access must be checked against admission policy and service-account permissions
+    native_evidence:
+      - create pods verb
+      - pod spec serviceAccountName
+      - projected service account token behavior
+  - id: descriptor/workload-creator/derived
+    case_id: workload-creator-derived-execution
+    descriptor_class: derived_capability
+    subject: serviceaccount:tenant-a:job-runner
+    organization_relation: customer-operated-automation
+    canonical_role: Doer
+    scope: namespace:tenant-a
+    plane: Runtime
+    capabilities:
+      - execute arbitrary workload image
+      - use mounted service account identity
+      - read mounted runtime inputs
+    exposure_mode: derived-execution-and-identity-use
+    lifecycle_state: job-execution
+    conditions:
+      - derived from create pods permission
+    restrictions:
+      - must be bounded by admission controls, image policy, and service-account selection rules
+    native_evidence:
+      - Role/job-runner create pods
+  - id: descriptor/workload-creator/induced
+    case_id: workload-creator-derived-execution
+    descriptor_class: induced_access
+    subject: serviceaccount:tenant-a:job-runner
+    organization_relation: customer-operated-automation
+    canonical_role: Doer
+    scope: namespace:tenant-a
+    plane: Secret
+    capabilities:
+      - potential secret exposure through mounted volumes
+      - potential token exposure through mounted identity
+    exposure_mode: induced-secret-and-identity-exposure
+    lifecycle_state: job-execution
+    conditions:
+      - induced path exists only when workload can mount or reach sensitive material
+    restrictions:
+      - classify as candidate finding until manifests, admission, and secret references are reviewed
+    native_evidence:
+      - pod volume mounts
+      - service account token projection
+      - secret references in pod spec
+  - id: descriptor/cluster-secret-reader/declared
+    case_id: cluster-secret-reader
+    descriptor_class: declared_access
+    subject: serviceaccount:platform:inventory
+    organization_relation: platform-service-provider
+    canonical_role: Auditor
+    scope: cluster
+    plane: Secret
+    capabilities:
+      - get secrets
+      - list secrets
+      - watch secrets
+    exposure_mode: sensitive-data-read
+    lifecycle_state: operational-inventory
+    conditions:
+      - bound by ClusterRoleBinding
+    restrictions:
+      - requires governance review and audit evidence
+    native_evidence:
+      - ClusterRole/secret-reader
+      - ClusterRoleBinding/inventory-secret-reader
+      - ServiceAccount/inventory
+  - id: descriptor/namespace-boundary/review
+    case_id: namespace-as-tenant-boundary
+    descriptor_class: effective_access
+    subject: tenant-boundary-claim:tenant-a
+    organization_relation: platform-provider
+    canonical_role: Governor
+    scope: namespace:tenant-a
+    plane: Policy
+    capabilities:
+      - claim tenant isolation
+      - review access and runtime boundaries
+    exposure_mode: governance-claim
+    lifecycle_state: design-review
+    conditions:
+      - claim must be supported by access, network, runtime, data, and governance evidence
+    restrictions:
+      - namespace alone is insufficient evidence
+    native_evidence:
+      - Namespace/tenant-a
+      - RoleBinding set
+      - NetworkPolicy set
+      - ResourceQuota set

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.

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

@@ -0,0 +1,79 @@
+id: benchmark/caring/kubernetes-rbac/caring-mapping
+title: Kubernetes RBAC To CARING Mapping
+status: candidate
+benchmark: benchmark/caring/kubernetes-rbac
+namespace_tenant_boundary_warning: true
+mappings:
+  - native_concept: Role
+    caring_dimension: capability_profile
+    canon_targets:
+      - standard/caring:CARINGCapabilityProfile
+      - model/access-control:Permission
+      - model/governance:Policy
+    mapping_rule: Interpret Role rules as scoped capability bundles over verbs, resources, API groups, and resource names.
+  - native_concept: ClusterRole
+    caring_dimension: capability_profile
+    canon_targets:
+      - standard/caring:CARINGCapabilityProfile
+      - model/access-control:Permission
+      - model/governance:Policy
+    mapping_rule: Interpret ClusterRole rules as cluster-scope or reusable capability bundles; do not infer organization responsibility.
+  - native_concept: RoleBinding
+    caring_dimension: declared_access
+    canon_targets:
+      - standard/caring:CARINGDeclaredAccessMap
+      - model/access-control:Grant
+      - model/governance:Decision
+    mapping_rule: Bind subject to a Role or ClusterRole within the RoleBinding namespace.
+  - native_concept: ClusterRoleBinding
+    caring_dimension: declared_access
+    canon_targets:
+      - standard/caring:CARINGDeclaredAccessMap
+      - model/access-control:Grant
+      - model/governance:Decision
+    mapping_rule: Bind subject to a ClusterRole at cluster scope.
+  - native_concept: ServiceAccount
+    caring_dimension: subject
+    canon_targets:
+      - model/access-control:Subject
+      - model/devsecops:WorkloadIdentity
+      - model/organization:Service
+    mapping_rule: Treat ServiceAccount as a service subject; map workload use separately as effective or induced access.
+  - native_concept: Namespace
+    caring_dimension: scope
+    canon_targets:
+      - model/access-control:ResourceScope
+      - model/landscape:RuntimeContainment
+      - model/network:SegmentationContext
+    mapping_rule: Use Namespace as a Kubernetes scope signal; require additional evidence before mapping it to TenantBoundary.
+  - native_concept: Verb
+    caring_dimension: capability
+    canon_targets:
+      - model/access-control:Action
+      - standard/caring:CARINGCapabilityProfile
+    mapping_rule: Interpret verbs in combination with resources because create pods and get secrets have different exposure consequences.
+  - native_concept: Resource
+    caring_dimension: scope
+    canon_targets:
+      - model/access-control:Resource
+      - model/landscape:RuntimeResource
+      - model/security:ExposureTarget
+    mapping_rule: Map resources to access targets and then evaluate exposure, derived capability, and plane.
+  - native_concept: Scope
+    caring_dimension: scope
+    canon_targets:
+      - model/access-control:ResourceScope
+      - model/landscape:LandscapeScope
+      - model/governance:GovernanceScope
+    mapping_rule: Preserve namespace, cluster, API group, resource, and resourceName boundaries as separate scope facets.
+analysis_rules:
+  - id: native-role-warning
+    rule: Do not map Role or ClusterRole to CARINGCanonicalRole without an explicit lifecycle-responsibility rationale.
+  - id: declared-to-effective
+    rule: Translate bindings into declared access first, then test workload, controller, service-account, secret, and volume paths for effective access.
+  - id: derived-workload-execution
+    rule: Permissions that create or update workload specs may imply derived execution and mounted identity capabilities.
+  - id: secret-exposure
+    rule: Permissions over secrets, pods, serviceaccounts, roles, rolebindings, or escalation verbs require security and governance review.
+  - id: namespace-tenant-boundary
+    rule: Namespace isolation claims require evidence from access control, runtime configuration, network policy, data isolation, and governance ownership.

infospace/standards/caring/benchmarks/kubernetes-rbac/findings-and-canon-pressure.yaml

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

infospace/standards/caring/benchmarks/kubernetes-rbac/native-concepts.yaml

@@ -0,0 +1,87 @@
+id: benchmark/caring/kubernetes-rbac/native-concepts
+title: Kubernetes RBAC Native Concept Map
+status: candidate
+benchmark: benchmark/caring/kubernetes-rbac
+namespace_tenant_boundary_warning: true
+concepts:
+  - native: Role
+    category: rule-bundle
+    native_scope: namespace
+    caring_mapping: CARINGCapabilityProfile
+    canon_mappings:
+      - model/access-control:PermissionSet
+      - model/governance:Policy
+    notes: A Role defines permissions within one namespace and is not automatically a CARINGCanonicalRole.
+  - native: ClusterRole
+    category: rule-bundle
+    native_scope: cluster
+    caring_mapping: CARINGCapabilityProfile
+    canon_mappings:
+      - model/access-control:PermissionSet
+      - model/governance:Policy
+    notes: A ClusterRole can define cluster-scoped permissions or reusable rule bundles for namespace bindings.
+  - native: RoleBinding
+    category: assignment
+    native_scope: namespace
+    caring_mapping: CARINGDeclaredAccessMap
+    canon_mappings:
+      - model/access-control:Grant
+      - model/governance:AssignmentDecision
+    notes: A RoleBinding grants a Role or ClusterRole to subjects within a namespace.
+  - native: ClusterRoleBinding
+    category: assignment
+    native_scope: cluster
+    caring_mapping: CARINGDeclaredAccessMap
+    canon_mappings:
+      - model/access-control:Grant
+      - model/governance:AssignmentDecision
+    notes: A ClusterRoleBinding grants a ClusterRole across cluster scope.
+  - native: ServiceAccount
+    category: service-subject
+    native_scope: namespace
+    caring_mapping: Subject
+    canon_mappings:
+      - model/access-control:Subject
+      - model/organization:Service
+      - model/devsecops:WorkloadIdentity
+    notes: A ServiceAccount is a service subject and workload identity anchor, not a human actor.
+  - native: Namespace
+    category: scope-signal
+    native_scope: namespace
+    caring_mapping: Scope
+    canon_mappings:
+      - model/landscape:RuntimeContainment
+      - model/access-control:ResourceScope
+      - model/network:SegmentationContext
+    notes: A Namespace is not automatically a tenant boundary; tenant isolation needs supporting access, network, data, and governance evidence.
+  - native: Verb
+    category: action
+    native_scope: rule
+    caring_mapping: Capability
+    canon_mappings:
+      - model/access-control:Action
+      - standard/caring:CARINGCapabilityProfile
+    notes: Verbs such as get, list, watch, create, update, patch, delete, bind, impersonate, and escalate must be interpreted by resource and scope.
+  - native: Resource
+    category: target
+    native_scope: api-group
+    caring_mapping: Scope
+    canon_mappings:
+      - model/access-control:Resource
+      - model/landscape:RuntimeResource
+      - model/data:ProtectedInformationAsset
+    notes: Resources such as pods, secrets, roles, rolebindings, and serviceaccounts carry different exposure and derived-capability implications.
+  - native: Scope
+    category: boundary
+    native_scope: namespace-or-cluster
+    caring_mapping: Scope
+    canon_mappings:
+      - model/access-control:ResourceScope
+      - model/landscape:LandscapeScope
+      - model/governance:GovernanceScope
+    notes: Kubernetes scope must be declared explicitly as namespace, cluster, API group, resource, and optionally tenant claim with evidence.
+mapping_constraints:
+  - Kubernetes native names are preserved as source semantics.
+  - CARING canonical roles are assigned only after analyzing lifecycle responsibility posture.
+  - Namespace tenancy is a reviewable claim, not a default mapping.
+  - Effective access must include controller-mediated and workload-mediated paths where relevant.