Tekton – Dashboard

Vault: Getting started with Tekton Dashboard

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

This tutorial shows you how to

Create a Kubernetes cluster with minikube
Install Tekton Pipelines and Tekton Dashboard
Import some Tekton resources
Create a TaskRun and monitor its logs
Create a PipelineRun and monitor its logs

[!CAUTION] This tutorial describes setting Dashboard up in READ-WRITE mode.

Anyone who can access the Dashboard can use the permissions granted to the service account. Make sure to take additional precautions if your deployment is publicly accessible.

READ-WRITE mode is not a requirement for Dashboard to operate, and can be installed in READ-ONLY mode.

Prerequisites

Install minikube. You only have to complete the step 1, “Installation”.
Install kubectl

Create your Kubernetes cluster

Create a cluster

minikube start --profile tekton-dashboard-tutorial

The process takes a few seconds, you see an output similar to the following, depending on the minikube driver that you are using:

😄  [tekton-dashboard-tutorial] minikube v1.25.2
✨  Using the docker driver based on existing profile
👍  Starting control plane node tekton-dashboard-tutorial in cluster tekton-dashboard-tutorial
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=3886MB) ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "tekton-dashboard-tutorial" cluster and "default" namespace by default

You can check that the cluster was successfully created with kubectl:

kubectl cluster-info

The output confirms that Kubernetes is running:

Kubernetes control plane is running at https://127.0.0.1:39509
CoreDNS is running at
https://127.0.0.1:39509/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Install Tekton Pipelines

To install the latest version of Tekton Pipelines, use kubectl:

kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/pipeline/latest/release.yaml

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Install Tekton Dashboard

To install the latest version of Tekton Dashboard, use kubectl:
```
kubectl apply --filename \
https://infra.tekton.dev/tekton-releases/dashboard/latest/release-full.yaml
```
NOTE: release-full.yaml installs dashboard in READ-WRITE mode.

Monitor the installation:

kubectl get pods --namespace tekton-pipelines --watch

When all components show Running under the STATUS column the installation is complete.

Hit Ctrl + C to stop monitoring.

Access Tekton Dashboard

The Tekton Dashboard is not exposed outside the cluster by default, but we can access it by port-forwarding to the tekton-dashboard Service on port 9097.

kubectl port-forward -n tekton-pipelines service/tekton-dashboard 9097:9097

You can now open the Dashboard in your browser at http://localhost:9097

Grant permissions

The import must be executed using a ServiceAccount with permissions to create the resources being imported.

For this tutorial we will create a ClusterRole granting permission to create a number of Tekton resources, and a RoleBinding configuring this so that the default ServiceAccount in the tekton-dashboard namespace can create resources in the default namespace.

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: tekton-dashboard-tutorial
rules:
  - apiGroups:
      - tekton.dev
    resources:
      - tasks
      - taskruns
      - pipelines
      - pipelineruns
    verbs:
      - get
      - create
      - update
      - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-dashboard-tutorial
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-dashboard-tutorial
subjects:
  - kind: ServiceAccount
    name: default
    namespace: tekton-dashboard
EOF

Import some Tekton resources using the Tekton Dashboard

We will import two simple Tasks and a Pipeline definition to demonstrate some of the features of the Dashboard.

Navigate to the ‘Import resources’ page in the Dashboard using the link in the main navigation
Fill in the form providing the following information:
- Repository URL: https://github.com/tektoncd/dashboard
- Repository path: docs/tutorial
- Target namespace: default
  - If selecting a different value, ensure the selected ServiceAccount has permission to create resources in this namespace
Leave the default values for the rest of the fields
Click the Import and Apply button

View the progress of the import

The Dashboard creates a PipelineRun to import the specified Tekton resources.

Click on the View status of this run link to track the status of importing the Tekton resources. Alternatively, navigate to the PipelineRuns page and click on the name of the run in the table.

The Tekton resources have been imported when the PipelineRun has completed successfully. You will see the following logs for the ‘import’ step:

pipeline.tekton.dev/hello-goodbye created
task.tekton.dev/hello created
task.tekton.dev/goodbye created

Step completed successfully

Create a TaskRun

Navigate to the TaskRuns page using the link in the main navigation

You will see the TaskRun that was created by the import process. Let’s create another TaskRun using one of the Task definitions we just imported.
Click the Create button and fill in the form as follows:
- Namespace: default
- Task: hello
Leave the default values for the rest of the fields
Click the Create button to create the TaskRun

