Skip to content

Detection Mode⚓︎

A detection mode is available in order to avoid interruptions of a running cluster, to support initial rollout or for testing purposes. In detection mode, Connaisseur admits all images to the cluster, but issues a warning1 and logs an error message for images that do not comply with the policy or in case of other unexpected failures:

kubectl run unsigned --image=docker.io/securesystemsengineering/testimage:unsigned
> Warning: Unable to find signed digest for image docker.io/securesystemsengineering/testimage:unsigned. (not denied due to DETECTION_MODE)
> pod/unsigned created

To activate the detection mode, set the detectionMode flag to true in charts/connaisseur/values.yaml.

Configuration options⚓︎

detectionMode in charts/connaisseur/values.yaml under application.features supports the following values:

Key Default Required Description
detectionMode false - true or false; when detection mode is enabled, Connaisseur will warn but not deny requests with untrusted images.

Example⚓︎

charts/connaisseur/values.yaml
charts/connaisseur/values.yaml
application:
  features:
    detectionMode: true

Additional notes⚓︎

Failure policy vs. detection mode⚓︎

The detection mode is not to be confused with the failure policy (kubernetes.webhook.failurePolicy in charts/connaisseur/values.yaml) for the mutating admission controller: In detection mode, Conaisseur service admits all requests to the cluster independent of the validation result while the failure policy only takes effect when the service itself becomes unavailable. As such, both options are disjoint. While in default configuration, requests will be denied if either no valid image signature exists or the Connaisseur service is unavailable, setting failurePolicy to Ignore and detectionMode to true ensures that Connaisseur never blocks a request.

  1. The feature to send warnings to API clients as shown above was only introduced in Kubernetes v1.19. However, warnings are only surfaced by kubectl in stderr to improve usability. Except for testing purposes, the respective error messages should either be handled via the cluster's log monitoring solution or by making use of Connaisseur's alerting feature. ↩