Enforce Step.image is under control of Task Author

[chuangw6]

Feature request

Tekton Controller should have some enforcement to make sure that some critical fields in a TaskSpec are fully under control of the task author even though the fields accept parameter injection. Step.Image is the critical field that determines what will be run in a K8s pod.

• Phase 1: If a parameter variable is used in Step.Image field, Tekton Controller checks whether there is an allowed list specified for that parameter.

  Note:

  • Allow Task Authors specify a Param Allowed List #7084 proposes to add allowed field in ParamSpec to let Task Author declare the allowlist upfront.

  • If the allowlist for the param used in the suffix part of Step.Image contains the mutable tag reference, phase 1 can still recognize it's controlled by the author.

    apiVersion: tekton.dev/v1beta1
    kind: Task
    metadata:
      name: image-params
    spec:
      params:
      - name: ref
        allowed: ["@sha256:foo", ":v1"]
      steps:
      - image: gcr.io/kaniko$(params.ref)

• Phase 2: Tekton controller checks whether Task Author has the full control in Step.Image. That means

  • if a param is used and allowlist is also specified for the param, but the allowlist contains the mutable tag reference, Tekton Controller resolves the tag to a digest first, and then checks if the resolved sha is in the allowlist. (Note: existing implementation already resolves tag -> sha if there is no command specified)
  • if resolved sha is not in allowlist i.e. the allowlist only contains tag, this should fail b/c it's not fully controlled by task author.

Use case

As mentioned above, Step.Image field is so critical that it determines what will be run in a K8s pod. Tekton needs to have this enforcement to make sure that our security feature i.e. trusted task is really secure. Otherwise, there will be a case that a signed task can be successfully verified by our "trusted resources" feature, but param injection is not controlled, which is a security hole, and compromises our security story in Tekton.

It's worth noting that there are many OSS Policy-as-Code solutions (i.e. https://kyverno.io/) that allows cluster operators to create policies against the resources in their cluster. And it offers great flexibility in terms of resource filtering and policy rules definition. But the difference between this requested feature and kyverno is that

• This feature in tekton is to enforce that the control (via allowlist) exists.
• kverno is a tool to use to implement the control via those fine-grained policies.

[chuangw6]

On 2023-09-01, spoke with @QuanZhang-William and @vdemeester about this ticket. We are aligned that this would be a helpful feature. Note: This feature will be gated by dedicated feature flag. Also, we will think about how to make this enforcement namespace-scoped, which will be helpful to some customers who don't want to apply it to the whole cluster when the feature flag is turned on.

[QuanZhang-William]

/cc @tektoncd/core-maintainers