sse-secure-systems/connaisseur

An admission controller that integrates Container Image Signature Verification into a Kubernetes cluster

A Kubernetes admission controller to integrate container image signature verification and trust pinning into a cluster.

👉 The full documentation is available here 📖

👉 Feel free to reach out via GitHub Discussions 💬

What is Connaisseur?

Connaisseur ensures integrity and provenance of container images in a Kubernetes cluster. To do so, it intercepts resource creation or update requests sent to the Kubernetes cluster, identifies all container images and verifies their signatures against pre-configured public keys. Based on the result, it either accepts or denies those requests.

Connaisseur is developed under three core values: Security, Usability, Compatibility. It is built to be extendable and currently aims to support the following signing solutions:

• Notary V1 / Docker Content Trust
• Sigstore / Cosign
• Notary V2 (PLANNED)

It provides several additional features such as:

• Alerting: send alerts based on verification result
• Detection Mode: warn but do not block invalid images
• Namespaced Validation: restrict validation to dedicated namespaces

Quick start

Getting started to verify image signatures is only a matter of minutes:

⚠️ Only try this out on a test cluster as deployments with unsigned images will be blocked. ⚠️

Connaisseur comes pre-configured with public keys for its own repository and Docker's official images (official images can be found here). It can be fully configured via helm/values.yaml. For a quick start, clone the Connaisseur repository:

git clone https://github.com/sse-secure-systems/connaisseur.git

Next, install Connaisseur via Helm:

helm install connaisseur helm --atomic --create-namespace --namespace connaisseur

Once installation has finished, you are good to go. Successful verification can be tested via official Docker images like hello-world:

kubectl run hello-world --image=docker.io/hello-world

Or our signed testimage:

kubectl run demo --image=docker.io/securesystemsengineering/testimage:signed

Both will return pod/<name> created. However, when trying to deploy an unsigned image:

kubectl run demo --image=docker.io/securesystemsengineering/testimage:unsigned

Connaisseur denies the request and returns an error (...) Unable to find signed digest (...). Since the images above are signed using Docker Content Trust, you can inspect the trust data using docker trust inspect --pretty <image-name>.

To uninstall Connaisseur use:

helm uninstall connaisseur --namespace connaisseur

Congrats 🎉 you just validated the first images in your cluster! To get started configuring and verifying your own images and signatures, please follow our setup guide.

Discussions, support & feedback

We hope to steer development of Connaisseur from demand of the community, are excited about your feedback and happy to help if you need support! So feel free to connect with us via GitHub Discussions.

Contributing

We are always excited about direct contributions to improve the tool! Please refer to our contributing guide to learn how to contribute to Connaisseur.

Security policy

We are grateful for any community support reporting vulnerabilities! How to submit a report is described in our Security Policy.

Wall of fame

Thanks to all the fine people directly contributing commits/PRs to Connaisseur:

Big shout-out also to all who support the project via issues, discussions and feature requests 🙏

Contact

You can reach us via email under [email protected].

connaisseur's Issues

Allow latest signed tag when multiple signed images with same tag exist

Describe the feature
When a tag has multiple signed images, connaisseur will deny with:
admission webhook "connaisseur-svc.connaisseur.svc" denied the request: found multiple signed digests for the same image.

Optional: Is your feature request related to a problem? Please describe.
Ideally, Connaisseur should identify the latest signed image for a given tag and optionally inform the user during deployment.

container hardening

We should investigate, whether the security of the connaisseur container can be futher improved, in case of a container compromise.

Examples:

1. change the user inside the container from root, to a less privileged one
2. set the filesystem to be read-only

Add support for keyless signatures for cosign

Describe the feature
Cosign offers yet another even more experimental feature: keyless signatures via OIDC. Connaisseur should attempt to support this based on Fulcio code signing certificates.

Optional: Implementation ideas
Not sure.

Only download required delegations

Describe the bug
Connaisseur downloads all delegation trust data.

Expected behavior
Connaisseur should only download the trust data that is actually needed, ignoring the rest. Should one of the trust data be empty, raise an error.

