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
After installation of Ratify, I configured cosign verifier to verify images signed with Cosign and keys stored in AKV. However, the image deployment was denied. After checking the Ratify logs, the verification of cosign signature was successful. However, the report from notation verifier indicated failure, which is as expected, as images were signed with Cosign not Notation. I deleted notation built-in verifier as a mitigation, then signature verification passed and images were deployed successfully.
What did you expect to happen?
Images can be signed with different signatures and be referenced with various supply chain artifacts, such as SBOM. Thus, there could be one or multiple verifiers required for verifying images depending on user scenarios. Users should be provided with a policy template to define the criteria for a successful image verification.
What version of Kubernetes are you running?
AKS
What version of Ratify are you running?
0-dev (dev.20240505.6163b7e)
Anything else you would like to add?
I signed one image with two keys in AKV, which resulted in two signatures. I expected image verification should pass only and only if two signatures passed validation. By default, as long as one signature passed validation, the image was allowed to be deployed. This scenario also requires a Rego policy in my understanding.
Are you willing to submit PRs to contribute to this bug fix?
Yes, I am willing to implement it.
The text was updated successfully, but these errors were encountered:
When notation and cosign are both configured, there is a few options how the policy behaves ( 1. i want to make sure notation and cosign signature exist , 2 . As long as we were able to validate the signature attached to the image , pass. 3. cosign OR notation signature found). Currently for both config Policy (default) and rego, we required both cosign and notation signature to be valid.
Discussed in PR review meeting today, we can add a flag in ratify helm chart to disable notation verifier. But at least 1 BUILT IN verifier must be configured, the chart will have both built in verifier ENABLED by default.
What happened in your environment?
After installation of Ratify, I configured cosign verifier to verify images signed with Cosign and keys stored in AKV. However, the image deployment was denied. After checking the Ratify logs, the verification of cosign signature was successful. However, the report from notation verifier indicated failure, which is as expected, as images were signed with Cosign not Notation. I deleted notation built-in verifier as a mitigation, then signature verification passed and images were deployed successfully.
What did you expect to happen?
Images can be signed with different signatures and be referenced with various supply chain artifacts, such as SBOM. Thus, there could be one or multiple verifiers required for verifying images depending on user scenarios. Users should be provided with a policy template to define the criteria for a successful image verification.
What version of Kubernetes are you running?
AKS
What version of Ratify are you running?
0-dev (dev.20240505.6163b7e)
Anything else you would like to add?
I signed one image with two keys in AKV, which resulted in two signatures. I expected image verification should pass only and only if two signatures passed validation. By default, as long as one signature passed validation, the image was allowed to be deployed. This scenario also requires a Rego policy in my understanding.
Are you willing to submit PRs to contribute to this bug fix?
The text was updated successfully, but these errors were encountered: