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 PR is a part of a larger set of PRs to provide non-falsifiable
provenance through SPIRE.
In particular this PR uses the SPIRE infrastructure which has already
been merged to sign TaskRunStatus.
It also has support to verify if TaskRunStatus has been modified by
another workload between reconciles.
Update pkg/pod/pod.go
Co-authored-by: Jerop Kipruto <[email protected]>
Update pkg/pod/pod.go
Co-authored-by: Jerop Kipruto <[email protected]>
Update pkg/pod/pod.go
Co-authored-by: Jerop Kipruto <[email protected]>
Copy file name to clipboardExpand all lines: docs/spire.md
+251-5Lines changed: 251 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,13 +6,58 @@ weight: 1660
6
6
-->
7
7
⚠️ This is a work in progress: SPIRE support is not yet functional
8
8
9
-
TaskRun result attestations is currently an alpha experimental feature. Currently all that is implemented is support for configuring Tekton to connect to SPIRE. See TEP-0089 for details on the overall design and feature set.
9
+
TaskRun result attestations is currently an alpha experimental feature. Currently all that is implemented is support for configuring Tekton to connect to SPIRE and enabling TaskRun to sign and verify the TaskRunStatus. See [TEP-0089](https://github.com/tektoncd/community/blob/main/teps/0089-nonfalsifiable-provenance-support.md) for details on the overall design and feature set.
10
10
11
11
This being a large feature, this will be implemented in the following phases. This document will be updated as we implement new phases.
12
12
1. Add a client for SPIRE (done).
13
-
2. Add a configMap which initializes SPIRE (in progress).
14
-
3. Modify TaskRun to sign and verify TaskRun Results using SPIRE.
15
-
4. Modify Tekton Chains to verify the TaskRun Results.
13
+
2. Add a configMap which initializes SPIRE (done).
14
+
3. Modify TaskRun to sign and verify TaskRunStatus using SPIRE (done).
15
+
4. Enabling Chains to verify the TaskRun Results.
16
+
17
+
When the TaskRun result attestations feature is [enabled](./spire.md#enabling-taskrun-result-attestations) all TaskRuns will produce a signature alongside its results, which can then be used to validate its provenance. For example, a TaskRun result that creates user-specified results `commit` and `url` would look like the following. `SVID`, `RESULT_MANIFEST`, `RESULT_MANIFEST.sig`, `commit.sig` and `url.sig` are generated attestations by the integration of SPIRE and Tekton Controller.
However, the verification materials are removed from the final results as part of the TaskRun status. It is stored in the termination messages (more details below):
1. Make sure `enforce-nonfalsifiability` is set to `"spire"` in the `feature-flags` configmap, see [`install.md`](./install.md#customizing-the-pipelines-controller-behavior) for details
112
+
1. Make sure `enforce-nonfalsifiability` is set to `"spire"` in the `feature-flags` configmap, see [`additional-configs.md`](./additional-configs.md#customizing-the-pipelines-controller-behavior) for details
68
113
1. Create a SPIRE deployment containing a SPIRE server, SPIRE agents and the SPIRE CSI driver, for convenience, [this sample single cluster deployment](https://github.com/spiffe/spiffe-csi/tree/main/example/config) can be used.
69
114
1. Register the SPIRE workload entry for Tekton with the "Admin" flag, which will allow the Tekton controller to communicate with the SPIRE server to manage the TaskRun identities dynamically.
70
115
```
@@ -127,3 +172,204 @@ To enable TaskRun attestations:
127
172
# spire-node-alias-prefix specifies the SPIRE node alias prefix to use.
128
173
spire-node-alias-prefix: "/tekton-node/"
129
174
```
175
+
176
+
## Sample TaskRun attestation
177
+
178
+
The following example shows how this feature works:
However, the verification materials are removed from the results as part of the TaskRun status:
237
+
```console
238
+
$ tkn tr describe non-falsifiable-provenance
239
+
Name: non-falsifiable-provenance
240
+
Namespace: default
241
+
Service Account: default
242
+
Timeout: 1m0s
243
+
Labels:
244
+
app.kubernetes.io/managed-by=tekton-pipelines
245
+
246
+
🌡️ Status
247
+
248
+
STARTED DURATION STATUS
249
+
38 seconds ago 36 seconds Succeeded
250
+
251
+
📝 Results
252
+
253
+
NAME VALUE
254
+
∙ bar world
255
+
∙ foo hello
256
+
257
+
🦶 Steps
258
+
259
+
NAME STATUS
260
+
∙ non-falsifiable Completed
261
+
```
262
+
263
+
## How is the result being verified
264
+
265
+
The signatures are being verified by the Tekton controller, the process of verification is as follows:
266
+
267
+
- Verifying the SVID
268
+
- Obtain the trust bundle from the SPIRE server
269
+
- Verify the SVID with the trust bundle
270
+
- Verify that the SVID spiffe ID is for the correct TaskRun
271
+
- Verifying the result manifest
272
+
- Verify the content of `RESULT_MANIFEST` with the field `RESULT_MANIFEST.sig` with the SVID public key
273
+
- Verify that there is a corresponding field for all items listed in `RESULT_MANIFEST` (besides SVID and `*.sig` fields)
274
+
- Verify individual result fields
275
+
- For each of the items in the results, verify its content against its associated `.sig` field
276
+
277
+
278
+
# TaskRun Status attestations
279
+
280
+
Each TaskRun status that is written by the tekton-pipelines-controller will be signed to ensure that there is no external
281
+
tampering of the TaskRun status. Upon each retrieval of the TaskRun, the tekton-pipelines-controller checks if the status is initialized,
282
+
and that the signature validates the current status.
283
+
The signature and SVID will be stored as annotations on the TaskRun Status field, and can be verified by a client.
284
+
285
+
The verification is done on every consumption of the TaskRun except when the TaskRun is uninitialized. When uninitialized, the
286
+
tekton-pipelines-controller is not influenced by fields in the status and thus will not sign incorrect reflections of the TaskRun.
287
+
288
+
The spec and TaskRun annotations/labels are not signed when there are valid interactions from other controllers or users (i.e. cancelling taskrun).
289
+
Editing the object annotations/labels or spec will not result in any unverifiable outcome of the status field.
290
+
291
+
As the TaskRun progresses, the Pipeline Controller will reconcile the TaskRun object and continually verify the current hash against the `tekton.dev/status-hash-sig` before updating the hash to match the new status and creating a new signature.
The signature are being verified by the Tekton controller, the process of verification is as follows:
368
+
369
+
- Verify status-hash fields
370
+
- verify `tekton.dev/status-hash` content against its associated `tekton.dev/status-hash-sig` field. If status hash does
371
+
not match invalidate the `tekton.dev/verified = no` annotation will be added
372
+
373
+
## Further Details
374
+
375
+
To learn more about SPIRE attestations, check out the [TEP](https://github.com/tektoncd/community/blob/main/teps/0089-nonfalsifiable-provenance-support.md).
0 commit comments