-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TaskRef: refer to a Task from another namespace #1409
Comments
/assign |
…skRun spec Sometimes users don't want to copy-paste Task from one namespace to other. One such use case could be enabling Task from Task catalog. Every time duplicating the same Task in more than one namespace could become maintenance nightmare. This patch allows referencing a Task from a different namespace in TaskRun's and PipelineRun's spec.TaskRef`. Hence this would allow the user to install the Task once in the namespace. (Now not sure about its overlap with ClusterTask) Fixes tektoncd#1409
Should we allow this for Pipelines/Conditions as well? Related: we have a feature request for Cluster scoped Conditions and Pipelines: #1266 |
@dibyom right, this is something we need to discuss then. My gut feeling is yes, but maybe this means we don't need |
One concern I have with this is that at least currently the Tekton Controller is doing the taskref lookup with elevated privilege. This might be a real problem in a multi-tenant environment where we want to prevent lookup of private Tasks that might inadvertently contain secret-ish materials. |
I'm concerned about the statement in the proposal:
I don't think it's clear what would happen later on if the permissions changed. If any garbage collection scenarios would be changed with this (I don't believe owner references work across namespaces). Or what it would mean to have an instance of this Also, I think there are side-channel attacks that open up if you start referencing things across namespaces. Unless you're very careful about error messages, you could probe for Tasks in other spaces by submitting pipelines and looking at the results. |
We need to consider the overlap with Yes as @skaegi mentioned on other hand we need to handle the permission or authorization issue. |
That's a very good point that I didn't take into account initially 😅 |
One way to address the permission issue by either placing the authorization checks in the tekton pipeline webhook based on the user's token/ |
FWIW I'm neutral to -1 on this, but our use case (this was echoed by @rakhbari on the WG call) is that we use namespaces as a mechanism for isolation and some security guarantees, so if it were implemented we couldn't use it. |
Slight preference for design 2: - name: task-a
taskRef:
name: foo
namespace: another-namespace Re. service account issues - could we initially assume the controller service account has the permissions it needs, and ask users to add more permissions to that account if needed? |
The problem is opposite, if the user has less permission than the controller (which might easily be the case), then we are in a situation of privileged escalation (kinda). |
I'm curious, can you not get the same/similar result by using a The nice thing about using a |
Ah interesting!! Is this already the case then, even with Tasks in the same namespace? Like a user only needs to be able to create a (In some ways this reminds me of tektoncd/triggers#77) |
@bobcatfish yeah that's the case already 👼 You can refer a Task in the same namespace even if you don't have the right to get/list/update/… Tasks 👼 |
Continuing discussion on #1420 (comment)
But a namespaced task or a cluster-task does not solve this issue that the task definition can change and the next pipeline-run can fail. So what is the recommended approach if a task definition need to be shared amongst only few namespaces/projects but not all? |
@sthaha IMHO we're getting into the area of artifact versioning and that's already covered by your SCM tool, in most cases github. If you organize your shared tasks properly in a github repo, that repo can be attached to other repos as a git submodule. That submodule is defined at a particular SHA of the shared tasks repo giving you automatic version control. You then Lots of common script repos are shared this way here inhouse. The owners of the repos that have a dependency on the shared script repo decide when they're ready to update their repo to the HEAD of the shared repo. |
@rakhbari thanks, that is a good enough approach albeit it does feel like working around the limitation that a task can't be shared outside a namespace. |
Trying to understand how is this different from using a For example in a pipeline using:
vs
|
ClusterTask available / viewable by everyone in the cluster vs if namespaced, the access to the task can be controlled by RBAC if we choose to implement this feature request. |
@sthaha I actually don't see it as a "limitation" at all. I see it as proper use of existing tools features (rather combining features of different tools) to achieve an end. Use the right tool for the job. TektonCD shouldn't include any features that creep into version control. We already have a tool for that (Github). Hopefully that makes more sense. 😃 |
What should be our final take on this issue? @vdemeester @bobcatfish @dibyom @sthaha @rakhbari @poy @ahpook @skaegi |
My take on this is that time will tell. Right now the overwhelming consensus seems to be that we do not need this feature (non-issue) and if we can survive ( no demand for this feature from community) without the need for a SAR in tekton-controller/webhook since namespaces becomes the natural boundary for isolation then it does keep the codebase simpler. I am happy for us to close this issue and revisit when there is a demand. |
Given @sthaha 's comment I'm going to close this issue for now. We can revisit it again in the future |
@dibyom: Closing this issue. In response to this:
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. |
Expected Behavior
It would be nice to be able to refer a Task from another namespace. Something like the following.
or
The security aspect of this should be simple, we let kubernetes RBAC handle this (aka if the user can't access
Task
from the other namespace, then we fail and report an error 👼Actual Behavior
To refer a
Task
intaskRef
, today you need to have thisTask
in the same namespace.Additional Info
Related to #964 (and https://docs.google.com/document/d/1O8VHZ-7tNuuRjPNjPfdo8bD--WDrkcz-lbtJ3P8Wugs/edit#)
/kind feature
The text was updated successfully, but these errors were encountered: