You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is probably the most "correct" value for this field - it should
uniquely identify the cluster, and will match other signature data
included in Fulcio certs, etc.
This is technically a breaking change, but likely one worth making.
Users can still override this behavior with the config map as before.
If omitted, this field is not populated as an indication that we don't
know how to accurately identify this cluster.
Copy file name to clipboardExpand all lines: docs/config.md
+67-23Lines changed: 67 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,21 +1,25 @@
1
-
<!--
2
-
---
3
-
linkTitle: "Chains Configuration"
4
-
weight: 20
1
+
## <!--
2
+
3
+
linkTitle: "Chains Configuration" weight: 20
4
+
5
5
---
6
+
6
7
-->
7
8
8
9
# Chains Configuration
9
10
10
-
`Chains` works by observing `TaskRun` and `PipelineRun` executions, capturing relevant information, and storing it in a cryptographically-signed format.
11
+
`Chains` works by observing `TaskRun` and `PipelineRun` executions, capturing
12
+
relevant information, and storing it in a cryptographically-signed format.
11
13
12
-
`TaskRuns` and `PipelineRuns` can indicate inputs and outputs which are then captured and surfaced in the `Chains` payload formats, where relevant.
13
-
`Chains` uses the `Results` to _hint_ at the correct inputs and outputs. Check out [slsa-provenance.md](slsa-provenance.md) for more details.
14
+
`TaskRuns` and `PipelineRuns` can indicate inputs and outputs which are then
15
+
captured and surfaced in the `Chains` payload formats, where relevant. `Chains`
16
+
uses the `Results` to _hint_ at the correct inputs and outputs. Check out
17
+
[slsa-provenance.md](slsa-provenance.md) for more details.
14
18
15
19
## Chains Configuration
16
20
17
-
Chains uses a `ConfigMap` called `chains-config` in the `tekton-chains` namespace for configuration.
18
-
Supported keys include:
21
+
Chains uses a `ConfigMap` called `chains-config` in the `tekton-chains`
22
+
namespace for configuration. Supported keys include:
19
23
20
24
### TaskRun Configuration
21
25
@@ -41,7 +45,8 @@ Supported keys include:
41
45
42
46
> NOTE:
43
47
>
44
-
> - For grafeas storage backend, currently we only support Container Analysis. We will make grafeas server address configurabe within a short time.
48
+
> - For grafeas storage backend, currently we only support Container Analysis.
49
+
> We will make grafeas server address configurabe within a short time.
45
50
> -`slsa/v1` is an alias of `in-toto` for backwards compatibility.
46
51
> -`slsa/v2alpha2` corresponds to the slsav1.0 spec.
47
52
@@ -72,34 +77,71 @@ Supported keys include:
72
77
73
78
#### docstore
74
79
75
-
You can read about the go-cloud docstore URI format [here](https://gocloud.dev/howto/docstore/). Tekton Chains supports the following docstore services:
80
+
You can read about the go-cloud docstore URI format
81
+
[here](https://gocloud.dev/howto/docstore/). Tekton Chains supports the
82
+
following docstore services:
76
83
77
84
-`firestore`
78
85
-`dynamodb`
79
86
-`mongo`
80
87
81
88
#### MongoDB
82
89
83
-
With MongoDB you will need to add a `MONGO_SERVER_URL` env var with the MongoDB connection URI to the `tekton-chains-controller`, the go-cloud URI is just to point at the db and collection
90
+
With MongoDB you will need to add a `MONGO_SERVER_URL` env var with the MongoDB
91
+
connection URI to the `tekton-chains-controller`, the go-cloud URI is just to
92
+
point at the db and collection
84
93
85
94
#### Grafeas
86
95
87
-
You can read more about Grafeas notes and occurrences [here](https://github.com/grafeas/grafeas/blob/master/docs/grafeas_concepts.md). To create occurrences, we have to create notes first that are used to link occurrences. Two types of occurrences will be created: `ATTESTATION` Occurrence and `BUILD` Occrrence. The configurable `noteid` is used as the prefix of the note name. Under the hood, the suffix `-simplesigning` will be appended for the `ATTESTATION` note, and the suffix `-intoto` will be appended for the `BUILD` note. If the `noteid` field is not configured, `tekton-<NAMESPACE>` will be used as the prefix.
96
+
You can read more about Grafeas notes and occurrences
|`builder.id`| The builder ID to set for in-toto attestations ||`https://tekton.dev/chains/v2`|
94
-
|`builddefinition.buildtype`| The buildType for in-toto attestations |`https://tekton.dev/chains/v2/slsa`, `https://tekton.dev/chains/v2/slsa-tekton`|`https://tekton.dev/chains/v2/slsa`|
|`builder.id`| The builder ID to set for in-toto attestations ||[Cluster's OIDC Issuer](#builder-id)|
111
+
|`builddefinition.buildtype`| The buildType for in-toto attestations |`https://tekton.dev/chains/v2/slsa`, `https://tekton.dev/chains/v2/slsa-tekton`|`https://tekton.dev/chains/v2/slsa`|
95
112
96
-
> NOTE:
97
-
> Considerations for the builddefinition.buildtype parameter:
113
+
> NOTE: Considerations for the builddefinition.buildtype parameter:
98
114
>
99
-
> - It is only valid for `slsa/v2alpha2` configurations (see TaskRun or PipelineRun configuration).
115
+
> - It is only valid for `slsa/v2alpha2` configurations (see TaskRun or
116
+
> PipelineRun configuration).
100
117
> - The parameter can take one of two values:
101
-
> -`https://tekton.dev/chains/v2/slsa`: This buildType strictly conforms to the slsav1.0 spec.
102
-
> -`https://tekton.dev/chains/v2/slsa-tekton`: This buildType also conforms to the slsav1.0 spec, but adds additional informaton specific to Tekton. This information includes the PipelinRun/TaskRun labels and annotations as internalParameters. It also includes capturing each pipeline task in a PipelinRun under resolvedDependencies.
118
+
> -`https://tekton.dev/chains/v2/slsa`: This buildType strictly conforms to
119
+
> the slsav1.0 spec.
120
+
> -`https://tekton.dev/chains/v2/slsa-tekton`: This buildType also conforms
121
+
> to the slsav1.0 spec, but adds additional informaton specific to Tekton.
122
+
> This information includes the PipelinRun/TaskRun labels and annotations as
123
+
> internalParameters. It also includes capturing each pipeline task in a
124
+
> PipelinRun under resolvedDependencies.
125
+
126
+
#### Builder ID
127
+
128
+
By default, Tekton Chains uses the Cluster OIDC issuer as the Builder ID to
129
+
identify the cluster performing the build.
130
+
131
+
This can vary depending on how the cluster is deployed - see
|`transparency.url`| The URL to upload binary transparency attestations to, if enabled. ||`https://rekor.sigstore.dev`|
112
154
113
-
**Note**: If `transparency.enabled` is set to `manual`, then only `TaskRuns` and `PipelineRuns` with the following annotation will be uploaded to the transparency log:
155
+
**Note**: If `transparency.enabled` is set to `manual`, then only `TaskRuns` and
156
+
`PipelineRuns` with the following annotation will be uploaded to the
0 commit comments