Child entities should inherit protection status from the parent entity

[Prashansa-K]

At the moment, protection status just applies to the parent entity that defines it.
We should extend this to the child entities as well.

Example with event gateways:

event_gateways:
  - ref: egw-cp-for-bc-test
    name: egw-cp-for-bc-test

    kongctl:
      protected: true # this protection label doesn't prevent a user from modifying/deleting the child resource

    backend_clusters:
      - ref: default-backend-cluster
        name: default-backend-cluster
        description: "First Backend Cluster for Test updated description"
        bootstrap_servers:
          - "egw-backend-1.example.com:9094"

If I apply the above config and later on add modifications to backend_clusters or delete them via a sync command, kongctl lets me do so. This is an undesired behaviour.

Same applies to all other entities.

Desired behaviour: A child entity should inherit the protected status of a parent.

[github-actions]

🎯 Agentic Issue Triage

Summary: Protection status (the KONGCTL-protected: "true" label) is currently enforced only on the specific resource where it is defined. When a parent entity is marked as protected, its child entities remain unprotected and can be freely updated or deleted, creating a protection bypass.

📋 Analysis

Issue Type

This is filed as a Bug — and rightly so. If a user marks a parent (e.g., an API) as protected: true, the intent is to guard it from accidental changes. But child entities (api_version, api_publication, api_implementation, api_document, portal pages, etc.) are checked independently and have no awareness of the parent's protection status.

How Protection Currently Works

Protection is stored as the Konnect label KONGCTL-protected: "true" on individual resources. It is enforced in two places:

1. Plan time — BasePlanner.ValidateProtection / ValidateProtectionWithChange in internal/declarative/planner/planner.go blocks ActionUpdate or ActionDelete for any resource carrying that label.
2. Execution time — internal/declarative/executor/base_executor.go re-checks the live resource for the protection label before committing updates or deletes.

Neither layer currently walks up the parent chain to check inherited protection.

Parent/Child Relationships in the Codebase

Child resources are resolved in two ways:

• Nested inline under the parent YAML block.
• Root-level with a parent reference (e.g., api: "my-api-ref").

The DependencyResolver (internal/declarative/dependencies.go) already has getParentType() logic mapping child → parent, and the ResourceSet has helpers like GetAPIVersionsByNamespace() that look up a parent's namespace. This infrastructure can be leveraged to resolve a parent resource and check its protection label.

🔧 Suggested Implementation Approach

1. internal/declarative/planner/planner.go — In ValidateProtection/ValidateProtectionWithChange, after checking the resource's own labels, also resolve the parent resource (via getParentType() + namespace lookup) and check its labels for KONGCTL-protected: "true". If the parent is protected, treat the child as protected too.

2. internal/declarative/executor/base_executor.go — Similarly, after fetching the live resource for an update or delete, check whether the parent resource (fetched from the API) carries the protection label.

3. Protection error messages — Update the error message to indicate why the child is blocked: e.g., "resource is protected via parent (parent-ref) and cannot be deleted".

4. _defaults interaction — Consider whether _defaults.kongctl.protected: true should already cover children in the same file (it currently doesn't because _defaults applies per-resource at load time, not hierarchically). This may be a separate follow-up.

5. Tests — Add unit tests in internal/declarative/planner/ and integration tests under test/integration/ for the new inherited-protection behavior.

✅ Sub-task Checklist

• Investigate all child resource types and their parent mappings in internal/declarative/dependencies.go
• Extend BasePlanner.ValidateProtection to resolve and check parent protection at plan time
• Extend executor update/delete paths to check parent protection at execution time
• Update protection error messages to surface parent-inherited blocks
• Add unit tests for planner with parent-protected children
• Add integration test scenario covering parent-protected + child operation
• Verify the _defaults file-level protection behavior is consistent (or document the gap)
• Update docs/examples/declarative/protected/ examples to demonstrate inherited protection

📚 Relevant Code Pointers

File	Relevance
internal/declarative/planner/planner.go	ValidateProtection, ValidateProtectionWithChange — main enforcement point
internal/declarative/executor/base_executor.go	Execution-time protection check for updates/deletes
internal/declarative/labels/labels.go	ProtectedKey, IsProtectedResource() helpers
internal/declarative/resources/types.go	KongctlMeta.Protected field definition
internal/declarative/dependencies.go	getParentType() — parent/child type mapping
internal/declarative/resources/resource_set.go	GetAPIVersionsByNamespace() — parent namespace resolution
docs/examples/declarative/protected/protected.yaml	Example showing current protection usage

Generated by Opened Issue Triage for issue #568 · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@69b5e3ae5fa7f35fa555b0a22aee14c36ab57ebb