Does SPIRE improve non-falsifiable provenance?

[jimmyjones2]

Have been thinking about TEP-0089 and non-falsifiable provenance. I'm struggling to see how it's possible to improve on the controls than Kubernetes RBAC already provides.

As noted in TEP-0089, a potential threat is exec'ing into a pod. While there might only be a small number of admins with this ability, there may be service accounts with this ability in the namespace (or in other namespaces, such as an ArgoCD service account used for deployment). In OpenShift the pipeline SA has the edit ClusterRole - and as it's the only SA available out of the box that has root privileges, many PipelineRuns will need to use it - meaning TaskRuns will have the ability to exec into other pods.

I think the ability to modify PVC contents is an additional threat. If the contents is changed between a git-clone task and a container build task, there is no longer a guarantee the build is of the git reference that was checked out. The ability to change the contents of a PVC is granted to anyone that can create a pod (including indirectly, such as a Deployment or PipelineRun with an inline TaskSpec - #5359). Also, as per above, if there is a powerful service account in the namespace, the pod can be run with that SA to give exec permission into other pods.

With both the above there seem multiple viable ways to exec into the pod of a TaskRun, get access to the certificate and sign results of the TaskRun.

If the whole point of TEP-0089 is to prevent an unauthorised party changing the results of a TaskRun, that's something that can be controlled already by RBAC. Adding SPIFFE/SPIRE is just as dependent on correct RBAC so I don't see how it significantly improves the situation? Or am I missing something - my knowledge of the internals of Tekton isn't great!

[jagathprakash]

Thanks for raising these concerns. There are a few concerns here

1. Proper RBAC can provide the same level of security as SPIRE. - With proper RBAC, we can prevent any workload from modifying the Tekton resources, which in turn means we can ensure non-falsifiable results. But if an admin wants to change the results, it is still possible. With SPIRE signing we will know if a result has been modified by anybody other than the task.
2. Admins can get access to SPIRE certificates by exec'ing into the pod - This is a valid concern which can be mitigated by preventing exec into pods. This has been addressed in TEP-0089. RBAC nor SPIRE can prevent falsification of results if execs are permitted.
3. Ability to modify PVC - If TEP-0089 were extended to sign PVC contents, we could prevent such threats.

Deploying SPIRE the correct way will ensure that results are not falsified by any workload or admin. Proper RBAC alone cannot ensure non-falsifiable provenance.

Non-result artifacts generated by TaskRuns or PipelineRuns can still be falsified by an attacker even after TEP-0089, but there could be a path with SPIRE to prevent it.

[jagathprakash]

@lumjjb @pxp928

[jimmyjones2]

To give a simple example - I've got a namespace where some kind of trusted process creates PipelineRuns on behalf of developers. admins are granted ClusterRole edit and developers view.

In this simple case, SPIRE wouldn't help - I can already adequately prevent developers from modifying TaskRun/PipelineRun CRDs - but still can't prevent admins from falsifying provenance (because they can exec).

Even just adding RBAC allowing developers to create PipelineRuns would allow them to falsify provenance (on OpenShift at least) because they could create an inline TaskSpec using the pipelines SA to exec into pods belonging to other PipelineRuns.

[lumjjb]

protecting against exec is something that is a part of ensuring the non-falsifiable provenance, the hope is to have this control be baked into the kubelet and have these be immutable and verifiable for a deployment of kubernetes. So yes, there is a bit more work to move the needle and this is part of the solution.

Today, without that, there are some deployment models where this can be enforced (e.g. managed kubernetes systems) depending on the threat model.

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

[jerop]

/lifecycle frozen