apiVersion: operator.tekton.dev/v1alpha1
kind: TektonChain
metadata:
name: chain
spec:
targetNamespace: openshift-pipelines
Tekton Chains is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/. |
Tekton Chains is a Kubernetes Custom Resource Definition (CRD) controller. You can use it to manage the supply chain security of the tasks and pipelines created using Red Hat OpenShift Pipelines.
By default, Tekton Chains observes all task run executions in your OpenShift Container Platform cluster. When the task runs complete, Tekton Chains takes a snapshot of the task runs. It then converts the snapshot to one or more standard payload formats, and finally signs and stores all artifacts.
To capture information about task runs, Tekton Chains uses the Result
and PipelineResource
objects. When the objects are unavailable, Tekton Chains the URLs and qualified digests of the OCI images.
The |
You can sign task runs, task run results, and OCI registry images with cryptographic key types and services such as cosign
.
You can use attestation formats such as in-toto
.
You can securely store signatures and signed artifacts using OCI repository as a storage backend.
Cluster administrators can use the TektonChain
custom resource (CR) to install and manage Tekton Chains.
Tekton Chains is an optional component of Red Hat OpenShift Pipelines. Currently, you cannot install it using the |
Ensure that the Red Hat OpenShift Pipelines Operator is installed in the openshift-pipelines
namespace on your cluster.
Create the TektonChain
CR for your OpenShift Container Platform cluster.
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonChain
metadata:
name: chain
spec:
targetNamespace: openshift-pipelines
Apply the TektonChain
CR.
$ oc apply -f TektonChain.yaml (1)
1 | Substitute with the file name of the TektonChain CR. |
Check the status of the installation.
$ oc get tektonchains.operator.tekton.dev
Tekton Chains uses a ConfigMap
object named chains-config
in the openshift-pipelines
namespace for configuration.
To configure Tekton Chains, use the following example:
$ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.oci.storage": "", "artifacts.taskrun.format":"tekton", "artifacts.taskrun.storage": "tekton"}}' (1)
1 | Use a combination of supported key-value pairs in the JSON payload. |
Cluster administrators can use various supported keys and values to configure specifications about task runs, OCI images, and storage.
Supported keys | Description | Supported values | Default values |
---|---|---|---|
|
The format to store task run payloads. |
|
|
|
The storage backend for task run signatures. You can specify multiple backends as a comma-separated list, such as |
|
|
|
The signature backend to sign task run payloads. |
|
|
Supported keys | Description | Supported values | Default values |
---|---|---|---|
|
The format to store OCI payloads. |
|
|
|
The storage backend to for OCI signatures. You can specify multiple backends as a comma-separated list, such as |
|
|
|
The signature backend to sign OCI payloads. |
|
|
Supported keys | Description | Supported values | Default values |
---|---|---|---|
|
The OCI repository to store OCI signatures. |
Currently, Chains support only the internal OpenShift OCI registry; other popular options such as Quay is not supported. |
Cluster administrators can generate a key pair and use Tekton Chains to sign artifacts using a Kubernetes secret. For Tekton Chains to work, a private key and a password for encrypted keys must exist as part of the signing-secrets
Kubernetes secret, in the openshift-pipelines
namespace.
Currently, Tekton Chains supports the x509
and cosign
signature schemes.
Use only one of the supported signature schemes. |
To use the x509
signing scheme with Tekton Chains, store the x509.pem
private key of the ed25519
or ecdsa
type in the signing-secrets
Kubernetes secret. Ensure that the key is stored as an unencrypted PKCS8 PEM file (BEGIN PRIVATE KEY
).
To use the cosign
signing scheme with Tekton Chains:
Install cosign.
Generate the cosign.key
and cosign.pub
key pairs.
$ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
Cosign prompts you for a password, and creates a Kubernetes secret.
Store the encrypted cosign.key
private key and the cosign.password
decryption password in the signing-secrets
Kubernetes secret. Ensure that the private key is stored as an encrypted PEM file of the ENCRYPTED COSIGN PRIVATE KEY
type.
If the signing secrets are already populated, you might get the following error:
Error from server (AlreadyExists): secrets "signing-secrets" already exists
To resolve the error:
Delete the secrets:
$ oc delete secret signing-secrets -n openshift-pipelines
Recreate the key pairs and store them in the secrets using your preferred signing scheme.
Before pushing signatures to an OCI registry, cluster administrators must configure Tekton Chains to authenticate with the registry. The Tekton Chains controller uses the same service account under which the task runs execute. To set up a service account with the necessary credentials for pushing signatures to an OCI registry, perform the following steps:
Set the namespace and name of the Kubernetes service account.
$ export NAMESPACE=<namespace> (1)
$ export SERVICE_ACCOUNT_NAME=<service_account> (2)
1 | The namespace associated with the service account. |
2 | The name of the service account. |
Create a Kubernetes secret.
$ oc create secret registry-credentials \
--from-file=.dockerconfigjson \ (1)
--type=kubernetes.io/dockerconfigjson \
-n $NAMESPACE
1 | Substitute with the path to your Docker config file. Default path is ~/.docker/config.json . |
Give the service account access to the secret.
$ oc patch serviceaccount $SERVICE_ACCOUNT_NAME \
-p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE
If you patch the default pipeline
service account that Red Hat OpenShift Pipelines assigns to all task runs, the Red Hat OpenShift Pipelines Operator will override the service account. As a best practice, you can perform the following steps:
Create a separate service account to assign to user’s task runs.
$ oc create serviceaccount <service_account_name>
Associate the service account to the task runs by setting the value of the serviceaccountname
field in the task run template.
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: build-push-task-run-2
spec:
serviceAccountName: build-bot (1)
taskRef:
name: build-push
...
1 | Substitute with the name of the newly created service account. |