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
+7-1Lines changed: 7 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,8 @@ 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 must pass all the "enforce" mode policies. If the resource only matches policies in "warn" mode and fails to pass the "warn" policy, it will not fail the taskrun or pipelinerun, but log a warning instead.
82
+
82
83
4. To pass one policy, the resource can pass any public keys in the policy.
83
84
84
85
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 +110,8 @@ spec:
109
110
key:
110
111
# data stores the inline public key data
111
112
data: "STRING_ENCODED_PUBLIC_KEY"
113
+
# mode can be set to "enforce" (default) or "warn".
114
+
mode: enforce
112
115
```
113
116
114
117
```yaml
@@ -141,6 +144,9 @@ To learn more about `ConfigSource` please refer to resolvers doc for more contex
141
144
142
145
`hashAlgorithm`is the algorithm for the public key, by default is `sha256`. It also supports `SHA224`, `SHA384`, `SHA512`.
143
146
147
+
`mode`controls whether a failing policy will fail the taskrun/pipelinerun, or only log the a warning
148
+
* enforce (default) - fail the taskrun/pipelinerun if verification fails
149
+
* warn - don't fail the taskrun/pipelinerun if verification fails but log a warning
144
150
145
151
#### Migrate Config key at configmap to VerificationPolicy
146
152
**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.
139
-
// 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.
138
+
// 1. If multiple policies match, the resource must satisfy all the "enforce" policies to pass verification. The matching "enforce" policies are evaluated using AND logic.
139
+
// Alternatively, if the resource only matches policies in "warn" mode, it will still pass verification and only log a warning if these policies are not satisfied.
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.
// prepareObjectMeta will remove annotations not configured from user side -- "kubectl-client-side-apply" and "kubectl.kubernetes.io/last-applied-configuration"
180
-
// to avoid verification failure and extract the signature.
187
+
// (added when an object is created with `kubectl apply`) to avoid verification failure and extract the signature.
188
+
// Returns a copy of the input object metadata with the annotations removed and the object's signature,
189
+
// if it is present in the metadata.
190
+
// Returns a non-nil error if the signature cannot be decoded.
0 commit comments