Tekton – Operator

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Config

TektonConfig custom resource is the top most component of the operator which allows user to install and customize all other components at a single place.

Operator provides support for installing and managing following operator components through TektonConfig:

Other than the above components depending on the platform operator also provides support for

On both Kubernetes and OpenShift
- TektonChain
On Kubernetes
- TektonDashboard
On OpenShift
- TektonAddon
- OpenShiftPipelinesAsCode

The TektonConfig CR provides the following features

  apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    targetNamespace: tekton-pipelines
    targetNamespaceMetadata:
      labels: {}
      annotations: {}
    profile: all
    config:
      nodeSelector: <>
      tolerations: []
      priorityClassName: system-cluster-critical
    chain:
      disabled: false
    pipeline:
      await-sidecar-readiness: true
      coschedule: workspaces
      disable-affinity-assistant: false
      disable-creds-init: false
      disable-home-env-overwrite: true
      disable-working-directory-overwrite: true
      disable-inline-spec: "pipeline,pipelinerun,taskrun"
      enable-api-fields: beta
      enable-bundles-resolver: true
      enable-cel-in-whenexpression: false
      enable-cluster-resolver: true
      enable-custom-tasks: true
      enable-git-resolver: true
      enable-hub-resolver: true
      enable-param-enum: false
      enable-provenance-in-status: true
      enable-step-actions: false
      enforce-nonfalsifiability: none
      keep-pod-on-cancel: false
      max-result-size: 4096
      metrics.count.enable-reason: false
      metrics.pipelinerun.duration-type: histogram
      metrics.pipelinerun.level: pipeline
      metrics.taskrun.duration-type: histogram
      metrics.taskrun.level: task
      require-git-ssh-secret-known-hosts: false
      results-from: termination-message
      running-in-environment-with-injected-sidecars: true
      send-cloudevents-for-runs: false
      set-security-context: false
      trusted-resources-verification-no-match-policy: ignore
      performance:
        disable-ha: false
        buckets: 1
        replicas: 1
        threads-per-controller: 2
        kube-api-qps: 5.0
        kube-api-burst: 10
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    pruner:
      disabled: false
      schedule: "0 8 * * *"
      resources:
        - taskrun
        - pipelinerun
      keep: 3
      # keep-since: 1440
      # NOTE: you can use either "keep" or "keep-since", not both
      prune-per-resource: true
    hub:
      params:
        - name: enable-devconsole-integration
          value: "true"
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    dashboard:
      readonly: true
      options:
        disabled: false
        configMaps: {}
        deployments: {}
        webhookConfigurationOptions: {}
    platforms:
      openshift:
        pipelinesAsCode:
          additionalPACControllers:
            <controllerName>:
              enable: true
              configMapName:
              secretName:
              settings:
          enable: true
          settings:
            application-name: Pipelines as Code CI
            auto-configure-new-github-repo: "false"
            bitbucket-cloud-check-source-ip: "true"
            custom-console-name: ""
            custom-console-url: ""
            custom-console-url-pr-details: ""
            custom-console-url-pr-tasklog: ""
            error-detection-from-container-logs: "false"
            error-detection-max-number-of-lines: "50"
            error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
              ]*)?(?P<error>.*)
            error-log-snippet: "true"
            hub-catalog-name: tekton
            hub-url: https://api.hub.tekton.dev/v1
            remote-tasks: "true"
            secret-auto-create: "true"
            secret-github-app-token-scoped: "true"
        options:
          disabled: false
          configMaps: {}
          deployments: {}
          webhookConfigurationOptions: {}

Look for the particular section to understand a particular field in the spec.

Target Namespace

This allows user to choose a namespace to install the Tekton Components such as pipelines, triggers.

By default, namespace would be tekton-pipelines for Kubernetes and openshift-pipelines for OpenShift.

Note: Namespace openshift-operators is not allowed in OpenShift as a targetNamespace.

Target Namespace Metadata

targetNamespaceMetadata allows user to add their custom labels and annotations to the target namespace via TektonConfig CR.

Profile

This allows user to choose which all components to install on the cluster. There are 3 profiles available:

all: This profile will install all components (TektonPipeline, TektonTrigger and TektonChain)
basic: This profile will install only TektonPipeline, TektonTrigger and TektonChain component
lite: This profile will install only TektonPipeline component

On Kubernetes, all profile will install TektonDashboard and on OpenShift TektonAddon will be installed.

Config

Config provides fields to configure deployments created by the Operator. This provides following fields:

User can pass the required fields and this would be passed to all Operator components which will get added in all deployments created by Operator.

Example:

config:
  nodeSelector:
    key: value
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"
  priorityClassName: system-node-critical

This is an Optional section.

NOTE: If spec.config.priorityClassName is used, then the required priorityClass is expected to be created by the user to get the Tekton resources pods in running state

Pipeline

Pipeline section allows user to customize the Tekton pipeline features. This allow user to customize the values in configmaps.

Refer to properties section in TektonPipeline for available options.

Some of the fields have default values, so operator will add them if user haven’t passed in CR. Other fields which doesn’t have default values won’t be passed unless user specify them in CR. User can find those here.

Example:

pipeline:
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  enable-api-fields: stable
  enable-custom-tasks: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipelinerun
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: taskrun
  require-git-ssh-secret-known-hosts: false
  running-in-environment-with-injected-sidecars: true
  trusted-resources-verification-no-match-policy: ignore
  performance:
    replicas: 1
    disable-ha: false
    buckets: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

Chain

Chain section allows user to customize the Tekton Chain features. This allows user to customize the values in configmaps

Refer to properties section in TektonChain for available options

Example:

chain:
  disabled: false                  # - `disabled` : if the value set as `true`, chains feature will be disabled (default: `false`)
  targetNamespace: tekton-pipelines
  controllerEnvs:
    - name: MONGO_SERVER_URL      # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.kmsref.auth.address: #value
  signers.kms.kmsref.auth.token: #value
  signers.kms.kmsref.auth.oidc.path: #value
  signers.kms.kmsref.auth.oidc.role: #value
  signers.kms.kmsref.auth.spire.sock: #value
  signers.kms.kmsref.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Pruner

Pruner provides auto clean up feature for the Tekton pipelinerun and taskrun resources. In the background pruner container runs tkn command.

Example:

pruner:
  disabled: false
  schedule: "0 8 * * *"
  startingDeadlineSeconds: 100 # optional
  resources:
    - taskrun
    - pipelinerun
  keep: 3
  # keep-since: 1440
  # NOTE: you can use either "keep" or "keep-since", not both
  prune-per-resource: true

disabled : if the value set as true, pruner feature will be disabled (default: false)
schedule: how often to run the pruner job. User can understand the schedule syntax here.
startingDeadlineSeconds: Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones
resources: supported resources for auto prune are taskrun and pipelinerun
keep: maximum number of resources to keep while deleting or removing resources
keep-since: retain the resources younger than the specified value in minutes
prune-per-resource: if the value set as true (default value false), the keep applied to each resource. The resources(pipeline and/or task) taken dynamically from that namespace and applied.
example: in a namespace ns-1 I have two pipeline, named pipeline-1 and pipeline-2, the out come would be: tkn pipelinerun delete --pipeline=my-pipeline-1 --keep=3 --namespace=ns-1, tkn pipelinerun delete --pipeline=my-pipeline-2 --keep=3 --namespace=ns-1. the same way works for task too.
We do not see any benefit by enabling prune-per-resource=true, when you use keep-since. As keep-since is limiting the resources by time(irrespective of resource count), there is no change on the outcome.

Note:

if disabled: false and schedule: with empty value, global pruner job will be disabled. however, if there is a prune schedule (operator.tekton.dev/prune.schedule) annotation present with a value in a namespace. a namespace wide pruner jobs will be created.

Pruner Namespace annotations

By default pruner job will be created from the global pruner config (spec.pruner), though user can customize a pruner config to a specific namespace with the following annotations. If some of the annotations are not present or has invalid value, for that value, falls back to global value or skipped the namespace.

