question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

cosign + connaisseur - image with multiple cosign signatures to be verified before deployment

See original GitHub issue

Discussed in https://github.com/sse-secure-systems/connaisseur/discussions/371

Implement verification against multiple trust roots in the policy. Could be done by for example making the trust_root key in the policy a list:

- pattern: "docker.io/my-app/*:*"
  validator: my-validator
  with:
    trust_root: ["vulnerability-scanner","qa-scanner"]

This could be extended by a required key to enforce some signatures or a threshold to set a minimum of signatures present

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Reactions:1
  • Comments:7 (1 by maintainers)

github_iconTop GitHub Comments

1reaction
xophamcommented, Dec 25, 2021

I quickly built an RC for testing. The respective branch is: https://github.com/sse-secure-systems/connaisseur/tree/debug-build/pr428-multi-signer Note: Here, the connaisseur image for testing is provided via my private docker repository.

A few notes on testing: The helm/values.yaml contains my test configuration to play around with. The essential lines are:

(...)
### VALIDATORS ###
# validators are a set of configurations (types, public keys, authentication)
# that can be used for validating one or multiple images (or image signatures).
# they are tied to their respective image(s) via the image policy below. there
# are a few handy validators pre-configured.
validators:
(...)
- name: multisign
  type: cosign  # or other supported validator (e.g. "cosign")
  trust_roots:
  # # the `default` key is used if no key is specified in image policy
  - name: alice
    key: |  # enter your public key below
      -----BEGIN PUBLIC KEY-----
      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEusIAt6EJ3YrTHdg2qkWVS0KuotWQ
      wHDtyaXlq7Nhj8279+1u/l5pZhXJPW8PnGRRLdO5NbsuM6aT7pOcP100uw==
      -----END PUBLIC KEY-----
  - name: bob
    key: |  # enter your public key below
      -----BEGIN PUBLIC KEY-----
      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE01DasuXJ4rfzAEXsURSnbq4QzJ6o
      EJ2amYV/CBKqEhhl8fDESxsmbdqtBiZkDV2C3znIwV16SsJlRRYO+UrrAQ==
      -----END PUBLIC KEY-----
  - name: charlie
    key: |  # enter your public key below
      -----BEGIN PUBLIC KEY-----
      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEHBUYJVrH+aFYJPuryEkRyE6m0m4
      ANj+o/oW5fLRiEiXp0kbhkpLJR1LSwKYiX5Toxe3ePcuYpcWZn8Vqe3+oA==
      -----END PUBLIC KEY-----

### IMAGE POLICY ###
# the image policy ties validators and images together whereby always only the most specific rule (pattern)
# is applied. specify if and how images should be validated by which validator via the validator name.
policy:
- pattern: "*:*"
  validator: multisign
  with:
    trust_root: "*"  # wildcard "*" added to allow specifying all trust roots of a validator
    threshold: 2  # minimum number of trust root signatures present for successfull verification
    required: ["bob", "charlie"]  # required trust roots by name
(...)

There is some notes on how to use the new features. Essentially, you need to create a validator with multiple trust roots and corresponding keys. Multiple trust roots are then referred to in the policy by setting policy[*].with.trust_root="*" which means that all trust roots of the specified validator will be considered for evaluation. Refined rules can then be specified via threshold and required flags:

  • threshold: minimum number of trust root signatures required. Default is number of specified trust roots for validator (i.e. all trust roots must have signed).
  • required: list of required trust roots amongst signatures. Default is none required. Both flags can be used in conjunction, i.e. enforce two specific signers but also at least 3 different signatures.

Just to get started testing, feel free to use my sample images:

export IMAGE=docker.io/xoph/multisign
kubectl run all --image=$IMAGE:3-signers
kubectl run alice --image=$IMAGE:1-signer
kubectl run alice-bob --image=$IMAGE:2-signers
kubectl run bob-charlie --image=$IMAGE:2-other-signers

However, feel free to build your own testimages and play around with the new feature.

Please let me know in case you find any bugs or have recommendations for the interface or defaults 🙏

fyi: @tommyreilly @operatorequals

0reactions
xophamcommented, Mar 2, 2022
Read more comments on GitHub >

github_iconTop Results From Across the Web

CONNAISSEUR - Verify Container Image Signatures in ...
Verifying the image signatures before deployment. Connaisseur aims to solve step two. This is achieved by implementing several validators, i.e. configurable ...
Read more >
Verify Container Image Signatures in Kubernetes using Notary ...
Verify Container Image Signatures in Kubernetes using Notary or Cosign or both. Connaisseur v2.0 adds support for multiple keys and signature solutions.
Read more >
Signing imgpkg Bundles with cosign - Carvel tools
Sign the container image after building; Copy the bundle (of images); Verify the image signatures before deployment.
Read more >
Verify OCI Container Image Signatures in Kubernetes - sigstore
Enter Connaisseur and Cosign! Two persons signing and verifying documents as an illustration for the Cosign-Connaisseur interplay for. Photo by ...
Read more >
TGI Kubernetes 174: Verifying Signed Images with Connaisseur
Join Pushkar with Christoph from SSE - Secure Systems Engineering GmbH, as we explore, why having signed images only is not enough.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found