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 commit uses verification policy's mode field in trusted resources.
The mode can be set to "warn" or "enforce". The policy will use "enforce" mode if the `mode` is not set.
If the mode is set `warn`, then fails to verify this policy will only
log a warning and not fail the taskruns or pipelineruns. "enforce" mode
policy will fail the taskruns or pipelineruns if fails to verify.
Signed-off-by: Yongxuan Zhang [email protected]
Copy file name to clipboardExpand all lines: docs/trusted-resources.md
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,7 @@ How does VerificationPolicy work?
78
78
You can create multiple `VerificationPolicy` and apply them to the cluster.
79
79
1. Trusted resources will look up policies from the resource namespace (usually this is the same as taskrun/pipelinerun namespace).
80
80
2. If multiple policies are found. For each policy we will check if the resource url is matching any of the `patterns` in the `resources` list. If matched then this policy will be used for verification.
81
-
3. If multiple policies are matched, the resource needs to pass all of them to pass verification.
81
+
3. If multiple policies are matched, the resource needs to pass all of the "enforce" mode policies. If only matching "warn" mode policies, fail to pass the "warn" policy will not fail the taskrun/pipelinerun but only log a warning.
82
82
4. To pass one policy, the resource can pass any public keys in the policy.
83
83
84
84
Take the following `VerificationPolicies` for example, a resource from "https://github.com/tektoncd/catalog.git", needs to pass both `verification-policy-a` and `verification-policy-b`, to pass `verification-policy-a` the resource needs to pass either `key1` or `key2`.
@@ -109,6 +109,8 @@ spec:
109
109
key:
110
110
# data stores the inline public key data
111
111
data: "STRING_ENCODED_PUBLIC_KEY"
112
+
# mode can be set to "enforce" or "warn".
113
+
mode: enforce
112
114
```
113
115
114
116
```yaml
@@ -141,6 +143,9 @@ To learn more about `ConfigSource` please refer to resolvers doc for more contex
141
143
142
144
`hashAlgorithm`is the algorithm for the public key, by default is `sha256`. It also supports `SHA224`, `SHA384`, `SHA512`.
143
145
146
+
`mode`controls whether a failing policy will fail the taskrun/pipelinerun, or only log the a warning
147
+
* enforce (default) - fail the taskrun/pipelinerun if verification fails
148
+
* warn - don't fail the taskrun/pipelinerun if verification fails but log a warning
144
149
145
150
#### Migrate Config key at configmap to VerificationPolicy
146
151
**Note:** key configuration in configmap is deprecated,
// verifyResource verifies resource which implements metav1.Object by provided signature and public keys from verification policies.
137
137
// For matched policies, `verifyResource“ will adopt the following rules to do verification:
138
-
// 1. If multiple policies are matched, the resource needs to pass all of them to pass verification. We use AND logic on matched policies.
138
+
// 1. If multiple policies are matched, the resource needs to pass all of "enforced" mode policies to pass verification. We use AND logic on matched "enforce" policies.
139
+
// or the resource only matches "warn" mode policies.
139
140
// 2. To pass one policy, the resource can pass any public keys in the policy. We use OR logic on public keys of one policy.
0 commit comments