operator.tekton.dev/prune.skip - pruner job will be skipped to a namespace, if the value set as true
operator.tekton.dev/prune.schedule - pruner job will be created on a specific schedule
operator.tekton.dev/prune.keep - maximum number of resources will be kept
operator.tekton.dev/prune.keep-since - retain the resources younger than the specified value in minutes
operator.tekton.dev/prune.prune-per-resource - the keep or keep-since applied to each resource
operator.tekton.dev/prune.resources - can be taskrun and/or pipelinerun, both value can be specified with comma separated. example: taskrun,pipelinerun
operator.tekton.dev/prune.strategy - allowed values: either keep or keep-since

Note:

if a global value is not present the following values will be consider as default value
resources: pipelinerun
keep: 100

Addon

TektonAddon install some resources along with Tekton Pipelines on the cluster. This provides few ClusterTasks, PipelineTemplates, Tasks.

This section allows to customize installation of those resources through params. You can read more about the supported params here.

Example:

addon:
  params:
    - name: "clusterTask"
      value: "true"
    - name: "pipelineTemplates"
      value: "true"
    - name: "resolverTasks"
      value: "true"
    - name: "resolverStepActions"
      value: "true"

NOTE: TektonAddon is currently available for OpenShift Platform only. Enabling this for Kubernetes platform is in roadmap of Operator.

Hub

This is to enable/disable showing hub resources in pipeline builder of devconsole(OpenShift UI). By default, the field is not there in the config object. If you want to disable the integration, you can add the param like below in config with value false. The possible values are true and false.

Example:

hub:
  params:
    - name: enable-devconsole-integration
      value: "false"

Dashboard

Dashboard provides configuration options for the Tekton Dashboard if the specified profile value includes the Dashboard component. (E.g. all on Kubernetes)

Example:

dashboard:
  readonly: true

readonly: If set to true, install the Dashboard in read-only mode

This is an Optional section.

Resolvers

As part of TektonPipelines, resolvers are installed which are by default enabled. User can disable them through TektonConfig.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

User can also provide resolver specific configurations through TektonConfig. The Default configurations are not added by default in TektonConfig. To override default configurations, user can provide the configurations as below. You can find the default configurations here

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: cluster-resolver-test
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
      tekton-hub-api: "https://my-custom-tekton-hub.example.com"
      artifact-hub-api: "https://my-custom-artifact-hub.example.com"

Under the hub-resolver-config, the tekton-hub-api and artifact-hub-api will be passed as environment variable into tekton-pipelines-remote-resolvers controller.
In the deployment the environment name will be converted as follows,

tekton-hub-api => TEKTON_HUB_API
artifact-hub-api => ARTIFACT_HUB_API

OpenShiftPipelinesAsCode

The PipelinesAsCode section allows you to customize the Pipelines as Code features. When you change the TektonConfig CR, the Operator automatically applies the settings to custom resources and configmaps in your installation.

Some of the fields have default values, so operator will add them if the user hasn’t passed in CR. Other fields which don’t have default values unless the user specifies them. User can find those here.

Example:

platforms:
  openshift:
    pipelinesAsCode:
      additionalPACControllers:
        controllername:
          enable: true
          configMapName:
          secretName:
          settings:
      enable: true
      settings:
        application-name: Pipelines as Code CI
        auto-configure-new-github-repo: "false"
        bitbucket-cloud-check-source-ip: "true"
        custom-console-name: ""
        custom-console-url: ""
        custom-console-url-pr-details: ""
        custom-console-url-pr-tasklog: ""
        error-detection-from-container-logs: "false"
        error-detection-max-number-of-lines: "50"
        error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
          ]*)?(?P<error>.*)
        error-log-snippet: "true"
        hub-catalog-name: tekton
        hub-url: https://api.hub.tekton.dev/v1
        remote-tasks: "true"
        secret-auto-create: "true"
        secret-github-app-token-scoped: "true"

NOTE: OpenShiftPipelinesAsCode is currently available for the OpenShift Platform only.

Additional fields as `options`

There is a field called options available in all the components.

NOTE: There is a possibility to have two different values for a field.
An example: with a pre-defined field you can set value and the same field may be defined under options as well. In that case value from options will be final.

A sample options field,

options:
  disabled: false
  configMaps:
    config-leader-election: # name of the configMap
      data:
        lease-duration: "90s"
    pipeline-config-logging: # creates new configMap under targetNamespace
      metadata:
        labels:
          my-custom-logger: "true"
        annotations:
          logger-type: "uber-zap"
      data:
        loglevel.controller: "info"
        loglevel.webhook: "info"
        zap-logger-config: |
          {
            "level": "debug",
            "development": false,
            "sampling": {
              "initial": 100,
              "thereafter": 50
            },
            "outputPaths": ["stdout"],
            "errorOutputPaths": ["stderr"],
            "encoding": "json",
            "encoderConfig": {
              "timeKey": "ts",
              "levelKey": "severity",
              "nameKey": "logger",
              "callerKey": "caller",
              "messageKey": "message",
              "stacktraceKey": "stacktrace",
              "lineEnding": "",
              "levelEncoder": "",
              "timeEncoder": "iso8601",
              "durationEncoder": "",
              "callerEncoder": ""
            }
          }          

  deployments:
    tekton-pipelines-controller: # name of the deployment
      metadata:
        labels:
          custom-label: "foo"
        annotations:
          custom-annotation: "foo"
      spec:
        replicas: 2
        template:
          spec:
            containers:
              - name: tekton-pipelines-controller
                env:
                  - name: CONFIG_LOGGING_NAME
                    value: pipeline-config-logging
  statefulSets:
    web: # name of the statefulSets
      metadata:
        labels:
          custom-label: foo
        annotations:
          custom-annotation: foo
      spec:
        replicas: 3
        template:
          spec:
            containers:
              - name: nginx
                env:
                  - name: NGINX_MODE
                    value: production
  horizontalPodAutoscalers:
    tekton-pipelines-webhook: # name of the hpa
      metadata:
        annotations:
        labels:
      spec:
        minReplicas: 2
        maxReplicas: 7
        metrics:
        - resource:
            name: cpu
            target:
              averageUtilization: 85
              type: Utilization
          type: Resource
  webhookConfigurationOptions:
    validation.webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None
    webhook.pipeline.tekton.dev:
      failurePolicy: Fail
      timeoutSeconds: 20
      sideEffects: None

disabled - disables the additional options support, if disabled set to true. default: false

ConfigMaps

Supports to update existing configMap also supports to create new configMap.

The following fields are supported in configMap

metadata
- labels - supports add and update
- annotations - supports add and update
data - supports add and update

Deployments

Supports to update the existing deployments. But not supported to create new deployment.

The following fields are supported in deployment

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates deployment replicas count
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - volumes - adds and updates volumes
    - initContainers - updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

StatefulSets

Supports to update the existing StatefulSet. But not supported to create new StatefulSet.

The following fields are supported in StatefulSet

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- replicas - updates statefulSets replicas count
- serviceName - updates service name
- podManagementPolicy - updates pod management policy
- volumeClaimTemplates - updates volume claim templates
- template
  - metadata
    - labels - supports add and update
    - annotations - supports add and update
  - spec
    - affinity - replaces the existing Affinity with this, if not empty
    - priorityClassName - replaces the existing PriorityClassName with this, if not empty
    - nodeSelector - replaces the existing NodeSelector with this, if not empty
    - tolerations - replaces the existing tolerations with this, if not empty
    - topologySpreadConstraints - replaces the existing TopologySpreadConstraints with this, if not empty
    - volumes - adds and updates volumes
    - initContainers - updates init-containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS
    - containers - updates containers
      - resources - replaces the resources requirements with this, if not empty
      - envs - adds and updates environments
      - volumeMounts - adds and updates VolumeMounts
      - args - appends given args with existing arguments. NOTE: THIS OPERATION DO NOT REPLACE EXISTING ARGS

HorizontalPodAutoscalers

Supports to update the existing HorizontalPodAutoscaler(HPA) also supports to create new HPA.

The following fields are supported in HorizontalPodAutoscaler (aka HPA)

