generated from coulomb/repo-seed
77 lines
4.8 KiB
YAML
77 lines
4.8 KiB
YAML
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.
|