Pipeline Runs fails on Tekton if “Multiple Users” creats git/docker secrets in same domain & namespace.

[AvinashSingh299]

Expected Behavior

“Multiple Users” with git/docker secrets in same domain(https://github.com or https://github.ibm.com or https://hub.docker.com/,…etc) & same namespace should be able to trigger Pipeline-runs successfully from Tekton UI.

Actual Behavior

Pipeline Runs fails on Tekton if “Multiple Users” creating git/docker secrets in same domain & namespace.

Steps to Reproduce the Problem

CP4A 3.X, IBM Cloud (Not Tested on Latest CP4A versions)

1. Install Cp4A
2. Create github secrets for User-A in domain https://github.com . Create a web-hook & initial a pipeline runs. It will work.
3. Now create github secrets for User-B in domain https://github.com in same namespace .
4. Try to trigger a build for User-A or User-B, it will fail.

Additional Info

I worked with Developers from Tekton & they proceeded below work-Around:

1. setup a functional/build ID in GitHub that added to all repos as an owner. The secret for this build ID is added to Tekton. Then setup a common/team Docker hub and add the secret for it to Tekton.

2. setup service accounts for each user/developer in OCP, copying the RBAC settings for the kabanero-operator to each new users service account and then selecting that users service account in Tekton when adding the user/developers secrets.

But Above steps are never test & even customer failing to implement it. 

Please either provide detailed steps/document for above or implement fix via code changes.

[a-roberts]

Yeah I see what you're saying, there's no concept of users for the webhooks extension, only ServiceAccounts with PipelineRuns and Tekton annotated secrets, so indeed as you noticed in the additional information, you can get around this but it's not ideal.

I'm wondering what the best strategic approach is here, you can't fiddle with the server URL so indeed you have to get around it with different ServiceAccounts. That process should be at least well defined and documented short of a solution being implemented here.

@dibbles a penny for your thoughts too?

[dibbles]

Currently options are (I believe) different service accounts for different users or an automation id that can access all repos. It is no so much a problem with the webhooks extension but a problem with base tekton pipelines and so the root issue would need addressing there.

All that said.... in tekton pipelines there has been much talk about getting rid of pipelineresources. PipelineResources being used by many people as inputs on tasks to automate the extraction of the code from the git repo.

In place of using pipelineresources I think the proposal is to use a task (backed by an image which contains the git cmd) - see https://github.com/tektoncd/catalog/tree/v1beta1/git (although this is for the beta levels of tekton).

Whilst there is no mention of authorization used (presumably it still relies on the creds-init phase of the main codebase), could it not in theory be possible to have a task like this to which is some how able to make use of an inputted secret for the credentials (and override anything from creds init) - I'm just guessing at this point in time as it is not something I have tried to solve?

The root issue otherwise would remain with how tektoncd/pipelines does credential management/initialization - unless that has at all changed recently.

[a-roberts]

Currently options are (I believe) different service accounts for different users or an automation id that can access all repos. It is no so much a problem with the webhooks extension but a problem with base tekton pipelines and so the root issue would need addressing there.

All that said.... in tekton pipelines there has been much talk about getting rid of pipelineresources. PipelineResources being used by many people as inputs on tasks to automate the extraction of the code from the git repo.

In place of using pipelineresources I think the proposal is to use a task (backed by an image which contains the git cmd) - see https://github.com/tektoncd/catalog/tree/v1beta1/git (although this is for the beta levels of tekton).

Whilst there is no mention of authorization used (presumably it still relies on the creds-init phase of the main codebase), could it not in theory be possible to have a task like this to which is some how able to make use of an inputted secret for the credentials (and override anything from creds init) - I'm just guessing at this point in time as it is not something I have tried to solve?

The root issue otherwise would remain with how tektoncd/pipelines does credential management/initialization - unless that has at all changed recently.

Regarding credentials I think it's worth highlighting tektoncd/pipeline#2343 which @sbwsg referenced in a recent working group call, in the short-term I'm with Duane in that many ServiceAccounts representing users and/or an automation iD is going to be the way to go for now.

Whilst there is no mention of authorization used (presumably it still relies on the creds-init phase of the main codebase), could it not in theory be possible to have a task like this to which is some how able to make use of an inputted secret for the credentials (and override anything from creds init) - I'm just guessing at this point in time as it is not something I have tried to solve?

I think this is worth running with as well, let us know what you think @AvinashSingh299

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.