metadata
- labels - supports add and update
- annotations - supports add and update
spec
- scaleTargetRef - replaces scaleTargetRef with this, if kind and name are not empty
- minReplicas - updates minimum replicas count
- maxReplicas - updates maximum replicas count
- metrics - replaces the metrics details with this array, if not empty
- behavior - updates behavior data with this, if not empty
  - scaleUp - replaces scaleUp with this, if not empty
  - scaleDown - replaces scaleDown with this, if not empty

NOTE: If a Deployment or StatefulSet has a Horizontal Pod Autoscaling (HPA) and is in active state, Operator will not control the replicas to that resource. However if status.desiredReplicas and spec.minReplicas not present in HPA, operator takes the control. Also if HPA disabled, operator takes control. Even though the operator takes the control, the replicas value will be adjusted to the hpa’s scaling range.

webhookConfigurationOptions

Defines additional options for each webhooks. Use webhook name as a key to define options for a webhook. Options are ignored if the webhook does not exist with the name key. To get detailed information about webhooks options visit https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/

the following options are supported for webhookConfigurationOptions

failurePolicy - defines how unrecognized errors and timeout errors from the admission webhook are handled. Allowed values are Ignore or Fail
timeoutSeconds - allows configuring how long the API server should wait for a webhook to respond before treating the call as a failure.
sideEffects - indicates whether the webhook have a side effet. Allowed values are None, NoneOnDryRun, Unknown, or Some

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Pipeline

TektonPipeline custom resource allows user to install and manage Tekton Pipeline.

It is recommended to install the component through TektonConfig.

The TektonPipeline CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonPipeline
metadata:
  name: pipeline
spec:
  targetNamespace: tekton-pipelines
  await-sidecar-readiness: true
  coschedule: workspaces
  disable-affinity-assistant: false
  disable-creds-init: false
  disable-home-env-overwrite: true
  disable-working-directory-overwrite: true
  disable-inline-spec: "taskrun,pipelinerun,pipeline"
  enable-api-fields: beta
  enable-bundles-resolver: true
  enable-cel-in-whenexpression: false
  enable-cluster-resolver: true
  enable-custom-tasks: true
  enable-git-resolver: true
  enable-hub-resolver: true
  enable-param-enum: false
  enable-provenance-in-status: true
  enable-step-actions: false
  enforce-nonfalsifiability: none
  keep-pod-on-cancel: false
  max-result-size: 4096
  metrics.count.enable-reason: false
  metrics.pipelinerun.duration-type: histogram
  metrics.pipelinerun.level: pipeline
  metrics.taskrun.duration-type: histogram
  metrics.taskrun.level: task
  require-git-ssh-secret-known-hosts: false
  results-from: termination-message
  running-in-environment-with-injected-sidecars: true
  send-cloudevents-for-runs: false
  set-security-context: false
  trusted-resources-verification-no-match-policy: ignore
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10
  options:
    disabled: false
    configMaps: {}
    deployments: {}

You can install this component using TektonConfig by choosing appropriate profile.

Properties

This fields have default values so even if user have not passed them in CR, operator will add them. User can later change them as per their need.

disable-affinity-assistant (Default: false)

Setting this flag to “true” will prevent Tekton to create an Affinity Assistant for every TaskRun sharing a PVC workspace. The default behaviour is for Tekton to create Affinity Assistants.

See more in the workspace documentation about Affinity Assistant or more info here.
disable-creds-init (Default: false)

Setting this flag to “true” will prevent Tekton scanning attached service accounts and injecting any credentials it finds into your Steps.

The default behaviour currently is for Tekton to search service accounts for secrets matching a specified format and automatically mount those into your Steps.

Note: setting this to “true” will prevent PipelineResources from working. See more info here.
await-sidecar-readiness (Default: true)

Setting this flag to “false” to allow the Tekton controller to start a TasksRun’s first step immediately without waiting for sidecar containers to be running first.

Note: setting this flag to “false” will mean the running-in-environment-with-injected-sidecars flag has no effect.
coschedule (Default: workspaces)

This flag determines how PipelineRun Pods are scheduled with Affinity Assistant. Acceptable values are “workspaces” (default), “pipelineruns”, “isolate-pipelinerun”, or “disabled”
running-in-environment-with-injected-sidecars (Default: true)

This option should be set to false when Pipelines is running in a cluster that does not use injected sidecars such as Istio. Setting it to false should decrease the time it takes for a TaskRun to start running. For clusters that use injected sidecars, setting this option to false can lead to unexpected behavior.

See more info here.
require-git-ssh-secret-known-hosts (Default: false)

Setting this flag to “true” will require that any Git SSH Secret offered to Tekton must have known_hosts included.

See more info here.
enable-custom-tasks (Default: false)

Setting this flag to “true” enables the use of custom tasks from within pipelines. This is an experimental feature and thus should still be considered an alpha feature.
enable-api-fields (Default: stable)

Setting this flag will determine which gated features are enabled. Acceptable values are “stable” or “alpha”.
results-from (Default: termination-message)

This feature is to use the container’s termination message to fetch results from. Set it to “sidecar-logs” to enable use of a results sidecar logs to extract results instead of termination message.
max-result-size (Default: 4096)

This feature is to configure the size of the task results if using sidecar-logs. The default value if 4096 and maximum value can be 1572863.
enable-provenance-in-status (Default: true)

This feature is to enable populating the provenance field in TaskRun and PipelineRun status. The provenance field contains metadata about resources used in the TaskRun/PipelineRun such as the source from where a remote Task/Pipeline definition was fetched. To disable populating this field, set this flag to “false”.
set-security-context (Default: false)

Setting this flag to “true” to set a security context for containers injected by Tekton that will allow TaskRun pods to run in namespaces with restricted pod security admission
keep-pod-on-cancel (Default: false)

Setting this flag to “true” will not delete the pod associated with cancelled taskrun.
enforce-nonfalsifiability (Default: none)

Setting this flag to “spire” to enable integration with SPIRE.
enable-param-enum (Default: false)

Setting this flag to “true” will enable params of type Enum
enable-step-actions (Default: false)

Setting this flag to “true” will enable specifying StepAction in a Step. A StepAction is the reusable and scriptable unit of work that is performed by a Step
enable-cel-in-whenexpression (Default: false)

Setting this flag to “true” will enable using CEL in when expressions.
trusted-resources-verification-no-match-policy (Default: ignore)

Trusted Resources is a feature which can be used to sign Tekton Resources and verify them. Details of design can be found at TEP–0091. This feature is under alpha version and support v1beta1 version of Task and Pipeline. To know more about this visit pipelines documentation

Metrics Properties

These fields have default values so even if user have not passed them in CR, operator will add them and override the values configure in pipelines.

metrics.pipelinerun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.pipelinerun.level (Default: pipeline)

Setting this flag will determine the level of pipelinerun metrics.
metrics.taskrun.duration-type (Default: histogram)

Setting this flag will determine the duration type - gauge or histogram.
metrics.taskrun.level (Default: task)

Setting this flag will determine the level of taskrun metrics.
metrics.count.enable-reason (Default: false)

Setting this flag to “true” will include reason label on count metrics.

Optional Properties

This fields doesn’t have default values so will be considered only if user passes them. By default Operator won’t add this fields CR and won’t configure for pipelines.

The Default values for this fields are already set in pipelines are not set by Operator. If user passes some values then those will be set for the particular field.

default-timeout-minutes

default-timeout-minutes contains the default number of minutes to use for TaskRun and PipelineRun, if none is specified.

default-timeout-minutes: "60" # 60 minutes
default-service-account

default-service-account contains the default service account name to use for TaskRun and PipelineRun, if none is specified.

default-service-account: "default"
default-managed-by-label-value

default-managed-by-label-value contains the default value given to the “app.kubernetes.io/managed-by” label applied to all Pods created for TaskRuns. If a user’s requested TaskRun specifies another value for this label, the user’s request supersedes.

default-managed-by-label-value: "tekton-pipelines"
disable-inline-spec (Default: ``)

