Special handling for special Pod gets?

[luxas]

Category

Policy evaluation change, Cedarschema change

Describe the feature you'd like to request

It seems that resources that are "connected" to are in authorization considered to be a get or post, and thus do not use a dedicated "connect" action. This means that if we had a parent action "readonly" that is assigned to a user, it means they are able to exec into pods. Shall we deviate from upstream Kube here and special-case these actions using a dedicated connect action, to keep the semantics of get only to "read single API object".

Here is a list of similar subresources:

// plugin/pkg/auth/authorizer/rbac/bootstrappolicy/policy_test.go
// viewEscalatingNamespaceResources is the list of rules that would allow privilege escalation attacks based on
// ability to view (GET) them
var viewEscalatingNamespaceResources = []rbacv1.PolicyRule{
	rbacv1helpers.NewRule(bootstrappolicy.Read...).Groups("").Resources("pods/attach").RuleOrDie(),
	rbacv1helpers.NewRule(bootstrappolicy.Read...).Groups("").Resources("pods/proxy").RuleOrDie(),
	rbacv1helpers.NewRule(bootstrappolicy.Read...).Groups("").Resources("pods/exec").RuleOrDie(),
	rbacv1helpers.NewRule(bootstrappolicy.Read...).Groups("").Resources("pods/portforward").RuleOrDie(),
	rbacv1helpers.NewRule(bootstrappolicy.Read...).Groups("").Resources("secrets").RuleOrDie(),
	rbacv1helpers.NewRule(bootstrappolicy.Read...).Groups("").Resources("services/proxy").RuleOrDie(),
}

Describe alternatives you've considered

Additional context

No response

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change