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.
Ratify also supports configuration through K8s CRDs. The configuration can be updated using natively supported
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:
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.
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
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
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