Inline specifications can be disabled for specific resources only. To achieve that, set the disable-inline-spec flag to a comma-separated list of the desired resources. Valid values are pipeline, pipelinerun and taskrun.
default-pod-template

default-pod-template contains the default pod template to use TaskRun and PipelineRun, if none is specified. If a pod template is specified, the default pod template is ignored.
default-cloud-events-sink

default-cloud-events-sink contains the default CloudEvents sink to be used for TaskRun and PipelineRun, when no sink is specified. Note that right now it is still not possible to set a PipelineRun or TaskRun specific sink, so the default is the only option available. If no sink is specified, no CloudEvent is generated
default-task-run-workspace-binding

default-task-run-workspace-binding contains the default workspace configuration provided for any Workspaces that a Task declares but that a TaskRun does not explicitly provide.
default-resolver-type

default-resolver-type contains the resolver type to be used as default resolver.

Performance Properties

spec:
  # omitted other fields ...
  performance:
    disable-ha: false
    buckets: 1
    replicas: 1
    threads-per-controller: 2
    kube-api-qps: 5.0
    kube-api-burst: 10

These fields are optional and there is no default values. If user passes them, operator will include most of fields into the deployment tekton-pipelines-controller under the container tekton-pipelines-controller as arguments(duplicate name? No, container and deployment has the same name), otherwise pipelines controller’s default values will be considered. and buckets field is updated into config-leader-election config-map under the namespace tekton-pipelines.

A high level descriptions are given here. To get the detailed information please visit pipelines documentation, High Availability Support, and Performance Configuration

disable-ha - enable or disable ha feature, defaults in pipelines controller is disable-ha=false
buckets - buckets is the number of buckets used to partition key space of each reconciler. If this number is M and the replica number of the controller is N, the N replicas will compete for the M buckets. The owner of a bucket will take care of the reconciling for the keys partitioned into that bucket. The maximum value of buckets at this time is 10. default value in pipeline controller is 1
replicas - pipelines controller deployment replicas count
threads-per-controller - is the number of threads(aka worker) to use when processing the pipelines controller’s workqueue, default value in pipelines controller is 2
kube-api-qps - QPS indicates the maximum QPS to the cluster master from the REST client, default value in pipeline controller is 5.0
kube-api-burst - maximum burst for throttle, default value in pipeline controller is 10

Note:

kube-api-qps and kube-api-burst will be multiplied by 2 in pipelines controller. To get the detailed information visit Performance Configuration guide

if you modify or remove any of the performance properties, tekton-pipelines-controller deployment and config-leader-election config-map (if buckets changed) will be updated, and tekton-pipelines-controller pods will be recreated

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Trigger

TektonTrigger custom resource allows user to install and manage Tekton Trigger.

It is recommended to install the components through TektonConfig.

The TektonTrigger CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonTrigger
metadata:
  name: trigger
spec:
  targetNamespace: tekton-pipelines

You can install this component using TektonConfig by choosing appropriate profile.

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Dashboard

TektonDashboard custom resource allows user to install and manage Tekton Dashboard.

It is recommended to install the components through TektonConfig.

The TektonDashboard CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonDashboard
metadata:
  name: dashboard
spec:
  targetNamespace: tekton-pipelines
  readonly: false

You can install this component using TektonConfig by choosing appropriate profile.

Properties

readonly (Default: false)

If set to true, installs the Dashboard in read-only mode.

If set to false, the following features will be enabled on the Dashboard:
- delete a pipeline
- create a pipelinerun
- rerun a pipelinerun
- delete a pipelinerun
- create a pipelineresource
- create a taskrun
- import resources from repository
external-logs

External URL from which to fetch logs when logs are not available in the cluster

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Result

TektonResult custom resource allows user to install and manage Tekton Result.

TektonResult is an optional component and currently cannot be installed through TektonConfig. It has to be installed seperately.

To install Tekton Result on your cluster follow steps as given below:

Make sure Tekton Pipelines is installed on your cluster, using the Operator.
Generate a database root password. A database root password must be generated and stored in a Kubernetes Secret before installing results. By default, Tekton Results expects this secret to have the following properties:
- namespace: tekton-pipelines
- name: tekton-results-postgres
- contains the fields:
  - user=<user name>
  - password=<your password>
If you are not using a particular password management strategy, the following command will generate a random password for you: Update namespace value in the command if Tekton Pipelines is installed in a different namespace..
```
export NAMESPACE="tekton-pipelines"
kubectl create secret generic tekton-results-postgres --namespace=${NAMESPACE} --from-literal=POSTGRES_USER=result --from-literal=POSTGRES_PASSWORD=$(openssl rand -base64 20)
```

Generate cert/key pair. Note: Feel free to use any cert management software to do this!

Tekton Results expects the cert/key pair to be stored in a TLS Kubernetes Secret. Update the namespace value in below export command if Tekton Pipelines is installed in a different namespace.

export NAMESPACE="tekton-pipelines"
# Generate new self-signed cert.
openssl req -x509 \
-newkey rsa:4096 \
-keyout key.pem \
-out cert.pem \
-days 365 \
-nodes \
-subj "/CN=tekton-results-api-service.${NAMESPACE}.svc.cluster.local" \
-addext "subjectAltName = DNS:tekton-results-api-service.${NAMESPACE}.svc.cluster.local"
# Create new TLS Secret from cert.
kubectl create secret tls -n ${NAMESPACE} tekton-results-tls \
--cert=cert.pem \
--key=key.pem

Create PVC if using PVC for logging

cat <<EOF > pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tekton-logs
  namespace: tekton-pipelines
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
EOF
// Apply the above PVC
kubectl apply -f pvc.yaml

