Gap Summary
Organization role assignments support three entity type references: APIs, Portals, and Control Planes. The existing org/teams/roles scenario tests the first two (APIs with literal wildcard entity_id: "*" and Portals with entity_id: !ref cross-resource reference), but never exercises Control Planes as an entity type. This leaves the control plane mapping in RoleEntityResourceType unverified end-to-end.
This matters because:
- Control planes are a primary Konnect resource, and role-based access to them is a core RBAC pattern.
- The
RoleEntityResourceType function in role_entity.go explicitly maps "controlplane" / "controlplanes" to ResourceTypeControlPlane, but this mapping is never exercised through a complete plan → apply → diff → verify cycle.
- A regression in control plane entity reference resolution (validation, planning, or execution) would go undetected by the current E2E suite.
- The system account and user role scenarios (
org/system-accounts/assignments, org/users/assignments) also only test APIs and Portals entity types, so adding control plane coverage for team roles would validate the shared ValidateRoleEntityReference and roleEntityDependency code paths for all three assignment types.
Evidence
- Code support:
internal/declarative/resources/role_entity.go:14-18 maps control plane entity type names to ResourceTypeControlPlane.
- Existing coverage:
test/e2e/scenarios/org/teams/roles/scenario.yaml step 001 tests entity_type_name: APIs, step 008 tests entity_type_name: Portals.
- Missing: No scenario in
test/e2e/scenarios/org/ uses entity_type_name: Control Planes or references a control plane in a role assignment.
- Shared validation:
ValidateRoleEntityReference in role_entity.go:53-87 handles all entity types uniformly — testing with control planes validates the full type mapping path.
Proposed Scenario Work
Expand the existing org/teams/roles scenario by adding a new overlay and step that parallels the portal entity ref pattern (step 008) but uses a control plane entity reference instead.
Add an overlay at test/e2e/scenarios/org/teams/roles/overlays/005-cp-entity-ref/config.yaml:
_defaults:
kongctl:
namespace: <cp-role-namespace>
control_planes:
- ref: <cp-ref>
name: <cp-name>
description: Control plane for team role entity ref E2E scenario
organization:
teams:
- ref: <cp-role-team-ref>
name: <cp-role-team-name>
description: Team for control plane role entity ref E2E
roles:
- ref: <cp-viewer-role-ref>
role_name: Viewer
entity_id: !ref <cp-ref>#id
entity_type_name: Control Planes
entity_region: us
Add a scenario step (e.g., step 009-plan-cp-entity-ref) that:
- Loads the overlay with a control plane and team with a role referencing it
- Runs
plan --mode apply
- Asserts the plan shows 3 CREATE changes (control plane, team, role)
- Asserts the role change has
fields.entity_id: "__REF__:<cp-ref>#id" and fields.entity_type_name: Control Planes
- Asserts the role
depends_on includes the control plane resource
Add corresponding vars to the scenario header for the control plane refs, names, and namespace.
Acceptance Criteria
Reference Patterns
test/e2e/scenarios/org/teams/roles/scenario.yaml step 008 (plan-portal-entity-ref) — demonstrates the exact same pattern for portal entity references, including the overlay structure and assertion style
test/e2e/scenarios/org/teams/roles/overlays/004-portal-entity-ref/config.yaml — template for the control plane overlay structure
Generated by E2E Coverage Scanner · opus46 · 320.6 AIC · ⌖ 30.7 AIC · ⊞ 6.7K · ◷
Gap Summary
Organization role assignments support three entity type references: APIs, Portals, and Control Planes. The existing
org/teams/rolesscenario tests the first two (APIs with literal wildcardentity_id: "*"and Portals withentity_id: !refcross-resource reference), but never exercises Control Planes as an entity type. This leaves the control plane mapping inRoleEntityResourceTypeunverified end-to-end.This matters because:
RoleEntityResourceTypefunction inrole_entity.goexplicitly maps"controlplane"/"controlplanes"toResourceTypeControlPlane, but this mapping is never exercised through a complete plan → apply → diff → verify cycle.org/system-accounts/assignments,org/users/assignments) also only test APIs and Portals entity types, so adding control plane coverage for team roles would validate the sharedValidateRoleEntityReferenceandroleEntityDependencycode paths for all three assignment types.Evidence
internal/declarative/resources/role_entity.go:14-18maps control plane entity type names toResourceTypeControlPlane.test/e2e/scenarios/org/teams/roles/scenario.yamlstep 001 testsentity_type_name: APIs, step 008 testsentity_type_name: Portals.test/e2e/scenarios/org/usesentity_type_name: Control Planesor references a control plane in a role assignment.ValidateRoleEntityReferenceinrole_entity.go:53-87handles all entity types uniformly — testing with control planes validates the full type mapping path.Proposed Scenario Work
Expand the existing
org/teams/rolesscenario by adding a new overlay and step that parallels the portal entity ref pattern (step 008) but uses a control plane entity reference instead.Add an overlay at
test/e2e/scenarios/org/teams/roles/overlays/005-cp-entity-ref/config.yaml:Add a scenario step (e.g., step
009-plan-cp-entity-ref) that:plan --mode applyfields.entity_id: "__REF__:<cp-ref>#id"andfields.entity_type_name: Control Planesdepends_onincludes the control plane resourceAdd corresponding vars to the scenario header for the control plane refs, names, and namespace.
Acceptance Criteria
entity_type_name: Control Planes!ref <cp-ref>#idasentity_idto test cross-resource reference resolutiondepends_onassertion confirms the role depends on the control plane resourceReference Patterns
test/e2e/scenarios/org/teams/roles/scenario.yamlstep 008 (plan-portal-entity-ref) — demonstrates the exact same pattern for portal entity references, including the overlay structure and assertion styletest/e2e/scenarios/org/teams/roles/overlays/004-portal-entity-ref/config.yaml— template for the control plane overlay structure