notary without authentication is handled incorrectly

Describe the bug
The case of notary servers that do not require authentication is mishandled. In case the notary does issue a JWT for anonymous users (e.g. notary.docker.io) the get_auth function does not handle unauthorized calls, but defaults to BasicAuth: https://github.com/sse-secure-systems/connaisseur/blob/master/connaisseur/notary_api.py#L296

Expected behavior
Pull trust data for anonymous users e.g. for notary.docker.io should work without setting credentials.

Optional: To reproduce

1. Configure helm/values.yml with rootPubKey for your public docker image without setting notary credentials.
2. install connaisseur: make install
3. kubectl run your public container image
4. error message will be prompted and details can be found in connaisseur logs

Optional: Versions (please complete the following information as relevant):

• OS: Ubuntu 20.04
• Kubernetes Cluster: microK8s
• Notary Server: notary.docker.io
• Container registry: docker.io
• Connaisseur: v1.20

Pull Request Template

Describe the feature
We need a pull request template, so that it automatically creates them for the develop branch, and NOT the master branch.

Integrate Cosign signature verification in python

Describe the feature
With #107, we have added support for cosign-based signatures by injecting it into the image. This provides the benefit of being able to support new features fast, but comes at the cost of having to include an external binary, significantly increased image size and the difficulty to parse the somewhat complicated stdout and stderr of cosign. Furthermore, cosign uses the local docker context and since we do not provide any, this means we cannot verify private images, i.e. images in private registries or other images that require authentication. It might be worth considering to validate cosign-based signatures directly by a self-built python library or if that happens a future python library if that happens to exist.

Optional: Implementation ideas
If we were to do that, could as well make it an open library.

'trust data has invalid format.'

I am using Dockerhub instead of Harbor and getting the following error:
Error from server: error when creating "deploymentandservice.yaml": admission webhook "connaisseur-svc.connaisseur.svc" denied the request: trust data has invalid format.
Below is the connaisseur pod log:
[2020-09-30 00:59:37,182] ERROR: {'message': 'trust data has invalid format.', 'context': {'trust_data_type': 'root', 'user': 'minikube-user', 'operation': 'CREATE', 'kind': 'Deployment', 'namespace': 'default', 'name': 'sample-deployment', 'image': '272965041/signed-image:v1'}, 'detection_mode': False}

Periodically scan actual Connaisseur and helm-hook image from Docker Hub with Trivy

Describe the feature
currently, the connaisseur and helm-hook images are only scanned and tested in the CI/CD but not on a periodic basis. There should be a scan and reporting every night to ensure no publicly available vulnerable version.

Optional: Is your feature request related to a problem? Please describe.
We cannot ensure that the actually public images are not vulnerable.

Optional: Implementation ideas
standard CI workflow with nightly run

Prototype Validation with Notary v2

Describe the feature
As we make progress on Notary v2, customers have asked about integration with several projects like Connaisseur. As we're not experts with Connaisseur, and we'd like to make sure we've collected the right feedback, we'd invite the maintainers, or anyone active with the project to view the latest prototypes, captured in the above status reports and let us know if we've captured the needs to integrate Connaisseur with full Notary v2 support, including content promotion within and across registries.

Optional: Implementation ideas
Use Notary v2 signatures for validation of content before deployment. The e2e scenarios are captured here: Notary v2 Scenarios

Optional: Additional context
Feel free to reach out to any of the Notary v2 folks, myself, or possibly participate in the Notary v2 weekly call: https://hackmd.io/_vrqBGAOSUC_VWvFzWruZw

Helm-hook image is not versioned

Describe the bug
The helm-hook image has no version information, so it cannot be updated without endangering past installations of Connaisseur

Optional: Additional context
E.g. can't rebuild image due to base image vulnerabilites without oerwriting prior image

Add rekor support for cosign

Describe the feature
With #107, basic Cosign support was added. In the spirit of extending that support and strengthening the signature verification, we could extend this to also support the rekor integration of cosign: https://github.com/sigstore/cosign/tree/v0.2.0#rekor-support