Once the TaskRun is created you will be taken to the TaskRuns page. View the logs by clicking the TaskRun name in the table.

Wait until the TaskRun has completed successfully and you will see the following logs:

Hello World

Step completed successfully

Create a PipelineRun

Next let’s create a PipelineRun using all of the resources we imported.

Navigate to the PipelineRuns page by clicking the link in the main navigation
Click the Create button

The form is similar to the one we saw for TaskRuns. Both forms are dynamic and provide Param fields based on the selected Task / Pipeline.
Fill in the form with the following information:
- Namespace: default
- Pipeline: hello-goodbye
- Params > hello-greeting: Hello from the tutorial 😀
Leave the default values for the rest of the fields

Note: If you leave the hello-greeting field empty, the default value Hello from a Pipeline defined in the Pipeline will be used.
Click the Create button to create the PipelineRun

Once the PipelineRun is created you will be taken to the PipelineRuns page. View the logs by clicking the PipelineRun name in the table. On the PipelineRun details page you will see two TaskRuns, hello and goodbye, matching the Tasks defined in our Pipeline. Each of these has a step echo which displays a message in the logs.

The logs for the hello Task display the custom message we entered in the create form earlier.

Hello from the tutorial 😀

Step completed successfully

Cleanup

To delete the cluster that you created for this quickstart run:

minikube delete --profile tekton-dashboard-tutorial

The output confirms that your cluster was deleted:

🔥  Deleting "tekton-dashboard-tutorial" in docker ...
🔥  Deleting container "tekton-dashboard-tutorial" ...
🔥  Removing /home/user/.minikube/machines/tekton-dashboard-tutorial ...
💀  Removed all traces of the "tekton-dashboard-tutorial" cluster.

Vault:

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

Installing Tekton Dashboard

This guide explains how to install Tekton Dashboard. It covers the following topics:

Installing Tekton Dashboard

Before you begin

Choose the version of Tekton Dashboard you want to install. You have the following options:

Official - install this unless you have a specific reason to go for a different release.
Nightly - may contain bugs, install at your own risk.
[HEAD] - this is the bleeding edge. It contains unreleased code that may result in unpredictable behavior. To get started, see the development guide instead of this page.

Pre-requisites

In order to install the Tekton Dashboard, please make sure the following requirements are met:

You must have a Kubernetes cluster running version 1.28.0 or later. Tekton Pipelines or other projects may require a newer version. The Dashboard may work on older Kubernetes versions but this is untested and not officially supported.

If you don’t already have a cluster, you can create one for testing with kind. Install kind and create a cluster by running kind create cluster. This will create a cluster running locally, with RBAC enabled and your user granted the cluster-admin role.
Tekton Pipelines must be installed in the cluster. See Installing Tekton Pipelines.
Optionally, install Tekton Triggers. See Installing Tekton Triggers.

Supported Tekton Pipelines and Tekton Triggers versions

Each Tekton Dashboard release is tested against specific Tekton Pipelines and Tekton Triggers versions. See the Tekton Dashboard release notes for details of the supported versions.

Installing Tekton Dashboard on Kubernetes

To install Tekton Dashboard on a Kubernetes cluster:

Run the following command to install Tekton Dashboard:
```
kubectl apply --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml
```
This will install the Dashboard in read-only mode by default.

