Choose Cosign over Notary
Tags: notary, cosign
Published: 2022-03-19 15:20:32

## Disclaimer
This article is not trying to compare the pros & cons between Cosign and Notary. Rather, it is a sharing that you should opt-in Cosign if you have some technical needs like I do.

I also attached some websites at the end of this article. I recommend you to read these websites before you move on. 

## Introduction
You might be heard of SolarWinds hack and you know what is Software Supply Chain Attack. And so-called software can include libraries, linux packages, plugins, etc. 

As there are many softwares distributed every single second worldwide, it becomes a hot topic that how we can trust the software we downloaded is safe. One idea is that we want someone we trust to make a claim by signing their signiture to the software. And everytime we want to download/update the software, we will check whether the signiture exists.

For example:
- Software authors can sign the software to claim that it is a authroized release.
- Secuirty auditors can sign the software to claim that it has passed their secuirty audit.
- Inhouse secuirty team can sign the software to claim that it is authroized to be used inside the company.

One of the major software type that we are so familar are container images. Cosign and Notary both are mainstream solutions for signing container images. 

> There are Notary/v1 and Notary/v2. Notary/v2 is not ready for general use so I won't talk much about it. In this article, when you see the term Notary, I am referring to Notary/v1.

## Considerations

### Able to sign any OCI artifacts

In the past, when we say we publish something to the registry, we always refer to container images. However it does not apply anymore. Nowadays many modern registries are OCI compatible, where we are free to store any OCI artifacts. And more amazingly, any arbitary file can be stored as an OCI artifact. Theotically, you can even store a video to OCI registries.

If you are working on K8S cluster, you should be familar with helm charts. And yes, you can store helm charts to OCI regitry. It is vital because we can reuse the CI/CD mindset that we apply to docker images, to helm charts. It works like a charm when we pair with GitOps.

So now you are so care about the safety of your software supply chain, and it is natural that you want all container images to be signed. What about helm charts? You probably want helm charts to be signed too. (I hope no one will think that unauthorized release of helm charts is trivial.) 

Now I can tell you that you should just go for Cosign and leave Notary alone. Why? **Notary only can be used to sign container images, not OCI artifacts.**

In additional to helm charts, you can store SBOMs, image scanning results as OCI artifacts with your container images. The use cases of OCI are far more than you can imagine.

> OK. You might tell me that you do not use helm charts at all. Then should you still consider Notary? Continue to read the following section.

### Easy to use

So now you want to sign your container images. Definately you want to do it in a automation style (please agree on me). And I can tell you that Cosign is absolutely better than Notary with no doubt.

Cosign itself is a binary. You can install it using any package managers like homebrew and apt. It also means you can use it in any CI/CD solution like Github Actions, Azure Pipeline by adding a step to install it. 

**Using Cosign is super simple.**

1. Use Cosign to generate a keypair in local environment.
2. Store the generated private key inside your CI/CD platform. 
3. Use Cosign to sign your OCI artifacts. 

```
cosign generate-key-pair
cosign sign --key cosign.key dlorenc/demo
```

---

On the contrary, Notary requires you to self-host a Notary service. 

**Here are some issues you should be aware of.**

#### Learning Curve

Notary is based on the TUF framework. TUF is powerful. The alternative word of powerful is complicated. You have to understand how TUF works to make a proper use of Notary. 

> After you have spend (so much) time to understand TUF well, are you ready to educate your users what TUF is?

#### Setup complexity

A Notary service consists of Notary server, Notary signer, Notary client, MySQL database. And you also need to setup MTLS between Notary server and Notary signer. It might not be a big issue, but it is still an effort you should pay attention to.

> Some people might argue that the setup is simple. However be mindful of Cosign, it just requires you to install a binary.

#### Operational burden

How are you going to handle if your Notary service is unavailable? Your pipelines might be broken when it can't verify signiture of the container images, and then all your downstream deployments screw up. 

> Some of you might be so experienced in designing a HA solution, and can taking a good care of the MySQL database in case of region outage. However I will prefer to use risk avoidance strategy by not using Notary.

#### Network connectivity 

Notary service is critical. Unless you are releasing container images to the public, most probably you are hosting Notary as an internal-facing service to reduce attack surface. 

If you are using public worker in your CI/CD solution, now you have to deploy some self-hosted workers such that it can reach your Notary service.

> Cosign does not have this issue.

#### Secret management
You have to manage a set of secrets, such as TLS certificates and TUF keys. 

> For Cosign, you also need to manage the private key. It is obviously much simpler than Notary.

---

Now you can think about is the advantage of using Notary outweight the effort you spend on it? 

To me, the answer is **NO**.

## Conclusion

Although I opt in for Cosign, I do not think Notary is bad. As I have mentioned, TUF (Notary) is powerful. If your team have resources to well-study TUF and want to secure container image supply chain as much as possible, using Notary is a good choice to you. And I do encourage people to learn what TUF is even you do not use Notary.

In the future, I will write another article to explain how you can use Cosign to secure helm chart K8S deployment.

## Fun 

### Status of Notary/v2

There are other issues come with Notary/v1. This is why Notary/v2 project is proposed. Notary/v2 has released its first alpha version, the implementation is called [Notation](https://github.com/notaryproject/notation). Personally, I think the user experience of using Notary/v2 is so similar to Cosign.

### Try Notary/v1

DockerHub is hosting an offcical Notary server in https://notary.docker.io and you can verify all offical published images listed in [here](https://hub.docker.com/search?q=&type=image&image_filter=official).

Verifying the offical alpine image
`notary -s https://notary.docker.io -d ~/.docker/trust list docker.io/library/alpine`

## Readings
[What is OCI?](https://dlorenc.medium.com/oci-artifacts-explained-8f4a77945c13)
[What is SBOMs?](https://www.cloudsavvyit.com/14680/how-to-index-your-docker-images-dependencies-with-syft/)
[Publish helm charts to AWS ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)
[What is TUF?](https://theupdateframework.io/)
[Notary/v2 v.s Notary/v1](https://www.cloudsavvyit.com/14716/how-docker-image-signing-will-evolve-with-notary-v2/)
[Notary/v2 v.s. Cosign](https://dlorenc.medium.com/notary-v2-and-cosign-b816658f044d)