Optional: Implementation ideas
We would probably have to extend the cosign configuration in the helm/values.yaml and might reuse host key. However, integration should not be too hard an issue.

Improve Integration tests to check whether returned digests are actually valid

Describe the bug
In the integration tests, it is checked whether 'pod created'. However, this will even appear, if the digest is wrong and the image cannot be pulled.

Expected behavior
Integration test should fail, if the actual image cannot be pulled. To do so, the Pod Status must be checked

use 'startup probes' instead of sentinel

Describe the feature
A startup probe could be used to manage liveliness and healthiness during Connaisseur startup: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes

Optional: Is your feature request related to a problem? Please describe.
The sentinel was introduced to handle the startup process of Connaisseur in order to manage liveliness and readiness before webhook and others are setup. A startup probe may be the more native solution.

Consider setting a codecov yaml to e.g. enforce minimum coverage...

Describe the feature
A minimum code coverage via codecov yaml could be enforced: https://docs.codecov.io/docs/codecov-yaml

kubernetes - not a valid image format

I have deployed notary-server and signer to my kubernetes cluster, made sure all TLS is setup properly, I then deployed connaisseur, and again, all green in kubernetes.

I have signed some images in my private registry also deployed on kubernetes, but when I try to use them in kube objects I got the error:

Error from server: error when creating "failed.yml": admission webhook "connaisseur-svc.connaisseur.svc" denied the request: "private-registry:30005/kibana:5.6.8" is not a valid image format.

The relevant logs from connaisseur pod:

ERROR: {'message': '"private-registry:30005/kibana:5.6.8" is not a valid image format.', 'context': {'user': 'kubernetes-admin', 'operation': 'CREATE', 'kind': 'Job', 'namespace': 'default', 'name': 'hello', 'image': 'private-registry:30005/kibana:5.6.8'}, 'detection_mode': False}

Is this a known bug? Is there something specific I need?

Compatibility to cosign v0.3.0 signatures

UPDATE: We should check and make ourselves compatible to the newest version available...

Describe the bug
Cosign v0.3.0 changed the signature specification slightly which causes v0.3.0 based signatures to be incompatible with connaisseur.
v0.2.0:

{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:2f6d89c49ad745bfd5d997f9b2d253329323da4c500c7fe343e068c0382b8df4"},"Type":"cosign container signature"},"Optional":null}

v0.3.0:

{"critical":{"identity":{"docker-reference":"index.docker.io/xoph/demo4"},"image":{"docker-manifest-digest":"sha256:2f6d89c49ad745bfd5d997f9b2d253329323da4c500c7fe343e068c0382b8df4"},"type":"cosign container image signature"},"optional":null}

Note that the JSON keys were de-capitalized in v0.3.0.

Expected behavior
Connaisseur should be able to validate v0.2.0 and v0.3.0 based signatures. This could be fixed by adjusting the exception handling in: https://github.com/sse-secure-systems/connaisseur/blob/master/connaisseur/sigstore_validator.py#L36

Might switch the whole validator to cosign v0.3.0 or v0.3.1 directly for that matter.

Optional: To reproduce
Sign an image usign cosign v0.3.0 and attempt to verify with connaisseur.

Optional: Versions (please complete the following information as relevant):

• Kubernetes Cluster: microK8s v1.19.9
• Notary Server: Cosign v0.3.0
• Container registry: DockerHub
• Connaisseur: v1.15.0

Connaisseur in EKS Environment

I could see that content trust/notary server support in Aws ECS is still yet to implement.

aws/containers-roadmap#43

So is it possible to deploy connaisseur without the above requirements or is there any workaround for this ?

Regex in schema json prevent connaisseur to validate signers with dash

Describe the bug

We have a container registry in azure where the signer's name is "mysigner-dev".

When we try to deploy an application from this registry the snapshot.json returns the list of the targets it includes the target/mysigner-dev the image is rejected with this error message:

ERROR: {'message': 'trust data has invalid format.', 'context': {'trust_data_type': 'snapshot', 'user': 'system:serviceaccount:ns:sa', 'operation': 'CREATE', 'kind': 'Deployment', 'namespace':
'mywebapp', 'name': 'mywebapp', 'image': 'myregistry.azurecr.io/webapp:0.1.20.0'}, 'detection_mode': True}

After some research, it appears that the code uses a regex which does not handle anything but words.

Expected behavior

Images are not rejected.

Optional: To reproduce

Add a signer with a "-" in its name or any char which is not a word as per the regex provided in the snapshot schema:

                "meta": {
                    "type": "object",
                    "patternProperties": {
                        "^(root|targets(\/\\w*)?)$": {

This can be easily reproduced through your unit tests.

Optional: Versions (please complete the following information as relevant):

• Kubernetes Cluster: k3s 1.19.4
• Notary Server: azure
• Container registry: azure
• Connaisseur: latest (1.4.0)

---

Ps: Your tool is really great and well made, thanks for the work you put into it! 💯

Helm installation fails with timeout on k8s 1.16.x

Describe the bug
Helm chart installation gets timed out waiting for readiness probe on k8s 1.16.x
Readiness probe fails maybe because MutatingWebhookConfigurations is not created at all in k8s 1.16.x

works fine on k8s 1.18.x as expected on the same setup.

Expected behavior
Helm chart installation succeeds and all 3 pods of the deployment are in ready state

Optional: To reproduce

Minikube

cd connaisseur/
sudo minikube start --driver=none --kubernetes-version=v1.16.15
sudo chown -R $USER $HOME/.kube $HOME/.minikube
make install
sudo minikube delete

sudo minikube start --driver=none --kubernetes-version=v1.18.0
sudo chown -R $USER $HOME/.kube $HOME/.minikube
make install
sudo minikube delete

Microk8s

cd connaisseur/
sudo snap refresh microk8s --classic --channel=1.16/stable
sudo microk8s start
sudo microk8s enable dns
sudo microk8s config > ~/.kube/config
make install
sudo microk8s stop

sudo snap refresh microk8s --classic --channel=1.18/stable
sudo microk8s start
sudo microk8s enable dns
sudo microk8s config > ~/.kube/config
make install
sudo microk8s stop

Optional: Versions (please complete the following information as relevant):

• OS: Ubuntu-18.04 on wsl2
• Kubernetes Cluster: microk8s-1.16/stable OR minikube-1.14(k8s-1.16.15, vm-driver=none)
• Notary Server: notary.docker.io
• Container registry: registry.docker.io
• Connaisseur: master
• Other:

Optional: Additional context

Add build step in CI

Describe the bug
Currently, the connaisseur image is built multiple times in the CI for different purposes (e.g. trivy scan, integration test). This has several disadvantages:

• time cost for building the image each time
• code duplication / higher maintanence due different solutions to build image
• if build fails, the specific scan or test fails which happens late in the ci, is non-intuitive and costs time

Expected behavior
Specific build step before or after tests to make sure image can be built, save time for later steps and reduce maintenance and code duplication.

Optional: To reproduce
See: https://github.com/sse-secure-systems/connaisseur/actions/runs/349660519

Please allow a values.yaml entry for notary port

Describe the feature
Along with the host, I think it would be nice to be able to specify the port.

Optional: Is your feature request related to a problem? Please describe.
Yes. By default, if you do your own notary, which I think a big reason many people will be looking to this the port will not always be 443, for example the demo I'm following it uses 4443:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='notary-server-svc.notary.svc', port=443): Max retries exceeded with url: /_notary_server/health (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fe50813f4f0>: Failed to establish a new connection: [Errno 111] Connection refused'))

I was able to specify the host but not the port.

Optional: Implementation ideas
Simply have an entry in the helm values file for notary.port (or something similar)

Optional: Additional context
If possible is there a place I can change in the meantime to force the port to be 4443 (or another port?) outside of the values file? could be a nice workaround

Integration test for validation in single namespace

We got #100 for enabling verification in namespaces (in contrast to for all namespaces). Functionality was manually tested, but we should add an integration test for that

Integration test

Would be nice if we had an integration test of at least roughly the setup guide. If it ran inside the pipeline that would be best, however as a start, local test script may be sufficient

CI does not properly report when failing

Some CI jobs do not report the actual problem when failing. This has been tested for:

• Safety
• Bandit

When failing, both Safety and Bandit do not show any output in the pipeline or upload the corresponding artefact. This complicates problem tracking, but does not pose a security issue, since the jobs still fail.

The problem is exemplified by #17 . The behavior should also be tested for Trivy.

Wanted outcome: Ideally, all CI jobs should explicitly display the problem in the pipeline and via uploaded artefact.

change webhook api version

Describe the bug
the webhook api version admissionregistration.k8s.io/v1beta1 is deprecated since kubernetes v1.16 in favor of api verison admissionregistration.k8s.io/v1. needs to be update.

Configurable bootstrap sentinel timeout

Describe the feature
Bootstrap sentinel timeout should be configfurable

Optional: Is your feature request related to a problem? Please describe.
Had the deployment timeout happen due to Connaisseur image not being pulled in time for the Bootstrap Sentinel to take effect

Reduce code repetition in Github Actions

Describe the feature
We have a lot of code duplication in Github Actions, especially with regards to the integration tests, that are run for both CICD and Release workflows and where both namespaced and "basic" integration test are very similar to each other

Optional: Implementation ideas
Github has the workflow_run option that would allow triggering an integration test workflow from both CICD and Release, but probably the workflow result would not be shown as part of the workflow, i.e. one has CICD running due to a PR, CICD triggers integration tests, then shows green checkmark regardless of whether integration test workflow succeeded or failed. <- All that's only theory, I didn't test it

Single format for configuration

Describe the bug
Connaisseur offers multiple configurations (alerting, validators, image policy) and all are stored in different formats (json, yaml).

Expected behavior
Use a single format to handle all configuration.

Document delegations feature

We have this nice feature of being able to require delegations for specific images. Yet, this feature gets promoted in a single sentence in the README and doesn't have documentation (outside code and tests). We should add some. Maybe ADVANCED_USECASES.md or the likes?

TLS Certificates Fix

The TLS certificates for connaisseur have subjectAltNames defined for them in the CSR config file, but they stll don't appear in the resulting certificates. This is caused by a known OpenSSL bug. These subjectAltNames are mandatory in Kubernetes v1.19 and need to be added or connaisseur will break.

Choose most recent digest for tag with multiple signatures

Describe the feature
If multiple signers sign the same tag, but for different digests (and not both of them are required as per image policy), Connaisseur should be able to choose the latest signed digest via release.json

Optional: Additional context
Probably needs subsequent changes to validation documentation as well

multiple notary support

Description
Currently only on notary server is configurable, where the trust data has to reside. This may not be pratical, since some users want to create signatures for their own images in a private notary and also use the public notary for all public images, without needing to pull in the public images into a private registry. Connaisseur should be able to retrieve trust data from more then one notary.

Implementation ideas
Add multiple entries for notary hosts in the values.yaml, each with it's own auth method and reference which host should be used for which kind of image in the ImagePolicy. Each rule gets a new host field, defining that all images matching this rule will have their signature data in the specified notary host.

Additional context
This is a follwoup to #82.

rebuild validator health check

Describe the feature
The validator health check should be reconsidered. It used to be called and logged when health probe is checked. This introduced an error and was for that reason removed: #166

Optional: Implementation ideas
the health checks could run as a separate periodic probe, potentially in a separate container, or as a separate thread.

This might be a good chance to reconsider the liveliness and readiness probe altogether

Support for Nexus

I am using Nexus instead of Harbor this means that when I am trying to pull an image the command will look like this:
"pull nexus.example.com:18079/hello-world:test"
I am getting the following error:
Error from server: admission webhook "connaisseur-svc.connaisseur.svc" denied the request: "nexus.example.com:18079/hello-world:test" is not a valid image format.
from what I understand the problem is with the validation of the path format. Is there a way to make Connaisseur work with Nexus?

Support for rsa, rsa-x509 and ecdsa-x509 on targets keys

Hey guys,

We're implementing connaisseur at our company, and we noticed that it doesn't support the use of rsa, rsa-x509 orecdsa-x509 keys, only ecdsa, in delegation roles, which correspond to targets in Notary's key hierarchy. Is there any particular reason for that?

Our understanding is that these should be supported, since it's stated at Content Trust's official tutorial that both cryptosystems could be used. The example in the documentation not only uses rsa, but its x509 form, in order to add the signer.

If this is something that cannot be implemented right now, I think it would be nice if connaisseur's documentation had this information stated somewhere. We had to manually compare our targets.json with targets_schema.json to find what we were doing wrong when trying to verify a signature.

Thanks in advance!

Test and setup guide for k3s

Compatibility with k3s should be checked and potential adjustments implemented: https://github.com/rancher/k3s/blob/master/README.md

Specifically for IoT solutions, ensuring authentication and integrity of code is critical, since the local network is not controlled.

Basic validation for public keys

Describe the feature
Do basic validation for loading public keys.

Implementation ideas
Currently the public keys are loaded into a internal dictonary called key_store as string in DER format. This is true for both the public keys that are coming from the root.json, as well as the pre-provisoned root public key. Validating them as soon as they are loaded will result in earlier error messages, should they have an invalid format, instead of the error messages occuring only when the actual signature validation is done. This also provides more precise error messages.

For a more concrete implementation idea: instead of storing the public keys as strings, we should store them as ecdsa.VerifyingKeys.

Verify cosign (code) signature

Describe the feature
Currently, we are injecting Cosign into Connaisseur as by #107. In the spirit of supply chain security, we may want to verify the signature of the source code.

Optional: Implementation ideas
We currently clone the cosign repo here: https://github.com/sse-secure-systems/connaisseur/blob/feat/cosign/docker/Dockerfile#L15
Within each release, there is hash and signature included and we may be able to go by that: https://github.com/sigstore/cosign/releases/tag/v0.2.0

Add public signature data for connaisseur itself to github repo

Describe the feature
The public signature information for connaisseur itself should be added to the github repository for Notary v1 and also Cosign

Optional: Is your feature request related to a problem? Please describe.
This would allow pinning the public key to the one provided via the Github repository

Optional: Implementation ideas
The pubkey files (for Notary v1, Cosign and future solutions) could be placed in the repo and a section providing the key and how to verify could be added to the README.md before 'Additional Information'. It could be similar to https://github.com/GoogleContainerTools/kaniko#verifying-signed-kaniko-images .

Support for multiple public keys

Does connaisseur have support for multiple root public keys? We need an admissions controller that checks signatures of several images on the Docker Hub (signed by the publishers) and of some images in a private registry (Harbor, signed ourselves). From what I could gather in the readme, it looks like Connaisseur only supports one public key, so we would be limited to checking the signature of a single source. Or do I misunderstand the way connaisseur or Docker Content Trust works?

Move connytest images into same docker repo as connaisseur

Describe the feature
Currently, the test images are hosted on docker.io/connytest/testimage. These should be moved into docker.io/securesystemsengineering/connaisseur or docker.io/securesystemsengineering/connytest

Optional: Is your feature request related to a problem? Please describe.
Would be more consistent than having a separate repo. However, makes the path much longer.

Optional: Additional context
Would require quite some changes and techincally also an update of the demo gif.

Connaisseur should not report ready if webhook not deployed during helm installation

If something breaks during the helm installation (or otherwise the webhook gets removed), but the connaisseur pods report a ready status, it is not apparent (e.g. when running kubectl get all -n connaisseur) that connaisseur is currently inactive and will not be blocking deployments with unsigned images or such with invalid signatures.

Connaisseur pods should report a non-ready status when there's no webhook using them.

Wrong documentation regarding null value in notary URL

https://github.com/sse-secure-systems/connaisseur/blob/master/helm/values.yaml#L24 state that the domain to the notary server can be null to use the public docker hub notary server. However, when set to null validation fails with

bash helm/certs/gen_certs.sh
Generating RSA private key, 4096 bit long modulus (2 primes)
.............................................................................................................................................................................++++
..............................++++
e is 65537 (0x010001)
Signature ok
subject=CN = connaisseur-svc.connaisseur.svc
Getting Private key
kubectl create ns connaisseur || true
namespace/connaisseur created
kubectl config set-context --current --namespace connaisseur
Context "**********" modified.
helm install connaisseur helm --wait
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: unknown object type "nil" in ConfigMap.data.NOTARY_SERVER
make: *** [Makefile:20: install] Error 1

We should either correct the documentation or make the value actually default to notary.docker.io

Implement a minimal load testing

Describe the feature
It might make sense to implement some minimal load testing like deployment of multiple images within one deployment or attempting to deploy several parallel deployments.

Optional: Implementation ideas
One might be able to simply re-use the integration test implementation.

setup guide only works with bash and is not explicit enough otherwise

Describe the bug
The steps to set the values in helm/values.yml in the setup guide (https://github.com/sse-secure-systems/connaisseur/tree/master/setup#3-configure-connaisseur) only work for bash and are not widely compatible.

Expected behavior
A more generic explanation should be added to make sure the setup is independent of the shell or OS.

Optional: To reproduce
Use e.g. Zsh to run the steps under: https://github.com/sse-secure-systems/connaisseur/tree/master/setup#3-configure-connaisseur

Optional: Versions (please complete the following information as relevant):
na

Optional: Additional context
na

Use Github's standardized code scanning interface for Actions

Github provides CodeQL as a standardized interface to scanning code in the CI. This simplifies implementation and reporting. Several scanners are available on the Marketplace, e.g.:

• https://github.com/marketplace/actions/bandit-check
• https://github.com/marketplace/actions/aqua-security-trivy

This could be used to enhance the current CI and also add periodic scans.

Deployment on Production Environment

Looking at the pod logs of Connaisseur during testing, it gives a warning related to the Flask server mentioning that a production WSGI should be used:

 * Serving Flask app "connaisseur.flask_server" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off

I went through the Connaisseur documentation to find out how it could be deployed on a production environment, but could not find anything related.

Could you please mention what is the right way to deploy Connaisseur on a production environment (EKS)?

helm-hook runs as unverified code

The helm hook which takes care of some management tasks (such as uninstall) runs as unverified code (it is currently not signed, and as a consequence we made an exception from validation).

Let's sign helm hook and enable verification in the default configuration.

installation error minikube

Describe the bug
Followed the installation procedure for the minikube setup but the logs from connaissuer pod throws below error

1, Installation error

Error: timed out waiting for the condition
make: *** [Makefile:20: install] Error 1

2. Logs from pod

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 2447, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1952, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1821, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.9/site-packages/flask/_compat.py", line 39, in reraise
raise value
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1950, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.9/site-packages/flask/app.py", line 1936, in dispatch_request
return self.view_functionsrule.endpoint
File "/app/connaisseur/flask_server.py", line 114, in readyz
notary_health = health_check(os.environ.get("NOTARY_SERVER"))
File "/app/connaisseur/notary_api.py", line 37, in health_check
response = requests.get(**request_kwargs)
File "/usr/local/lib/python3.9/site-packages/requests/api.py", line 76, in get
return request('get', url, params=params, **kwargs)
File "/usr/local/lib/python3.9/site-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.9/site-packages/requests/sessions.py", line 530, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.9/site-packages/requests/sessions.py", line 643, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.9/site-packages/requests/adapters.py", line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='notary.harbor.domain', port=443): Max retries exceeded with url: /_notary_server/health (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fa943883f40>: Failed to establish a new connection: [Errno -2] Name does not resolve'))

INFO: 172.18.0.1 - - [11/Nov/2020 14:26:26] "GET /ready HTTP/1.1" 500 -
[2020-11-11 14:26:29,374] INFO: 172.18.0.1 - - [11/Nov/2020 14:26:29] "GET /health HTTP/1.1" 200 -

Optional: Versions (please complete the following information as relevant):

• OS: Ubuntu 20.04
• minikube version: v1.13.1 - driver=docker
• kubernetes version : v1.18.9