Previous versions are available at previous/$VERSION_NUMBER/*.yaml, e.g. https://infra.tekton.dev/tekton-releases/dashboard/previous/v0.32.0/release.yaml

To install in read/write mode, use release-full.yaml.

v0.31.0 and earlier used a different naming scheme for the release manifests:

Mode Current v0.31.0 and earlier

read-only release.yaml tekton-dashboard-release-readonly.yaml

read/write release-full.yaml tekton-dashboard-release.yaml
Monitor the installation using the following command until all components show a Running status:
```
kubectl get pods --namespace tekton-pipelines --watch
```
Note: Hit CTRL+C to stop monitoring.

Mode	Current	v0.31.0 and earlier
read-only	release.yaml	tekton-dashboard-release-readonly.yaml
read/write	release-full.yaml	tekton-dashboard-release.yaml

Congratulations! You have successfully installed Tekton Dashboard on your Kubernetes cluster.

Installing with the installer script

v0.8.0 and later releases provide an installer script to simplify deploying the Tekton Dashboard with custom options.

You can refer to the dev docs for more info on how to use the installer.

For example:

to install the latest release in read/write mode:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write

to install with access to a subset of namespaces instead of full cluster access:
```
curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --tenant-namespaces tenant-namespace1,tenant-namespace2
```
This will add the --namespaces arg to the Dashboard deployment and create RoleBindings in each of the specified namespaces with appropriate roles granted to the Dashboard ServiceAccount.

to install with support for loading logs from an external source:

curl -sL https://raw.githubusercontent.com/tektoncd/dashboard/main/scripts/release-installer | \
  bash -s -- install latest --read-write --external-logs <logs-provider-url>

See Tekton Dashboard walk-through - Logs persistence for details

Accessing the Dashboard

By default, the Dashboard is not exposed outside the cluster.

There are several solutions described below for accessing the Dashboard UI depending on your setup.

Using kubectl proxy

The Dashboard can be accessed through its ClusterIP Service by running kubectl proxy.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl proxy

Browse http://localhost:8001/api/v1/namespaces/tekton-pipelines/services/tekton-dashboard:http/proxy/ to access your Dashboard.

Using kubectl port-forward

An alternative way to access the Dashboard is using kubectl port-forward.

Assuming tekton-pipelines is the install namespace for the Dashboard, run the following command:

kubectl --namespace tekton-pipelines port-forward svc/tekton-dashboard 9097:9097

Browse http://localhost:9097 to access your Dashboard.

Using an Ingress rule

A more advanced solution is to expose the Dashboard through an Ingress rule.

This way the Dashboard can be accessed as a regular website without requiring kubectl.

Assuming you have an ingress controller up and running in your cluster, and that tekton-pipelines is the install namespace for the Dashboard, run the following command to create the Ingress resource:

# replace DASHBOARD_URL with the hostname you want for your dashboard
# the hostname should be setup to point to your ingress controller
DASHBOARD_URL=dashboard.domain.tld
kubectl apply -n tekton-pipelines -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
spec:
  rules:
  - host: $DASHBOARD_URL
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097
EOF

You can now access the Dashboard UI at http(s)://dashboard.domain.tld in your browser (assuming the host configured in the ingress is dashboard.domain.tld)

Notes:

The exact Ingress resource definition may vary a little depending on the ingress controller installed in the cluster. Some specific annotations may be required for the ingress controller to process the Ingress resource correctly
If you don’t have access to a domain you can use the freely available nip.io service

An example using the NGINX ingress controller to expose the Dashboard on a specific path instead of at the root of the domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: domain.tld
    http:
      paths:
      - path: /tekton(/|$)(.*)
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

You can then access the Dashboard UI at http(s)://domain.tld/tekton/

Access control

The Dashboard does not provide its own authentication or authorization, however it will pass on any authentication headers provided to it by a proxy deployed in front of the Dashboard. These are then handled by the Kubernetes API server allowing for full access control via Kubernetes RBAC. In case of forbidden access the Dashboard will display corresponding error notifications.

See the walk-throughs for an example of enabling authentication using oauth2-proxy.

By default the Dashboard accesses resources and performs actions in the cluster using the permissions granted to its own ServiceAccount (i.e. the tekton-dashboard ServiceAccount in the tekton-pipelines namespace). If you wish to have the Dashboard perform actions on behalf of the authenticated user or some other ServiceAccount this can be achieved via user impersonation. This is known to work with a number of popular solutions including oauth2-proxy, Keycloak, OpenUnison, Traefik, Istio’s EnvoyFilter, and more.

Typically when configuring impersonation you would have the proxy forward its ServiceAccount token in the Authorization header, and details of the user and groups in the Impersonate-User and Impersonate-Group headers respectively. See the docs of your chosen solution for details.

When using a reverse proxy, with impersonation headers or the user’s account, you should remove the Dashboard’s privileges to better maintain a “least privileged” approach. This will make it less likely that the Dashboard’s ServiceAccount will be abused:

kubectl delete clusterrolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard
kubectl delete rolebinding -l rbac.dashboard.tekton.dev/subject=tekton-dashboard -n tekton-pipelines

If you’re using one of these proxies to provide authentication but still want to use the Dashboard’s ServiceAccount to access the Kubernetes APIs you may need to modify the proxy config to prevent it from sending the Authorization header on upstream requests to the Dashboard. Some examples of relevant config:

oauth2-proxy: add the --pass-authorization-header=false command line argument or its equivalent to your config https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview#command-line-options
Istio EnvoyFilter: the external authentication service should return a custom header x-envoy-auth-headers-to-remove: Authorization https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto
Traefik: removeHeader: true https://doc.traefik.io/traefik/v2.0/middlewares/basicauth/#removeheader

Uninstalling the Dashboard on Kubernetes

The Dashboard can be uninstalled by running the following command:

kubectl delete --filename https://infra.tekton.dev/tekton-releases/dashboard/latest/release.yaml

The above command assumes that the current latest version was installed, refer to Installing Tekton Dashboard on Kubernetes to find the correct --filename argument if another version was installed.

Next steps

To get started with Tekton Dashboard, see the tutorial.

To add more functionality to your Tekton Dashboard, see the Tekton Dashboard extensions

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Vault:

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

Tekton Dashboard extensions

This guide explains what Tekton Dashboard extensions are and how to manage them. It covers the following topics:

Before you begin

Tekton Dashboard Extensions are currently alpha and are considered experimental. This means things could change at any time.

Resource based extensions

Resource based extensions provide a simple and easy way to list and view resources inside a cluster. They are deployed as Extension resources and the Dashboard will generate UI to display the chosen resources.

Using them requires two steps (see an example below):

create an Extension resource in your cluster
add RBAC rules to the Tekton Dashboard service account to allow it access to the target resources

See the Example: Register a CronJob extension below for a working example.

Extension CRD (apiVersion: dashboard.tekton.dev/v1alpha1)

Extension

Variable Name	Type	Required	Default	Description
	metav1.TypeMeta	Yes	-
metadata	metav1.ObjectMeta	No	-
spec	ExtensionSpec	Yes	-	Extension spec

ExtensionSpec

Variable Name	Type	Required	Default	Description
apiVersion	string	Yes	-	Extension resource group
name	string	Yes	-	Extension resource name
disableResourceDetailsLinks	boolean	No	false	Disable display of links to resource details pages
displayName	string	Yes	-	Display name in the Dashboard UI
namespaced	boolean	No	true	Specifies whether the Extension represents a namespaced resource

Example: Register a CronJob extension

To create an Extension resource for CronJobs run the following command:

kubectl apply -n tekton-pipelines -f - <<EOF
apiVersion: dashboard.tekton.dev/v1alpha1
kind: Extension
metadata:
  name: cronjobs
spec:
  apiVersion: batch/v1
  name: cronjobs
  displayName: k8s cronjobs
EOF

This adds a new item in the side nav of the Dashboard.

Clicking on it will show an error though, you need to allow the Tekton Dashboard service account to access cronjobs in your cluster. See next step to learn how you can easily extend RBAC rules of the service account.

Example: Extend Tekton Dashboard service account permissions

Extending the Tekton Dashboard service account can be done easily using ClusterRole aggregation. To support this method the Dashboard must be installed with the --extensions-rbac flag to ensure that the aggregationRule is correctly configured.

Create a ClusterRole with the necessary permissions and the label rbac.dashboard.tekton.dev/aggregate-to-dashboard: "true".

To add the necessary permissions for your cronjobs extension to work, run the following command:

kubectl apply -f - <<EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tekton-dashboard-cronjobs-extension
  labels:
    rbac.dashboard.tekton.dev/aggregate-to-dashboard: "true"
rules:
  - apiGroups: ["batch"]
    resources: ["cronjobs"]
    verbs: ["get", "list", "watch"]
EOF

Alternatively, if the --extensions-rbac is not used, omit the label from the ClusterRole, and define the appropriate RoleBinding or ClusterRoleBinding yourself with the subject set to the tekton-dashboard service account.

Now the Tekton Dashboard will show CronJobs in your cluster.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Vault:

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

Tekton Dashboard log viewer

This guide describes the features and functionality of the log viewer provided by the Tekton Dashboard on the TaskRun and PipelineRun details pages.

Basic functionality

The Tekton Dashboard log viewer supports ANSI colour codes and text styles, and will automatically detect URLs in log content and render them as clickable links opening in a new window.

The toolbar displayed in the log viewer includes a number of additional features, including:

maximize: increase the area available to the log viewer by hiding the task list and run header. This allows the user to eliminate distractions from other parts of the app and focus on the log content.
open in new window: open the raw logs in a separate browser window. This provides an unmodified and unprocessed view of the logs, without any of the added features provided by the log viewer.
download: download the raw logs as a text file.
user preferences: these are persisted to browser local storage and applied to all logs in the app. See the following sections for more details.

Timestamps

The Dashboard will always request logs with timestamps from the Kubernetes pod logs API, and show / hide the timestamps in the log viewer based on the user’s preference. This can be toggled from the settings menu in the toolbar at the top of the log viewer.

The timestamps are localised based on the user’s browser settings, with the raw timestamp value received from the API provided as a tooltip on hover.

In releases prior to Tekton Dashboard v0.54, the timestamp preference was found on the Settings page, and governed whether or not timestamps were requested from the Kubernetes API server.

Log levels

The log viewer parses log lines to detect the associated log level and decorate them accordingly to help with log consumability. The format supported is described below.

<timestamp> ::<level>::<message>

timestamp is provided by the Kubernetes API server
level is one of error, warning, notice, info, debug, trace
- debug and trace logs are hidden by default
- any log line without an explicit level is considered as info, but will not display the log level badge to avoid redundancy in the UI where users are not using the supported log format
message is any other content on the line, and may contain ANSI codes for formatting, etc.

For example, the following snippet would output a log line at the warning level:

echo ':⚠️:Something that may require attention but is non-blocking…'

The displayed log levels can be changed via the settings menu in the toolbar at the top of the log viewer.

Log groups

In addition to log levels, the log viewer also supports collapsible groups within the logs. The format supported is described below.

<timestamp> ::group::<message>
…
<timestamp> ::endgroup::

A group command marks the beginning of the group. The content of message is displayed as the title / summary of the group along with an indicator of the group’s current state (i.e. expanded or collapsed). Clicking the summary will toggle the state of the group.

Groups are rendered in the collapsed state by default unless the step is still in progress when the logs are viewed. The user can expand or collapse groups as desired and their state will be maintained until the user navigates to a different view.

Log groups cannot be mixed with log levels on the same line, the group, endgroup, and log level commands are mutually exclusive. However, logs contained within a group can use log levels as normal.

Nesting groups is not supported. A group command will implicitly terminate any prior unterminated group.

For example, the following snippet would output a log group with the summary ‘Additional config’ containing a number of messages at the info level:

echo '::group::Additional config'
echo 'This extends the base config'
echo '::info:: More info about the config…'
echo '::endgroup::'

Logs persistence

By default, Tekton Dashboard loads the logs from the Kubernetes API server, using the pod logs API. However, it also supports loading logs from an external source when the container logs or the pods associated with the TaskRuns are no longer available on the cluster.

This functionality is described in detail, along with a full walk-through of an example configuration, in Tekton Dashboard walk-through - Logs persistence.

It can be enabled by providing the --external-logs flag to the installer script, or configured directly in the Dashboard deployment’s args.

When configured, the Dashboard will first attempt to load pod logs normally, and if they’re unavailable will fallback to the provided external logs service by making a GET request to the provided endpoint with the following format:

GET <external-logs>/<namespace>/<podName>/<container>?startTime=<stepStartTime>&completionTime=<stepCompletionTime>

namespace: the namespace containing the run
podName: the name of the Pod resource associated with the selected TaskRun
container: the name of the container associated with the selected step
stepStartTime: the start time of the step container
stepCompletionTime: the completion time of the step container

If the start / completion times are unavailable their respective query parameters will be omitted from the request.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License. Code samples are licensed under the Apache 2.0 License.

Tekton – Dashboard

Vault: Getting started with Tekton Dashboard

Prerequisites

Create your Kubernetes cluster

Install Tekton Pipelines

Install Tekton Dashboard

Access Tekton Dashboard

Grant permissions

Import some Tekton resources using the Tekton Dashboard

View the progress of the import

Create a TaskRun

Create a PipelineRun

Cleanup

Further reading

Vault:

Installing Tekton Dashboard

Before you begin

Pre-requisites

Supported Tekton Pipelines and Tekton Triggers versions

Installing Tekton Dashboard on Kubernetes

Installing with the installer script

Accessing the Dashboard

Using kubectl proxy

Using kubectl port-forward

Using an Ingress rule

Access control

Uninstalling the Dashboard on Kubernetes

Next steps

Vault:

Tekton Dashboard extensions

Before you begin

Resource based extensions

Extension CRD (apiVersion: dashboard.tekton.dev/v1alpha1)

Extension

ExtensionSpec

Example: Register a CronJob extension

Example: Extend Tekton Dashboard service account permissions

Vault:

Tekton Dashboard log viewer

Basic functionality

Toolbar

Timestamps

Log levels

Log groups

Logs persistence