Once the secrets are created create a TektonResult CR (Check ##Properties) as below.
```
kubectl apply -f config/crs/kubernetes/result/operator_v1alpha1_result_cr.yaml
```
Check the status of installation using following command
```
kubectl get tektonresults.operator.tekton.dev
```

Spec

The TektonResult CR is like below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  targetNamespace: tekton-pipelines
  db_host: localhost
  db_port: 5342
  db_sslmode: false
  db_enable_auto_migration: true
  log_level: debug
  logs_api: true
  logs_type: File
  logs_buffer_size: 90kb
  logs_path: /logs
  auth_disable: true
  logging_pvc_name: tekton-logs
  secret_name: # optional
  gcs_creds_secret_name: <value>
  gcc_creds_secret_key: <value>
  gcs_bucket_name: <value>
  is_external_db: false
  loki_stack_name: #optional
  loki_stack_namespace: #optional

These properties are analogous to the one in configmap of tekton results api tekton-results-api-config documented at [api.md]:https://github.com/tektoncd/results/blob/4472848a0fb7c1473cfca8b647553170efac78a1/cmd/api/README.md

Property “secret_name”:

secret_name - name of your custom secret or leave it as empty. It an optional property. The secret should be created by the user on the targetNamespace. The secret can contain S3_ prefixed keys from the result API properties. Please note: the key of the secret should be in UPPER_CASE and values should be in string format. The following keys are supported by this secret.

S3_BUCKET_NAME
S3_ENDPOINT
S3_HOSTNAME_IMMUTABLE
S3_REGION
S3_ACCESS_KEY_ID
S3_SECRET_ACCESS_KEY
S3_MULTI_PART_SIZE

Sample Secret File

apiVersion: v1
kind: Secret
metadata:
  name: my_custom_secret
  namespace: tekton-pipelines
type: Opaque
stringData:
  S3_BUCKET_NAME: foo
  S3_ENDPOINT: https://example.localhost.com
  S3_HOSTNAME_IMMUTABLE: "false"
  S3_REGION: region-1
  S3_ACCESS_KEY_ID: "1234"
  S3_SECRET_ACCESS_KEY: secret_key
  S3_MULTI_PART_SIZE: "5242880"

GCS specific Property

The follow keys are needed for enabling GCS storage of logs:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  gcs_creds_secret_name: <value>
  gcc_creds_secret_key: <value>
  gcs_bucket_name: <value>

We need to create a secret with google application creds for a bucket foo-bar like below:

kubectl create secret generic gcs-credentials --from-file=creds.json

To know more about Application Default Credentials in creds.json that is use to create above secret for GCS, please visit: https://cloud.google.com/docs/authentication/application-default-credentials

In the above example, our properties are:

gcs_creds_secret_name: gcs-credentials
gcc_creds_secret_key: creds.json
gcs_bucket_name: foo-bar

External DB

It is not recommended to use internal DB, operator hard code PVC configuration and DB settings.

If you want to move from internal DB to external DB, please take backup of the DB. If you want to start fresh, then delete previous TektonResult CR. and recreate the fresh one with following instructions:

Generate a secret with user name and password for Postgres (subsitute ${password} with your password):

   export NAMESPACE="tekton-pipelines" # Put the targetNamespace of TektonResult where it is going to be installed.
   kubectl create secret generic tekton-results-postgres --namespace=${NAMESPACE} --from-literal=POSTGRES_USER=result --from-literal=POSTGRES_PASSWORD=${password}

Create a TektonResult CR like below:

Add db_host with DB url without port.
Add db_port with your DB port.
Set is_external_db to true.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  targetNamespace: tekton-pipelines
  db_port: 5432
  db_user: result
  db_host: tekton-results-postgres-external-service.pg-redhat.svc.cluster.local
  is_external_db: true
...

LokiStack + TektonResult

Tekton Results leverages external Third Party APIs to query data. Storing of data via Tekton Results is inefficient and bad for performance. It’s better to use forwarders like Vector, Promtail, Fluentd for forwarding TaskRun pod Logs from nodes.

Kubernetes (GCP) + LokiStack/Loki

Loki

You can either use Grafana’s Helm Repo or operator from OperatorHub to install Loki. Installing via operator simplies certain operations for Tekton Operator. You just need to configure lokistack_name and lokistack_namespace.

In case of helm installation, you will need to configure options field to configure Results API configMap tekton-results-api-config:

LOGS_API
LOGGING_PLUGIN_PROXY_PATH
LOGGING_PLUGIN_API_URL
LOGGING_PLUGIN_TOKEN_PATH
LOGGING_PLUGIN_NAMESPACE_KEY
LOGGING_PLUGIN_STATIC_LABELS
LOGGING_PLUGIN_TLS_VERIFICATION_DISABLE
LOGGING_PLUGIN_FORWARDER_DELAY_DURATION
LOGGING_PLUGIN_QUERY_PARAMS
LOGGING_PLUGIN_QUERY_LIMIT

Please consult the docs here for information on these fields.

These fields allow you to configure how Tekton Results interacts with your Loki backend.

You might need to configure following environment variable to Tekton Results API deployment if you are using some custom CA to generate TLS certificate:

LOGGING_PLUGIN_CA_CERT

LOGGING_PLUGIN_FORWARDER_DELAY_DURATION: This is the max duration in minutes taken by third party logging system to forward and store the logs after completion of taskrun and pipelinerun. This is used to search between start time of runs and completion plus buffer duration.

Forwarder

You need to configure forwarder systems to add labels for namespace, pass TaskRun UID/PipelineRun UID in pods and a common label key:value alongwith logs from nodes.

A sample configuration for vector: values.yaml.

OpenShift (LokiStack + OpenShift Logging)

To configure LokiStack with TektonResult, you can use the lokistack_name and lokistack_namespace properties in the TektonResult custom resource. Here’s how to do it:

First, ensure that you have LokiStack installed in your cluster.
Then, create or update your TektonResult CR with the following properties:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonResult
metadata:
  name: result
spec:
  targetNamespace: tekton-pipelines
  // ... other properties ...
  lokistack_name: your-lokistack-name
  lokistack_namespace: your-lokistack-namespace

Replace your-lokistack-name with the name of your LokiStack instance and your-lokistack-namespace with the namespace where LokiStack is installed.

By setting these properties, Operator will configure Tekton Result to use the specified LokiStack instance for log retrieval.

OpenShift Logging

Install the openshift logging operator by following this: Deploying Cluster Logging

If you are installing OpenShift Logging Operator only for TaskRun Logs, then you also need to configure a ClusterLogForwarder:

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  inputs:
  - name: only-tekton
    application:
      selector:
        matchLabels:
          app.kubernetes.io/managed-by: tekton-pipelines
  pipelines:
    - name: enable-default-log-store
      inputRefs: [ only-tekton ]
      outputRefs: [ default ]

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Addon

TektonAddon custom resource allows user to install resource like clusterTasks and pipelineTemplate along with Pipelines. It also allows user to install various Tasks in openshift-pipelines namespace.

NOTE: TektonAddon is currently available only for OpenShift Platform. This is roadmap to enable it for Kubernetes platform.

It is recommended to install the components through TektonConfig.

The TektonAddon CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonAddon
metadata:
  name: addon
spec:
  targetNamespace: openshift-pipelines
  params:
  - name: clusterTasks
    value: "true"
  - name: pipelineTemplates
    value: "true"
  - name: resolverTasks
    value: "true"
  - name: resolverStepActions
    value: "true"

You can install this component using TektonConfig by choosing appropriate profile.

Params

params provide a way to enable/disable the installation of resources. Available params are

clusterTasks (Default: true)
pipelineTemplates (Default: true)
resolverTasks (Default: true)
resolverStepActions (Default: true)

User can disable the installation of resources by changing the value to false.

Pipelines templates uses clustertasks in them so to install pipelineTemplates, clusterTasks must be true.

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Manual Approval Gate

ManualApprovalGate custom resource allows user to install and manage Manual Approval Gate.

ManualApprovalGate CR is as below

On Kubernetes, ManualApprovalGate CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: ManualApprovalGate
metadata:
  name: manual-approval-gate
spec:
  targetNamespace: tekton-pipelines

On OpenShift, ManualApprovalGate CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: ManualApprovalGate
metadata:
  name: manual-approval-gate
spec:
  targetNamespace: openshift-pipelines

Check the status of installation using following command:

kubectl get manualapprovalgates.operator.tekton.dev
NAME                   VERSION   READY   REASON
manual-approval-gate   v0.2.0    True

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Chain

TektonChain custom resource allows user to install and manage Tekton Chains.

It is recommended to install the component through TektonConfig.

TektonChain CR is as below

On Kubernetes, TektonChain CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonChain
metadata:
  name: chain
spec:
  disabled: false
  targetNamespace: tekton-pipelines

On OpenShift, TektonChain CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonChain
metadata:
  name: chain
spec:
  disabled: false
  targetNamespace: openshift-pipelines

Check the status of installation using following command:
```
kubectl get tektonchains.operator.tekton.dev
```

Chain Config

There are some fields which you can define on Tekton Chains CR to configure the behaviour of the chains

Properties (Mandatory)

targetNamespace

Setting this field to provide the namespace in which you want to install the chains component.

Properties (Optional)

These fields don’t have default values so will be considered only if user passes them. By default, Operator won’t add these fields in CR and won’t configure for chains.

The Default values for some of these fields are already set in chains and are not set by Operator. If user passes some values then those will be set for the particular field.

Details of the field can be found in Tekton Chains Config

Chains CR will look like this after providing all the fields.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonChain
metadata:
  name: chain
spec:
  disabled: false
  targetNamespace: tekton-pipelines
  controllerEnvs:
    - name: MONGO_SERVER_URL      # This is the only field supported at the moment which is optional and when added by user, it is added as env to Chains controller
      value: #value               # This can be provided same as env field of container
  artifacts.taskrun.format: in-toto
  artifacts.taskrun.storage: tekton,oci (comma separated values)
  artifacts.taskrun.signer: x509
  artifacts.oci.storage: oci (comma separated values)
  artifacts.oci.format: simplesigning
  artifacts.oci.signer: x509
  artifacts.pipelinerun.format: in-toto
  artifacts.pipelinerun.storage: tekton,oci (comma separated values)
  artifacts.pipelinerun.signer: x509
  artifacts.pipelinerun.enable-deep-inspection: #value (boolean - true/false)
  storage.gcs.bucket: #value
  storage.oci.repository: #value
  storage.oci.repository.insecure: #value (boolean - true/false)
  storage.docdb.url: #value
  storage.docdb.mongo-server-url: #value
  storage.docdb.mongo-server-url-dir: #value
  storage.grafeas.projectid: #value
  storage.grafeas.noteid: #value
  storage.grafeas.notehint: #value
  builder.id: #value
  builddefinition.buildtype: #value
  signers.x509.fulcio.enabled: #value (boolean - true/false)
  signers.x509.fulcio.address: #value
  signers.x509.fulcio.issuer: #value
  signers.x509.fulcio.provider: #value
  signers.x509.identity.token.file: #value
  signers.x509.tuf.mirror.url: #value
  signers.kms.kmsref: #value
  signers.kms.auth.address: #value
  signers.kms.auth.token: #value
  signers.kms.auth.token-path: #value
  signers.kms.auth.oidc.path: #value
  signers.kms.auth.oidc.role: #value
  signers.kms.auth.spire.sock: #value
  signers.kms.auth.spire.audience: #value
  transparency.enabled: #value (boolean - true/false)
  transparency.url: #value

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Proxy Support

We have added the support for running the tekton components in a proxy environment through operator. This will enable running the tekton controllers, webhook and also taskrun pods with proxy configuration. We are attaching the proxy env variables like HTTP_PROXY, NO_PROXY and HTTPS_PROXY to the pods created through automation on the fly.

Note:

This funcationality will only be available for pods created using taskruns, not for all pods on clusters.

Proxy Support on Kubernetes

For enabling the proxy support on Kubernetes, users need to update the operator deployment with proxy environment variables like

spec:
  containers:
    - env:
        - name: HTTP_PROXY
          value: "url-to-be-pasted-here"

This will restart the operator pod, ending up in proxy environment variables attached to all components pods. Also whenever you run a taskrun, the resulting pod will also be having the environment variables in all containers.

This functionality of adding proxy environment variables is not available on taskruns created in tekton-pipelines namespace.

Proxy Support on OpenShift

For enabling proxy support on OpenShift environment, configure the proxy environments on OpenShift like mentioned here. After that install the operator through Operator Hub, and proxy environment variables will be available in tekton component’s controllers and webhook pod, also all taskrun pods created will also have the these environments

By default, openshift-pipelines namespace is exempted from adding the proxy environment varaibles in taskrun pods

Configuring namespace to be exempted from proxy environment feature

By default, the automation of adding proxy environment variables to taskrun pod is available on all namespace except the namespace in which tekton components are installed.

If you want to disable this feature in any other namespace, you can update the namespace object with following label

operator.tekton.dev/disable-proxy: true

Support for certificates for HTTPS proxy

TBD

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

OpenShiftPipelinesAsCode

OpenShiftPipelinesAsCode custom resource allows the user to install and manage OpenShift PipelinesAsCode.

It is recommended that you install OpenShiftPipelinesAsCode through TektonConfig.

OpenShiftPipelinesAsCode CR is as below

On OpenShift, OpenShiftPipelinesAsCode CR is as below:

apiVersion: operator.tekton.dev/v1alpha1
kind: OpenShiftPipelinesAsCode
metadata:
  name: pipelines-as-code
spec:
  additionalPACControllers:
    controllername:
      enable: true
      configMapName:
      secretName:
      settings:
  enable: true
  settings:
    application-name: Pipelines as Code CI
    auto-configure-new-github-repo: "false"
    bitbucket-cloud-check-source-ip: "true"
    custom-console-name: ""
    custom-console-url: ""
    custom-console-url-pr-details: ""
    custom-console-url-pr-tasklog: ""
    error-detection-from-container-logs: "false"
    error-detection-max-number-of-lines: "50"
    error-detection-simple-regexp: ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+):([
      ]*)?(?P<error>.*)
    error-log-snippet: "true"
    hub-catalog-name: tekton
    hub-url: https://api.hub.tekton.dev/v1
    remote-tasks: "true"
    secret-auto-create: "true"
    secret-github-app-token-scoped: "true"
  targetNamespace: openshift-pipelines

