Summary

Currently, Argo CD supports obtaining manifests from either a Git repository, a Helm chart repository, or a Helm chart stored within an OCI registry. Given that OCI registries are more frequently being used to store content aside from container images, introduce a mechanism for storing and retrieving manifests that can be used by any of the existing supported tools in any of the supported methods of representing assets that are to be applied to a Kubernetes environment.

Motivation

Implementation of the Native OCI Support proposal.

Proposal

High Level Plan

Define baseline primitives

Prior to the implementation of this proposal, several baseline primitives need to be discussed and agreed upon.

1. Tooling for managing OCI Content
   ORAS (OCI Registry as Storage) is a CLI tool and library for managing arbitrary content in OCI registries. Not only does it contain the features necessary for implementing OCI support in Argo CD, it is already being used both in several other Open Source projects, including Helm as well as Argo CD itself.
   .
   ORAS/Argo CD Integration
   .

2. Packaging Format
   To enable maximum compatibility with the existing features of Argo CD, content stored within OCI artifacts should be in a format representable as to current methods for managing content. The result is a gzipped compressed tar archive containing resources that can be utilized by any of the supported tools in Argo CD..

3. OCI Attributes
   The Open Container Initiative makes extensive use of Media Types in order to describe content and how they should be managed. The OCI Image Specification (image-spec) provides guidelines for how Artifacts should be organized and described.
   .
   Given that the goal of this effort is to provide first class support for OCI content, two (2) new OCI Media Types will be introduced:

• application/vnd.cncf.argoproj.argocd.content.v1.tar+gzip - Primary asset stored within the OCI artifact containing a gzip compressed tar archive of Argo CD resources. Further details are outlined in the prior section.
• application/vnd.cncf.argoproj.argocd.config.v1+json - An OCI Image Configuration

Task Breakdown

1. Developing an OCI Client (using ORAS (OCI Registry as Storage))
   a. Pulling from OCI registry
   b. Packaging
   c. Creation and extraction
   d. Publishing to OCI registry

2. ArgoCD to accept OCI repository sources
   We can start by supporting the OCI repositories without CLI and GUI support. Users can apply an ArgoCD application via kubectl commands. We did a similar exercise for Multiple sources application. UI and CLI support can be included as a follow-up to the OCI support itself. To support OCI, we would need the below changes:

   1. Credential Management (Repository Secret)
      1. Investigate appropriate methods for managing authentication to OCI registries
         1. Introduce new mechanisms or build upon existing functionality
         2. Differentiation between OCI based Helm Charts?
            1. repo-creds secret type can probably be reused
   2. Repo Server Integration
      1. Investigate feasibility of defining new interface for managing content sources (Git/Helm/OCI)
      2. Develop capabilities to generate manifests from OCI source
      3. Ensure path transversal is maintained/handled
   3. Webhook Integration
      1. Accept reception via invocation from OCI registries
      2. Investigate payloads from major OCI registries (DockerHub, Quay, GitHub Container Registry, Google Container Registry, etc) to determine requirements
      3. Define new key(s) in argocd-secret for OCI webhook support

3. Argo CD CLI support / integration

   1. Check / Update existing commands to work for OCI registries
   2. Add oci subcommand (additional enhancement to make it easier for users)
      1. Packaging
      2. Publishing
         1. Optionally accept content produced/provided by external tooling/process
      3. Retrieving
      4. Optional extraction

4. User Interface Enhancements

   1. Application Create and Details page to be updated
   2. Implementation of enhancements to user interface
      1. Credentials
      2. Certificates
   3. Investigate where additional changes are required to support native OCI management