Proposal: Per-resource Service Accounts

[imjasonh]

Today, to authorize interactions with PipelineResources (e.g., fetch source, push image, deploy to cluster), a TaskRun specifies a Service Account, which is expected to have an annotated Secret with credentials to interact with all the external services needed by the TaskRun.

These credentials are pulled from the Secret and passed to creds-init before the steps run, to populate .gitconfigs, ~/.docker/config.jsons, SSH keys, etc. (full docs)

The result is that a TaskRun has a single Service Account, with permission to do all the things the TaskRun needs to do, and all of that Service Account's properly-annotated Secrets are made available to all of the run's steps and resources.

This can be confusing in cases where there are many resources involved that require credentials. There might be multiple resources of the same time (git, image, cluster) that might be able to be authorized by multiple available credentials, and removing one might have unintended consequences if they were unexpectedy load-bearing. A TaskRun might want to fetch source before running steps using a read-only auth token, then do some work, then push to the repo afterwards using a different read-write token. Or a Service Account might be used for many TaskRuns, and have all the credentials needed for all of the Tasks it can possibly run mounted into every TaskRun.

Proposal

Optionally allow PipelineResource definitions to specify a Service Account (or just a Secret? Or multiple Secrets?) to use to interact with that resource, which would populate credentials in the expected place(s) only for the duration of that interaction. After the resource interaction is done, the TaskRun's otherwise configured Service Account would take over to perform the rest of the steps and interact with resources.

(The per-resource credentials are instead of the TaskRun's credentials, not in addition to)

PipelineResource implementations should not have to be aware of credentials, just as they aren't today -- they should be able to assume the presence of required credentials, and it should be the responsibility of the controller to run creds-init correctly before the resource's containers run to make sure the expected credentials are present, and that they're not present when they aren't requested.

Considerations

This opens a possible door to having per-step Service Accounts, or per-step Secrets, which would similarly populate credentials only for the duration of that step, then revert to fallback credentials for the rest of the run. This feels like overkill to me, and would need to be justified by sufficient user feedback.

[vtereso]

This opens a possible door to having per-step Service Accounts

I assume this means outside of PipelineResources since the steps internal to them are blackboxed? In any case, I agree that per step seems overkill since you could just make smaller Task definitions, which could probably achieve a similar result.

[imjasonh]

Yeah, I envisioned someone wanting to run the main steps of a Task with credsA applied to the first set of steps and credsB applied to the rest of the steps, but this seems like a real antipattern that would likely only cause more confusion.

[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]

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]

@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.

[vdemeester]

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

[tekton-robot]

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

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.

[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.

[vdemeester]

/remove-lifecycle stale
/cc @sbwsg

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

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

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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 with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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.

[james-callahan]

Is there some way to create a per-pipelinerun service account?
I'd like to use it to make sure pipelines that happen to run at the same time can't interfere with each others resources