Caching for same image verification vs automatic child approval

[mathuvenkat]

Is there any caching involved when specs refer to the same image which has been validated ?
i.e image is referenced by tag in the spec say image:tagA , mutating admission webhook changes it to image:digestA and verifies signature. For a different spec with image:tagA, will process be repeated or after it mutates to digest is there any understanding that it has been validated earlier ? How is automatic child approval related to this if at all ?

Second question is regarding secrets, to use connaisseur in our cluster for infra as well as tenant namespaces, we should have ability of tenant images being able to be verified by their own keys vs infra images verified by a different key. This is possible using policy patterns and validators to indicate different keys for different image prefix/pattern. If images were from different registries , can we specify auth for each validator ?

https://sse-secure-systems.github.io/connaisseur/v2.1.2/validators/sigstore_cosign/#authentication - "It is possible to provide one Kubernetes secret with a config.json for authentication to multiple private registries and referencing this in multiple validators."
Eg: is this right ?

--- 
policy: 
  - 
    pattern: "quay.io/team/component*:*"
    validator: infra-imagevalidator
    with: 
      key: key1
  - 
    pattern: "tenant.registry/team/component*:*"
    validator: tenant-imagevalidator
    with: 
      key: key1
validators: 
  - 
    auth: 
      secret_name: quay-secret
    name: infra-imagevalidator
    trust_roots: 
      - 
        key: |
            -----BEGIN PUBLIC KEY-----
            -----END PUBLIC KEY-----
        name: key1
    type: cosign
  - 
    auth: 
      secret_name: tenant-registry-secret
    name: tenant-imagevalidator
    trust_roots: 
      - 
        key: |
            -----BEGIN PUBLIC KEY-----
            -----END PUBLIC KEY-----
        name: key1
    type: cosign

[phbelitz]

Regarding the first question. No, currently we have no caching mechanism in place that will remember previously validated images, but its definitely something we want to tackle going forward. Specifically by reworking the automatic child approval.

Speaking of automatic child approval, the point of this feature is as follows. When you submit a deployment to the kube api, Connaisseur will validate the included image, which lets say is image:tag. This will get mutated to image:digest and then applied to the cluster. The creation of the deployment will spawn pods, which already include the mutated image:digest references. The images first of all already got validated (during validation of the deployment) and second, they may apply to a different policy rule, should you have one specifically for images with digests. So in order to skip this, connaisseur will check whether a resource is a child of someone else (in the example, the pods would be children of the deployment) and check whether the image of the child and parent are the same. Should this check out, the validation is skipped.

For the second question. Yes totally, you can do that. That's specifically how the system was designed. All validator are independent of each other and you can mix-mash different image patterns with different validators, however you feel like.

Feel free to ask any followup questions, should something still be unclear or not work.

[xopham]

@mathuvenkat in addition to @phbelitz response. Your configuration example looks correct.
Regarding the sentence from the docs you are quoting:

It is possible to provide one Kubernetes secret with a config.json for authentication to multiple private registries and referencing this in multiple validators.
This is meant to clarify the fact that in case multiple registries with different authentication are used (as in your case), it is possible to either create a separate secret for each registry as you did in your example:

• secret registry A:

{
  "auths": {
    "registryA.com:5000": {
      "username": "regAuser",
      "password": "myawesomepassword",
    }
  }
}

• secret registry B:

{
  "auths": {
    "registryB.com:5000": {
      "auth": "ASDFkjlwerupvckljsdfaSADFwlkerugjlkdnfgret23409sdfjaksljdfasd="
    }
  }
}

Or you could build a single secret containing both authentications and reference that secret twice in the validator configuration:

{
  "auths": {
    "registryA.com:5000": {
      "username": "regAuser",
      "password": "myawesomepassword",
    }
  },
  {
    "registryB.com:5000": {
      "auth": "ASDFkjlwerupvckljsdfaSADFwlkerugjlkdnfgret23409sdfjaksljdfasd="
    }
  }
}

[mathuvenkat]

@xopham - thanks for clarifying that part. So we could use one secret and use the same secret reference for multiple validators . Sorry for the naive question - per my example if "quay-secret" docker config json looks like the one you've provided above with registryA and registryB, how will it get resolved to which creds applies to which validator , if validators[].auth.secret_name is set as quay-secret

[xopham]

@mathuvenkat that is done by cosign implicitly and follows the standard dockerconfigjson approach whereby the domain of the image path is matched to the respective entries in the config.json. However, I do agree that there has been a related vulnerability of the docker cli that uses the same secret: CVE-2021-41092. So, one could argue that separate secrets may be a tiny bit more secure by compensating for potentially false credential matching.

[mathuvenkat]

@phbelitz , @xopham - One more question regarding this just to confirm. Does validation happen for existing images? Seems to be the case per my testing, as I', trying to get some stats on any performance implications on large zones on introducing connaissuer admission controller in our flow. Do we have any benchmarking numbers that you can point me to - I do not see them on the connaiseur docs.
i.e on minikube cluster I provided imagePullPolicy: IfNotPresent in the spec, but on observing connaisseur logs, I see it validates signature again. Why do we have this if existing image is going to be used?

[xopham]

@mathuvenkat the imagePullPolicy only refers to the Connaisseur deployment itself, not the admitted images.
We have indeed done some work to improve Connaisseur performance and get an understanding of limitations and choosing the right webserver architecture. The results are documented in ADR-7. However, there is no actual full performance testing beyond that.

As mentioned by @phbelitz , we aim to introduce a caching in the future that avoids re-validation for a given time period, but will require some architectural adjustments.

[mathuvenkat]

thanks @xopham - I didnt mean the imagePullPolicy on the connaisseur yaml, which I see is meant for that deployment, I meant even if I provide a new podspec.yaml with some container image say "x" with imagePullPolicy: IfNotPresent, even though the image is already downloaded, connaisseur still validates signature and fails to admit it. I had thought it would do validation only for imagePullPolicy:Always when the image was not already existing.