Documentation: Security/authorization model for Tekton users in a multi-tenant cluster

[jcmcken]

I'm not sure this is the appropriate avenue to ask this question, but I'm wondering about Tekton and multi-tenancy.

We have some general purpose clusters with RBAC enabled and customer workloads completely namespaced, using OPA policy and some other mechanisms to prevent customers from executing privileged operations in the cluster (e.g. accessing the host, accessing other customers' workloads, etc.)

In such a set up, how does Tekton come into the picture? For example, can we deloy Tekton as a "cluster-wide service" while still maintaining namespace separation for cluster tenants? Can we prevent cluster tenants from using Tekton to escalate privileges within the cluster (e.g. use privileged Linux capabilities, run privileged containers, etc.)?

Based on the history of the project (Knative Build + kaniko for unprivileged image builds), I'm thinking Tekton does fit into this picture. But I'm looking for specifics or documentation that explains it in more depth. I took a look at the Kubernetes objects in the Tekton installation files, and I see Tekton receives some elevated privileges. But it's not particularly clear what the workflow looks like.

[ghost]

I think it's fair to say that support for multi-tenant scenarios is somewhat nascent in Tekton Pipelines.

We've started by creating separate roles for the Pipelines controller:

• tekton-pipelines-controller-cluster-access accounts for cluster-scope access that the controller currently requires.
• tekton-pipelines-controller-tenant-access accounts for namespace-scope access that the controller requires.

Notice that currently both of these are bound using ClusterRoleBindings. This is intentional for backwards-compatibility with Tekton's existing behaviour. However, in a multi-tenant scenario you could modify tekton-pipelines-controller-tenant-access to be a RoleBinding instead, assigning the role to only those namespaces where tenant CI/CD workloads live.

I think there's still a fair amount of work to be done both on the Tekton side as well as the Knative side to fully support locked down multi-tenant situations. But to be honest I'm also not an expert on this stuff. Help would be very much appreciated if anyone wants to tackle this.

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