Restrict creation of Resources to just Pipeline Resources? about triggers HOT 10 CLOSED

I've added this to the 0.1 milestone cuz I think we should answer this before 0.1 - and maybe the answer is to leave it as is!

from triggers.

Sorry, I'm a little late adding my opinion to this issue.

One benefit I see of not restricting TriggerTemplates to only Tekton resources, is that it decouples the Triggers project from the Pipelines project. So, if Pipelines creates new resources, or modifies its resources (which will happen in the future since it's still in alpha), the Triggers project might become broken from these changes, and/or Triggers might need to be updated to support these changes. I think the benefits of keeping the Triggers project decoupled or loosely coupled to the Pipelines project might outweigh the costs stated above.

from triggers.

@dibyom The root README specifies:

This repo draws inspiration from Tekton, but can used stand alone since TriggerTemplates can create any Kubernetes resource.

Implementation specifics or otherwise, seems good to update this and potentially add some info other places.

from triggers.

I believe we already have the full scope since that is how it is implemented as per c9537c0. If we wanted to restrict this to core tekton objects for the initial release, we could do so at the apiGroup/resource level. However, if such a restriction were added, we would still need some other abstraction to validate at the resource templates before event time since their structure is not known.

from triggers.

From the WG discussion, we seem to be aligned that restricting resource creation to the tekton.dev apigroup makes sense for a first release. TBD on implementation. Should we add a ConfigMap whitelisting the permissible apigroups for creation? Use environment variables?

from triggers.

I think a ConfigMap makes sense! I'll take a stab at this

/assign

from triggers.

Leaving this open until the follow up PR is in with the ConfigMap implementation, which should also update the documentation.

from triggers.

I'll update the docs and then close this issue and open a new one for the ConfigMap implementation.

from triggers.

Gulp -- I'd like to be able to create Secrets too. e.g. the event contains information that I use to create a Secret needed later in my pipeline.

from triggers.

So, chatted with @vtereso and here is what we are thinking:

• We'll keep the static restriction for 0.1

• In the future we'll add two checks:

1. does the EventListener ServiceAccount have access to the Resources in the template?

2. does the user creating the EventListener have access to the Resources in the template as well as the EventListener ServiceAccount?

Once we have these two checks we'll deprecate the static whitelist of allowed types.

from triggers.