Threat Model

DEPRECATION WARNING

The threat model is OUTDATED and does not reflect the currently applicable architecture. It still serves as a general guidance to relevant threats.

The STRIDE threat model has been used as a reference for threat modeling. Each of the STRIDE threats were matched to all entities relevant to Connaisseur, including Connaisseur itself. A description of how a threat on an entity manifests itself is given as well as a possible counter measure.

images created by monkik from Noun Project

(1) Developer/User

Threat	Description	Counter Measure
Spoofing	A developer could be tricked into signing a malicious image, which subsequently will be accepted by Connaisseur.	Security Awareness: Developers need to be aware of these attacks, so they can spot any attempts.
Elevation of privilege	An attacker could acquire the credentials of a developer or trick her into performing malicious actions, hence elevating their privileges to those of the victim. Depending on the victim's privileges, other attacks may be mounted.	RBAC & Security Awareness: With proper Role-Based Access Control (RBAC), the effects of compromising an individual's account would help limit its impact and may mitigate the privilege escalation, of course depending on the victim's access level. Other than that, a security awareness training for developers can help minimize the chances of losing critical credentials.

(2) Connaisseur service

Threat	Description	Counter Measure
Spoofing	An attacker could stop the original Connaisseur service and start their own version, to take over the admission controller's responsibilities. That way, the functionality of Connaisseur could be completely disabled or altered at will.	RBAC: By only permitting a carefully selected group of people to start and stop services in the Connaisseur namespace, such attacks can be prevented.
Tampering	Given an attacker has access to the Connaisseur container, she could tamper with its source code, leading to forged responses or full compromise. The attacker could also stop the the original Connaisseur process and handle incoming requests some other way, which would be similar to the spoofing threat, but from inside the Connaisseur container.	RBAC + Monitoring: Access to the inside of the container can be restricted with RBAC, so an attacker never gets there in the first place. In case the attacker already is inside the container, there are specific monitoring tools (e.g. falco), which are able to register changes inside containers and notify you, should Connaisseur be compromised.
Tampering	An attacker could modify Connaisseur's image policy to bypass signature verification and inject malicious images. Alternatively, the public root key could be replaced, allowing fake trust data to pass as legit. Lastly, the admission controller could be simply deactivated by deleting the webhook.	RBAC + Monitoring: An RBAC system can prevent unauthorized changes to both the image policy and public root key. Additionally, the Connaisseur readiness probe checks the availability of the webhook and will be set to Not Ready should the webhook not be present. Monitoring should still be used to keep track of the admission controller's webhook availability status, as setting up a fake connaisseur-bootstrap-sentinel pod in the connaisseur namespace can bypass that readiness probe check. More on that in an upcoming architectural decision record.
Denial of service	When sending an extraordinary amount of requests to Connaisseur or triggering unexpected behavior, Connaisseur might become unresponsive or crash. As a result, image signatures can't be verified.	Failure Policy: The webhook that is connected to Connaisseur denies all request automatically, should the Connaisseur service be unavailable. Thus, malicious images cannot enter the cluster. Additionally, multiple instances of Connaisseur can be run for better load balancing.
Elevation of privilege	Since Connaisseur interacts with the Kubernetes API, an attacker located inside the Connaisseur container can act on its behalf and use its permissions.	RBAC: Per default, the Connaisseur service account only has read permissions to a few non-critical objects.

(3) Notary server

Threat	Description	Counter Measure
Spoofing	An attacker could mount a Monster-in-the-Middle attack between Notary and the Connaisseur service and act as a fake Notary, sending back false trust data.	TLS: A TLS connection between Connaisseur and Notary ensures the Notary server's authenticity.
Tampering	With full control over the Notary server, the stored trust data can be manipulated to include digests of malicious images.	Signatures: Changing the trust data would invalidate the signatures and thus fail the image verification. Additionally, the keys needed to create valid signatures are not stored in Notary, but offline on client side.
Information disclosure	As Notary is responsible for creating the snapshot and timestamp signatures, an attacker could steal those private keys, and create valid snapshot and timestamp signatures.	Key rotation: The snapshot and timestamp keys can easily be rotated and changed frequently. The more cirtical root and target key are not stored on server side.
Denial of service	An extraordinary amount of requests to the Notary server could bring it down so that the Connaisseur service has no more trust data available to work with.	Health Probe: Connaisseur's readiness and liveness probes check the Notary server's health every few seconds. Should Notary be unavailable, Connaisseur will switch into a not-ready state. As a consequence, the failure policy will automatically deny all requests.

(4) Registry

Threat	Description	Counter Measure
Spoofing	An attacker could mount a Monster-in-the-Middle attack between the registry and the Kubernetes cluster and act as a fake registry, sending back malicious images.	TLS: A TLS connection between the Kubernetes cluster and the registry ensures that the registry is authentic.
Tampering	With full control over the registry, an attacker may introduce malicious images or change the layers of existing ones and thus inject malicious content.	Image Digests: Introducing new images does not work as Connaisseur selects them by digest. An attacker would have to change the content of the corresponding digest layer, while the changes need to produce the same digest. Such a hash collision is considered practically impossible. If digests differ, the docker daemon underlying the cluster will deny the image.
Denial of service	An extraordinary amount of requests to the registry could bring it down, so that no images can be pulled from it.	Out of scope: This threat is specific to registries, not Connaisseur.