Explore a proper permission strategy for deployers and applyset to manage resources

[matthiasbruns]

Description

In #624 we applied the k8s ApplySet for deployers. While implementing this, we found out that our current permission concept for the deployer does not work anymore for the ApplySet, since the deployer needs to be able to get/list/delete resources in the cluster.

For reference, the actual lookup the actual implementation in https://github.com/open-component-model/open-component-model/pull/1335/changes#diff-471c0beaf0cee38ed3a51901a53c633cb94d0fcb2230955143463f36aaa65bfdR584

This issue is about discussing which way we want to go with the permission concept.

1. Give wildcard access to all possible resources which can be deployed by the deployer beforehand (simplest, least security)
2. Let the user provide a cluster-role / role with permissions he decides on to (least work for us, harder to integrate for the user, error-prone)
3. Dynamically create roles based on the resources to be generated by the deployer (hardest to implement, good middleground, easier for the user)

Permission Concept Comparison

Aspect	1. Wildcard Access	2. User-Provided Role	3. Dynamic Role Creation
Security	⚠️ Low - broad permissions	✅ High - user controls exact permissions	✅ High - minimal permissions based on actual resources
Implementation Complexity	✅ Simple - single RBAC manifest	✅ Simple - use existing role	⚠️ Complex - requires dynamic role management
User Experience	✅ Easy - works out of the box	⚠️ Moderate - requires RBAC knowledge	✅ Easy - automatic permission setup
Maintenance	✅ Low - one-time setup	❌ High - users must update as resources change	⚠️ Moderate - controller maintains roles
Error Handling	✅ No permission errors	❌ Frequent errors if misconfigured	⚠️ Potential edge cases during role creation
Audit Trail	❌ Difficult - too broad to audit	✅ Clear - explicit user-defined permissions	✅ Clear - roles match deployed resources
Compliance	❌ May violate least-privilege	✅ Aligns with organizational policies	✅ Aligns with least-privilege principle
Multi-Tenancy	⚠️ Risky - may allow cross-namespace access	✅ Good - user can scope appropriately	✅ Good - scoped to specific resources
Best For	Dev/test environments	Highly regulated environments	Production environments with ease of use

Done Criteria

• Explored all three options
• Document your findings in this ticket
• Decide on one option to implement (in the team)
• Update the follow up issue about the implementation task Implement Permission Strategy for Deployers with ApplySet #821

[jakobmoellerdev]

Dynamic Role Creation => you cannot dynamically create arbitrary roles without having wildcard access. thus this is moot. (to create RBAC you need to have RBAC :D )

so imho, we have to decide between wildcard or non-wildcard.

[fabianburth]

we will discuss it in the war room