Overview
Ratify's configuration consist of Store, Verifier, and Executor.
Configuration file
When Ratify runs in cli serve mode, configuration file can be dynamically updated while the server is running, subsequent verification will be based on the updated configuration.
CRDs
Ratify also supports configuration through K8s CRDs. The configuration can be updated using natively supported kubectl commands.
When running Ratify in a pod, the ConfigMap will be mounted in the pod at the default configuration file path. Ratify will initialize with specifications from the configuration file. CRDs will override store and verifier defined in the configuration file if they exist at runtime. Our team is in the process of converting configuration components into Ratify CRDs to support a more native k8s experience. Please review ratify CRDs samples here.
Currently supported components through CRDs are:
Get Crds
Our helms charts are wired up to initialize CRs based on chart values.
After Ratify installation, you can use the kubectl command to review the currently active configuration.
Sample command:
kubectl get stores.config.ratify.deislabs.io --namespace default
kubectl get verifiers.config.ratify.deislabs.io --namespace default
kubectl get certificatestores.config.ratify.deislabs.io --namespace default
Update Crds
You can choose to add / remove / update crds. Sample command to update a verifier:
kubectl apply -f .../ratify/config/samples/config_v1alpha1_verifier_schemavalidator.yaml
Sample command to remove a verifier:
kubectl delete verifiers.config.ratify.deislabs.io/verifier-notary
Limitations
Currently Ratify only supports single namespace, Ratify cannot distinguish CRs with the same metadata name from different namespaces. To ensure predictable results, please install all CRs in a single namespace. This limitation is being tracked by issue 1061