Typo fix

Scarf proposal

Signed-off-by: David Noyes <david.noyes@venafi.com>

design/20240122.scarf.md

@@ -0,0 +1,54 @@
+# Proposal: Scarf.sh integration
+
+<!-- toc -->
+- [Summary](#summary)
+  - [What is Scarf?](#what-is-scarf)
+- [Motivation](#motivation)
+  - [Goals](#goals)
+- [Proposal](#proposal)
+  - [How will this change impact our users?](#how-will-this-change-impact-our-users)
+  - [Known issues/limitations](#known-issueslimitations)
+<!-- /toc -->
+
+## Summary
+
+With our focus on CNCF graduation, CNCF aims for its projects to become vendor-neutral wherever possible. The cert-manager project should uphold this aim. In doing so, it will need to take a further step to move on from its proud Jetstack legacy with a change to remove Jetstack from the container image repository name. Recently partnered with the Linux Foundation, Scarf is a service designed for open-source projects that will allow us to perform this migration seamlessly. In addition, Scarf will provide the benefit of not being tied to a single container image/binary repository vendor, giving us the freedom to change vendors and continue to provide container images seamlessly while still maintaining observability of how the project is downloaded.
+
+### What is Scarf?
+
+The open-source Scarf Gateway is the power behind the Scarf platform. The Scarf Gateway serves as a centralised point of access for the distribution of containers and packages, regardless of their actual hosting location. The Gateway is positioned before an existing registry to reroute download traffic to the storage location while providing essential usage data that the registry does not readily share. It is understood that the Scarf gateway will not act as a full proxy for all image data to pass through but only as a proxy for image metadata, redirecting the download client to the actual hosting location, such as quay.io.
+
+## Motivation
+
+### Goals
+
+- Discontinue using the name "Jetstack" in all container image downloads.
+- Continue to provide non-breaking changes for those already using the existing "Jetstack" container image download locations.
+- Gain the freedom to change image repositories with ease when necessary.
+- Improve observability and reporting to maintainers of how cert-manager is downloaded to serve its users better.
+
+## Proposal
+
+- Obtain a new custom "download" domain through the CNCF to be used for fronting all binary downloads.
+- The creation of a Scarf account will be configured and managed by the cert-manager maintainers.
+- Update documentation referencing "jetstack" binary paths e.g. quay.io/jetstack/cert-manager-controller, and replace with the new download domain.
+- Update helm charts referencing "jetstack" binary paths, replacing with the new download domain.
+- Update code referencing "jetstack" binary paths, replacing with the new download domain.
+- Add Scarf pixels to selective documentation pages, giving us insight into which pages are most useful or areas to focus on for improvement.
+- Automate regular analytics gathering leveraging the Scarf API to publish relevant stats and info publically. E.g.
+  - Region
+  - Operating System
+  - Container Tags / Versions
+  - Container Runtimes
+
+
+### How will this change impact our users?
+
+Images and binaries should continue to be accessed from their existing locations. Therefore, there should be no impact on any existing downloads, automation, or mirroring.
+Going forward, we would encourage users to use the new download paths by specifying the new domain in the documentation.
+
+Any users downloading from secure environments with limited internet connections through firewall restrictions will need to add "allowed" rules for the Scarf gateway domain in addition to any existing rules for the image repository, such as quay.io. These should be clearly documented.
+
+### Known issues/limitations
+
+- Currently the Scarf service only allows for custom domains and doesn't include custom paths. When speaking with members of the Scarf organisation, this is due to a technical limitation as the path is used in the image identification/verification process. Scarf is investigating a workaround; however, we may need to consider an additional hosting location/service to allow us to remove "jetstack" from the download path. An additional hosting location will increase existing maintenance and deployment process overheads.

design/template.md

@@ -1,5 +1,5 @@
 <!--
-This template is adapted from Kubernetes Enchancements KEP template https://raw.githubusercontent.com/kubernetes/enhancements/a86942e8ba802d0035ec7d4a9c992f03bca7dce9/keps/NNNN-kep-template/README.md
+This template is adapted from Kubernetes Enhancements KEP template https://raw.githubusercontent.com/kubernetes/enhancements/a86942e8ba802d0035ec7d4a9c992f03bca7dce9/keps/NNNN-kep-template/README.md
 -->
 
 # CHANGEME: Title