feat: add more notation attributes to values.yaml

[shahramk64]

Description

What this PR does / why we need it:

Currently, helm chart parameters exist for ORAS stores and KMP resources, but not for Notation Verifier. We need to add parameters for setting up Notation Verifier.

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):

Fixes #1965

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Helm Chart Change (any edit/addition/update that is necessary for changes merged to the main branch)
• This change requires a documentation update

How Has This Been Tested?

Checklist:

• Does the affected code have corresponding tests?
• Are the changes documented, not just with inline documentation, but also with conceptual documentation such as an overview of a new feature, or task-based documentation like a tutorial? Consider if this change should be announced on your project blog.
• Does this introduce breaking changes that would require an announcement or bumping the major version?
• Do all new files have appropriate license header?

Post Merge Requirements

• MAINTAINERS: manually trigger the "Publish Package" workflow after merging any PR that indicates Helm Chart Change

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

see 4 files with indirect coverage changes

[yizha1]

How can different trust policies use different stores?

[shahramk64]

How can different trust policies use different stores?

Consider the following verifier.yaml:

apiVersion: config.ratify.deislabs.io/v1beta1
kind: Verifier
metadata:
  name: verifier-notation
spec:
  name: notation
  artifactTypes: application/vnd.cncf.notary.signature
  parameters:
    verificationCertStores:
      my_private_cert:
        - kmpprovider-akv
      my_public_cert:
        - inline_mar_images
    trustPolicyDoc:
      version: "1.0"
      trustPolicies:
        - name: my_private_registry
          registryScopes:
            - "skalantari_registry.azurecr.io/*"
          signatureVerification:
            level: strict
          trustStores:
            - ca:my_private_cert
          trustedIdentities:
            - "my identity"
        - name: mar_images
          registryScopes:
            - "mcr.azurecr.io/*"
          signatureVerification:
            level: strict
          trustStores:
            - ca:inline_mar_images
          trustedIdentities:
            - "mar identity"

It defines two trustPolicies, each include their trustStores, trustedIdentities, and registryScopes. In my PR, I moved this section to values.yaml so that the user can configure it before the installation. Note that verificationCertStores is filled with the values specified in values.yaml too (notationCerts in values.yaml is used)

[yizha1]

Can you describe how users configure values.yaml for the verifier.yaml example?

[akashsinghal]

I think what @yizha1 is getting is how would the user from the helm chart be able to set up the verificationCertStores field because that would require the mapping between the notation trust store name and the ratify KMP names that belong to that trust store.