Support CRDs in a K8s environment

[lee0c]

Ratify should be configurable through either config.json or, in a Kubernetes environment, through dynamically configurable CRDs. We propose 2 CRDs: a Store and a Verifier. Both CRDs should be thought of as representing a specific type of store/verifier with a specific configuration – aka, a notaryv2 verifier with keys A and B is distinct from a notaryv2 verifier with key C.

kind: Store
metadata:
  name: string # Cluster-unique name for this store
  namespace: string # Namespace in which to use this store
spec:
  type: string # ORAS, FilePath, Sigstore, etc
  address: string # Optional (required for custom store). URL or file path
  auth:
    mode: string # K8sSecrets, AzureWorkloadIdentity, etc
    # may need additional fields here

kind: Verifier
metadata:
  name: string # Cluster-unique name for this verifier
  namespace: string # Namespace in which to use this verifier
spec:
  type: string # NotaryV2, SBOM, VulnerabilityScan, etc
  address: string # Optional. URL/file path
  artifactType: string
  params: object # Verifier-specific field. For ex. NotaryV2 takes certs

It may be beneficial to have an additional CRD for Keys to allow for flexibility in how keys are stored/fetched - this is worthy of further discussion. @etrexel I think you have more familiarity with options around keys and how they are handed to Notation/the notation verifier?

David Tesar edit 8/9/2022: I'd like to break this down into smaller parts.

• CRD Design document #281
• Implement CRDs for Stores
• Implement CRDs for Verifiers #282