Allow Task Authors specify a Param Allowed List

[QuanZhang-William]

Feature request

Today, Tekton does not have a native way to validate param input values. As a workaround, Task authors need to create extra validation tasks/steps, or embed the param input validation in the script.

A Task Author should be able to specify a list of allowed values for the param.

At runtime, the Tekton Controller checks the user provided param value against the corresponding allowed values defined by the Task Author. The Tekton Controller passes the validation if the user-provided value is in the allowed list, it fails the validation otherwise.

Proposal

One solution is to introduce a new allowed API field under spec.param e.g.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: demo
spec:
  Params:
    - name: identifier
      type: string
      allowed: ["sha256:foo", "sha256:bar", "sha256:baz"]
  steps:
    - name: s1
      image: gcr.io/kaniko/executor@$(params.identifier)

Ideally, the param allowlist should be able to take CEL or Regular expressions.

Use case

• As a task author, I wan to restrict users to use only supported versions of kaniko/golang image
• As a task author, I want to make sure user passes in valid storageClass values In gcs-create-bucket.yaml.
• As a Task Author in an organization, I want to limit the locations that files can be uploaded to In gcs-upload.yaml.
• If Regex/CEL is supported, Task Authors can validate the user input from required format (e.g. check-name-match task can be simplified in our CI), and required fields are not empty (for example, repository to be cloned) ...

[QuanZhang-William]

/cc @tektoncd/core-maintainers

[jerop]

+1 to improving the schema for params

consider naming the field enum instead of allowed to reuse a concept that many users would be familiar with

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: demo
spec:
  Params:
    - name: identifier
      type: string
      enum: 
        - "sha256:foo"
        - "sha256:bar"
        - "sha256:baz"
  steps:
    - name: s1
      image: gcr.io/kaniko/executor@$(params.identifier)

@skaegi had previously proposed the enum field in #1393 (comment), and it was also discussed in #2610

[jerop]

cc @pritidesai as discussed in data interface wg

[QuanZhang-William]

+1 to improving the schema for params

consider naming the field enum instead of allowed to reuse a concept that many users would be familiar with

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: demo
spec:
  Params:
    - name: identifier
      type: string
      enum: 
        - "sha256:foo"
        - "sha256:bar"
        - "sha256:baz"
  steps:
    - name: s1
      image: gcr.io/kaniko/executor@$(params.identifier)

@skaegi had previously proposed the enum field in #1393 (comment), and it was also discussed in #2610

This is a good suggestion. We could also consider to introduce another layer named constrains or rules so that it is easier to support CEL or Regex in the future (we may also need to validation only 1 constrain type is specified):

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: demo
spec:
  Params:
    - name: identifier
      type: string
      constrains:
        enum: 
          - "sha256:foo"
          - "sha256:bar"
          - "sha256:baz"
      # cel: "some cel expression"
      # regex: "some regular expression"
  steps:
    - name: s1
      image: gcr.io/kaniko/executor@$(params.identifier)

However, we could focus on the enum constrain in the first phase of the feature.