Check the status of the installation using following command:
```
kubectl get openshiftpipelinesascodes.operator.tekton.dev
```

PipelinesAsCode Config

The recommended way to update the OpenShiftPipelinesAsCode CR is using TektonConfig CR.

Properties (Mandatory)

targetNamespace

Set this field to provide the namespace in which you want to install the PipelinesAsCode component.

Properties (Optional)

The fields have default values so even if the user has not passed them in CR, operator will add them. The user can later change them as per their need.

Details of the field can be found in OpenShift Pipelines As Code Settings

Additional Pipelines As Controller (Optional)

If users want to deploy additional Pipelines As Code controller on their cluster along with default Pipelines As Code controller then they need to provide the additionalPACControllers field in the pipelinesAsCode section.

Example:

pipelinesAsCode:
  additionalPACControllers: # can provide a list of controllers
    <controllername>: 
      enable:
      configMapName:
      secretName:
      settings:

controllername is the unique name of the new controller, should not be more than 25 characters and should follow k8s naming rules.
enable is optional with default value to true. You can use this field to disable the additional PAC controller without removing the details from the CR.
configMapName is optional and is to provide the ConfigMap name of additional PAC Controller. If user doesn’t provide any value then Operator will add controllerName + -pipelines-as-code-configmap as default value. If user provides configMap name as pipelines-as-code for additional Pipelines As Code controller, then operator will not create the configMap and the default pipeline-as-code configMap will be used with default settings.
secretName is optional and is to provide the secret name of additional PAC Controller. If user does not provide any value then operator will add controllerName + -pipelines-as-code-secret as default value to be added to deployment env.
settings is optional and used to set the settings in the configMap of additional PAC Controller. For the fields whose are not provided, default value will be used. You can check them here. Also, if configmap name is provided as pipelines-as-code then these settings will not be taken.

NOTE: Users can deploy multiple additional PAC Controller by providing multiple entries in additionalPACControllers field.

Example:

pipelinesAsCode:
  additionalPACControllers:
    firstcontroller:
      enable: true
    secondcontroller:
      enable: true
      configMapName: second-config
      secretName: second-secret

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Configuring SCC used for Tekton workloads in OpenShift

Security Context Constraints (SCCs) are used to control permissions for pods in a cluster.

By default, the operator uses a custom SCC called pipelines-scc for all Tekton workloads run on OpenShift. pipelines-scc is primarily derived from the anyuid SCC which allows users to run with any UID and GID, and hence is not ideal for some, if not most users given the relaxed permissions allotted to all workloads. Besides, pipelines-scc also allows SETFCAP Linux capability to be requested by workloads. Historically, these relaxed permissions were provided to all Tekton workloads to support use cases like building container images via Tekton.

This document describes how to configure the default SCC and other SCC related configurations to better suit user’s Tekton workloads.

How to change SCC applied to Tekton workloads

Internally, the operator creates a service account (SA) named pipeline and attaches pipelines-scc to it by default. The pipeline SA is attached to all Tekton workloads by the operator and this is how the permissions percolate from the attached SCC to the workload pods.

Now the users can attach a different SA to their workloads as well and hence pipelines-scc will not take effect for those workloads, instead the SCC attached to that SA will take effect.

Configure default and maximum allowed SCC via TektonConfig

Note: Before we look at how to configure default SCC via the operator, it’s worth noting that this feature makes it convenient for users to configure default SCC but it does not restrict users from attaching a different SCC via a different SA to their workloads - and this different SCC could be more restrictive or permissive than the default SCC. So, setting the default SCC should not be considered a security control that prohibits users from applying a different SCC to their Tekton workloads, instead it’s just a way to specify default SCC applied by the operator.

To understand how to configure a default and maximum allowed SCC, let’s look at an example TektonConfig configuration.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  ...
  ...
  platforms:
    openshift:
      scc:
        default: "restricted-v2"
        maxAllowed: "privileged"

spec.platforms.openshift.scc.default specifies the default SCC that will be attached to the service account used for workloads (pipeline SA by default)
spec.platforms.openshift.scc.maxAllowed specifies the highest SCC that can be requested for in any namespace

