triggers: Users should only be able to create TriggerTemplates for resources they are permissioned to use

In the current design, users would be able to use the spec.resourceTemplates field to escalate their degree of write permission within the cluster; users of TriggerTemplate are able to create any resource that the service account responsible for creating resources in a TriggerTemplate has permission to create. For example, if a user does not have access to create Pods, but the service account servicing TriggerTemplate does, a user could put a Pod into spec.resourceTemplates and have it created.

We should protect against this form of privilege escalation by having a validating webhook that uses information from the authorizer (this is part of the payload webhooks are passed) to make SAR checks that establish that the user creating or updating a TriggerTemplate has permission to create those resources in the cluster.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 2
Comments: 33 (15 by maintainers)

Most upvoted comments

@dibyom @khrm - to help illustrate my point about the optional nature of the EVT sa ref field and multi-tenant event listeners, I’ve opened an experimental PR #836 to explain where things need to go, and we sufficiently close the gaps originally noted by this issue.

UPDATE: we had a centralized discussion on this in today’s WG call today … the skinny:

per @dibyom the pluggable interceptor rework should reduced the permission scope of the EventListener
EL permissions in general are on @khrm 's radar wrt multi-tenant EL
we also discussed a few tweaks to the first pass approach I did in https://github.com/tektoncd/triggers/pull/836
But in general, we’ll revisit once the interceptor rework is done, and there is something more tangible wrt multi-tenant WL to examine

@dibyom @khrm please comment as needed if my summary missed something

gabemontero on Dec 2, 2020

After investigating and thinking about this a bit more, I think the TL;DR is:

afaik @pmorie is pointing out that in our current design, if a user can create an EventListener (with a serviceaccount that can make PipelineRuns, read TriggerBindings, etc.), and you can create Pipelines + Tasks, they’ll then have additionally the ability to:

Create Resources like PipelineRuns
Creating a PipelineRun means you can create a pod
Being able to create a pod means you can basically do anything you want within a cluster, and access any existing service accounts w/in the cluster

So basically for example you might intend for a user to only be able to run Pipeline Foo in a cluster in response to a webhook, but you may not realize you actually gave the user the ability to do nearly anything they want in the cluster.

I’m not sure triggers or pipelines should solve this directly, but we might want to provide some guidance (and maybe even best practice setup Tasks like the one @akihikokuroda added!) for ppl to setup secure clusters, e.g. something like:

Restrict who can create Pipelines and Tasks <-- maybe this solves like 90% of the problem?
Use SubjectAccessReview to express stuff like: in order for a user to be allowed to make an EventListener, they must also be allowed to create a PipelineRun (and if you want to create a PipelineRun, you need to be allowed to create a pod)
Use something like gatekeeper to express more complex stuff, e.g. serviceaccount blah can only be referenced in pods that are created by user baz

bobcatfish on Sep 5, 2019