Note that the SCC specified in default field cannot be of a higher priority than the one specified in maxAllowed field.

How are SCCs compared

OpenShift uses a prioritization logic to compare and sort SCCs from most restrictive to least restrictive. More on this can be read here.

Configuring default SCC for a specific namespace

If users wish to configure a different SCC for Tekton workloads to be run in a particular namespace, they can do so by adding the annotation operator.tekton.dev/scc: <SCC name> to their namespace.

Example:

apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace
  annotations:
    operator.tekton.dev/scc: nonroot

In this example, in the namespace test-namespace all the Tekton workload pods will have the effective SCC as nonroot irrespective of the default SCC set in TektonConfig.

A use case for specifying a different SCC for a given namespace could be building containers with Tekton. Building containers with, say, buildah in Tekton needs elevated privileges like running as root and elevated Linux capabilities. Users can request for anyuid SCC in one namespace without impacting permissions of Tekton workloads running in other namespaces.

Note: The SCC requested by the operator.tekton.dev/scc can not have a higher priority than the one specified in TektonConfig.Spec.Platforms.OpenShift. SCC.MaxAllowed field.

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Installing Tekton Operator

To configure images from a custom registry, follow the Air Gap Configuration guide.

Install operator

$ kubectl apply -f https://storage.googleapis.com/tekton-releases/operator/latest/release.yaml

Note: This will also install pipelines, triggers, chains, and dashboard

In case you want to install other components, use available installation profiles: lite , all, basic

Where

Platform	Profile	Installed Component
Kubernetes, OpenShift	lite	Pipeline
Kubernetes, OpenShift	basic	Pipeline, Trigger, Chains
Kubernetes	all	Pipeline, Trigger, Chains, Dashboard
OpenShift	all	Pipeline, Trigger, Chains, Pipelines as Code, Addons

To install pipelines, triggers, chains and dashboard (use profile ‘all’)

$ kubectl apply -f https://raw.githubusercontent.com/tektoncd/operator/main/config/crs/kubernetes/config/all/operator_v1alpha1_config_cr.yaml

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Air Gap environment (aka disconnected environment)

When we have our cluster on a air gap or proxy environment, we need to copy the actual images into our custom registry and update image details via environment variables on the operator deployment under the container tekton-operator-lifecycle as follows, This will allow us to use images from our custom registry.

Sample: images as environment variable in operator deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tekton-operator
  namespace: tekton-operator
spec:
  template:
    spec:
      containers:
        - name: tekton-operator-lifecycle
          env:
            - name: IMAGE_DASHBOARD_TEKTON_DASHBOARD
              value: custom-example.com/tektoncd/dashboard:v0.48.0
            - name: IMAGE_JOB_PRUNER_TKN
              value: custom-example.com/tektoncd/tkn:v0.31.0

List of image environment variables

Images supported in kubernetes

Component	Container/Args name	Environment Variable
Chains	tekton-chains-controller	`IMAGE_CHAINS_TEKTON_CHAINS_CONTROLLER`
Dashboard	tekton-dashboard	`IMAGE_DASHBOARD_TEKTON_DASHBOARD`
Hub	tekton-hub-api	`IMAGE_HUB_TEKTON_HUB_API`
Hub	tekton-hub-db	`IMAGE_HUB_TEKTON_HUB_DB`
Hub	tekton-hub-db-migration	`IMAGE_HUB_TEKTON_HUB_DB_MIGRATION`
Hub	tekton-hub-ui	`IMAGE_HUB_TEKTON_HUB_UI`
Manual Approval Gate	manual-approval	`IMAGE_MAG_MANUAL_APPROVAL`
Manual Approval Gate	tekton-taskgroup-controller	`IMAGE_MAG_TEKTON_TASKGROUP_CONTROLLER`
Pipeline	arg:entrypoint-image	`IMAGE_PIPELINES_ARG__ENTRYPOINT_IMAGE`
Pipeline	arg:git-image	`IMAGE_PIPELINES_ARG__GIT_IMAGE`
Pipeline	arg:nop-image	`IMAGE_PIPELINES_ARG__NOP_IMAGE`
Pipeline	arg:shell-image	`IMAGE_PIPELINES_ARG__SHELL_IMAGE`
Pipeline	arg:shell-image-win	`IMAGE_PIPELINES_ARG__SHELL_IMAGE_WIN`
Pipeline	arg:workingdirinit-image	`IMAGE_PIPELINES_ARG__WORKINGDIRINIT_IMAGE`
Pipeline	controller	`IMAGE_PIPELINES_CONTROLLER`
Pipeline	tekton-events-controller	`IMAGE_PIPELINES_TEKTON_EVENTS_CONTROLLER`
Pipeline	tekton-pipelines-controller	`IMAGE_PIPELINES_TEKTON_PIPELINES_CONTROLLER`
Pipeline	webhook	`IMAGE_PIPELINES_WEBHOOK`
Results	api	`IMAGE_RESULTS_API`
Results	postgres	`IMAGE_RESULTS_POSTGRES`
Results	watcher	`IMAGE_RESULTS_WATCHER`
Triggers	arg:el-image	`IMAGE_TRIGGERS_ARG__EL_IMAGE`
Triggers	tekton-triggers-controller	`IMAGE_TRIGGERS_TEKTON_TRIGGERS_CONTROLLER`
Triggers	tekton-triggers-core-interceptors	`IMAGE_TRIGGERS_TEKTON_TRIGGERS_CORE_INTERCEPTORS`
Triggers	webhook	`IMAGE_TRIGGERS_WEBHOOK`
Pipelines Proxy	webhook Proxy image	`IMAGE_PIPELINES_PROXY`
Pruner CronJob	image used in pruner cronJob	`IMAGE_JOB_PRUNER_TKN`

Images supported in OpenShift

Supports all the images listed above in kubernetes and following are specific to OpenShift

Component	Container/Args name	Environment Variable
Pipeline-as-code	pac-controller	`IMAGE_PAC_PAC_CONTROLLER`
Pipeline-as-code	pac-webhook	`IMAGE_PAC_PAC_WEBHOOK`
Pipeline-as-code	pac-watcher	`IMAGE_PAC_PAC_WATCHER`
Console Plugin	console-plugin	`IMAGE_PIPELINES_CONSOLE_PLUGIN`
Results	retention-policy-agent	`IMAGE_RESULTS_RETENTION_POLICY_AGENT`
Addons		`IMAGE_ADDONS_BUILD`
Addons		`IMAGE_ADDONS_GENERATE`
Addons		`IMAGE_ADDONS_GEN_ENV_FILE`
Addons		`IMAGE_ADDONS_GIT_RUN`
Addons		`IMAGE_ADDONS_KN`
Addons		`IMAGE_ADDONS_LOAD_SCRIPTS`
Addons		`IMAGE_ADDONS_MAVEN_GENERATE`
Addons		`IMAGE_ADDONS_MAVEN_GOALS`
Addons		`IMAGE_ADDONS_MVN_SETTINGS`
Addons		`IMAGE_ADDONS_OC`
Addons		`IMAGE_ADDONS_PARAM_BUILDER_IMAGE`
Addons		`IMAGE_ADDONS_PARAM_GITINITIMAGE`
Addons		`IMAGE_ADDONS_PARAM_KN_IMAGE`
Addons		`IMAGE_ADDONS_PARAM_MAVEN_IMAGE`
Addons		`IMAGE_ADDONS_PARAM_TKN_IMAGE`
Addons		`IMAGE_ADDONS_PREPARE`
Addons		`IMAGE_ADDONS_REPORT`
Addons		`IMAGE_ADDONS_S2I_BUILD`
Addons		`IMAGE_ADDONS_S2I_GENERATE`
Addons		`IMAGE_ADDONS_SKOPEO_COPY`
Addons		`IMAGE_ADDONS_SKOPEO_RESULTS`
Addons		`IMAGE_ADDONS_TKN`
Addons		`IMAGE_ADDONS_TKN_CLI_SERVE`
Addons		`IMAGE_ADDONS_PREPARE_AND_RUN`

Vault:

Mon, 01 Jan 0001 00:00:00 +0000

Tekton Hub

TektonHub custom resource allows user to install and manage Tekton Hub.

TektonHub is an optional component and currently cannot be installed through TektonConfig. It has to be installed seperately. It is available for both Kubernetes and OpenShift platform.

To install Tekton Hub on your cluster follow steps as given below:

Note :

Initially user had to enable Tekton Hub Authentication, get the Hub token with required scopes and then hit the catalog refresh api to load the resources in the database.
Now user doesn’t needs to enable login mechanism to get the resources populated in the database as resources will be automatically populated in the database when the api is up and running
Resources in the hub db will be also automatically refreshed with the updated data with the time which is specified in the Hub CR i.e catalogRefreshInterval: 30m. Default time interval is 30m
If you are using your database instead of default one then secret name for the database should be tekton-hub-db and you need to create the secret in your targetNamespace with the following keys
The dependency of config.yaml from git is removed and complete config data is moved into API configMap. Now user can add the config data i.e. categories, catalogs, scopes and defaultScopes in the Hub CR itself. If user does not add any data then default data provided by Hub in the API configMap will be used

apiVersion: v1
kind: Secret
metadata:
  name: tekton-hub-db
  labels:
    app: tekton-hub-db
type: Opaque
stringData:
  POSTGRES_HOST: <The name of the host of the database>
  POSTGRES_DB: <Name of the database>
  POSTGRES_USER: <The name of user account>
  POSTGRES_PASSWORD: <The password of user account>
  POSTGRES_PORT: <The port that the database is listening on>

This is how TektonHub CR looks

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace:
  # <namespace> in which you want to install Tekton Hub. Leave it blank if in case you want to install
  # in default installation namespace ie `openshift-pipelines` in case of OpenShift and `tekton-pipelines` in case of Kubernetes
  db:                      # 👈 Optional: If user wants to use his database
    secret: tekton-hub-db  # 👈 Name of db secret should be `tekton-hub-db`

  categories:                     # 👈 Optional: If user wants to use his categories 
    - Automation
    - Build Tools
    - CLI
    - Cloud
    - Code Quality
    - ...

  catalogs:                       # 👈 Optional: If user wants to use his catalogs
    - name: tekton
      org: tektoncd
      type: community
      provider: github
      url: https://github.com/tektoncd/catalog
      revision: main

  scopes:                         # 👈 Optional: User can define his scopes  
    - name: agent:create
      users: [abc, qwe, pqr]
    - name: catalog:refresh
      users: [abc, qwe, pqr]
    - name: config:refresh
      users: [abc, qwe, pqr]

  default:                       # 👈 Optional: User can define his default scopes
    scopes:
      - rating:read
      - rating:write

  api:
    catalogRefreshInterval: 30m     # After every 30min catalog resources in the hub db would be refreshed to get the updated data from the catalog. Supported time units are As(A seconds), Bm(B minutes) Ch(C hours), Dd(D days) and Ew(E weeks).

You can install Tekton Hub by running the command
```
kubectl apply -f <name>.yaml
```

Check the status of installation using following command

$ kubectl get tektonhub.operator.tekton.dev
NAME   VERSION   READY   REASON   APIURL                  UIURL
hub    v1.8.0    True             https://api.route.url   https://ui.route.url

Create the secrets for the API before we install Tekton Hub. By default, Tekton Hub expects this secret to have the following properties:
- namespace: TargetNamespace defined in TektonHub CR at the time of applying. If nothing is specified then based on platform create the secrets. openshift-pipelines in case of OpenShift, tekton-pipelines in case of Kubernetes.
- name: tekton-hub-api
- contains the fields:
  - GH_CLIENT_ID=<github-client-id>
  - GH_CLIENT_SECRET=<github-client-secret>
  - GL_CLIENT_ID=<gitlab-client-id>
  - GL_CLIENT_SECRET=<gitlab-client-secret>
  - BB_CLIENT_ID=<bitbucket-client-id>
  - BB_CLIENT_SECRET=<bitbucket-client-secret>
  - JWT_SIGNING_KEY=<jwt-signing-key>
  - ACCESS_JWT_EXPIRES_IN=<time(eg 30d)>
  - REFRESH_JWT_EXPIRES_IN=<time(eg 30d)>
  - GHE_URL=<github enterprise url(leave it blank if not using github enterprise>
  - GLE_URL=<gitlab enterprise url(leave it blank if not using gitlab enterprise>
Note 1: For more details please refer to here

Once the secrets are created now we need to understand how TektonHub CR looks.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace:
  # <namespace> in which you want to install Tekton Hub. Leave it blank if in case you want to install
  # in default installation namespace ie `openshift-pipelines` in case of OpenShift and `tekton-pipelines` in case of Kubernetes
  db:                      # 👈 Optional: If user wants to use his database
    secret: tekton-hub-db  # 👈 Name of db secret should be `tekton-hub-db`

  categories:                     # 👈 Optional: If user wants to use his categories 
    - Automation
    - Build Tools
    - CLI
    - Cloud
    - Code Quality
    - ...

  catalogs:                       # 👈 Optional: If user wants to use his catalogs
    - name: tekton
      org: tektoncd
      type: community
      provider: github
      url: https://github.com/tektoncd/catalog
      revision: main

  scopes:                         # 👈 Optional: User can define his scopes 
    - name: agent:create
      users: [abc, qwe, pqr]
    - name: catalog:refresh
      users: [abc, qwe, pqr]
    - name: config:refresh
      users: [abc, qwe, pqr]

  default:                       # 👈 Optional: User can define his default scopes
    scopes:
      - rating:read
      - rating:write

  api:
    catalogRefreshInterval: 30m     # After every 30min catalog resources in the hub db would be refreshed to get the updated data from the catalog. Supported time units are As(A seconds), Bm(B minutes) Ch(C hours), Dd(D days) and Ew(E weeks).

After configuring the TektonHub spec you can install Tekton Hub by running the command
```
kubectl apply -f <name>.yaml
```

Check the status of installation using following command

$ kubectl get tektonhub.operator.tekton.dev
NAME   VERSION   READY   REASON   APIURL                  UIURL
hub    v1.6.0    True             https://api.route.url   https://ui.route.url

Tekton – Operator

Vault:

Tekton Config

Target Namespace

Target Namespace Metadata

Profile

Config

Pipeline

Chain

Pruner

Note:

Pruner Namespace annotations

Note:

Addon

Hub

Dashboard

Resolvers

OpenShiftPipelinesAsCode

Additional fields as options

ConfigMaps

Deployments

StatefulSets

HorizontalPodAutoscalers

webhookConfigurationOptions

Vault:

Tekton Pipeline

Properties

Metrics Properties

Optional Properties

Performance Properties

Note:

Vault:

Tekton Trigger

Vault:

Tekton Dashboard

Properties

Vault:

Tekton Result

Spec

Property “secret_name”:

Sample Secret File

GCS specific Property

External DB

LokiStack + TektonResult

Kubernetes (GCP) + LokiStack/Loki

Loki

Forwarder

OpenShift (LokiStack + OpenShift Logging)

OpenShift Logging

Vault:

Tekton Addon

Params

Vault:

Manual Approval Gate

Vault:

Tekton Chain

Chain Config

Properties (Mandatory)

Properties (Optional)

Vault:

Proxy Support

Proxy Support on Kubernetes

Proxy Support on OpenShift

Configuring namespace to be exempted from proxy environment feature

Support for certificates for HTTPS proxy

Vault:

OpenShiftPipelinesAsCode

PipelinesAsCode Config

Properties (Mandatory)

Properties (Optional)

Additional Pipelines As Controller (Optional)

Vault:

Configuring SCC used for Tekton workloads in OpenShift

How to change SCC applied to Tekton workloads

Configure default and maximum allowed SCC via TektonConfig

How are SCCs compared

Configuring default SCC for a specific namespace

Vault:

Installing Tekton Operator

Vault:

Additional fields as `options`