Home¶
What is Artifact Conduit (ARC)?¶
ARC (Artifact Conduit) is an open-source, Kubernetes-native orchestration layer for moving artifacts — container images, Helm charts, software packages, and other resources — from external sources into restricted environments where direct internet access is prohibited. An Order declares which artifacts to transfer; ARC resolves the referenced endpoints and credentials and runs an operator-authored Argo Workflows template for each artifact.
System Architecture¶
ARC is implemented as a Kubernetes Extension API Server integrated with the Kubernetes API Aggregation Layer. This architectural approach provides several advantages over Custom Resource Definitions (CRDs), including dedicated storage isolation, custom API implementation flexibility, and reduced risk to the hosting cluster's control plane.
Architecture: ARC System Components and Data Flow
The system follows a layered architecture where users interact through the Kubernetes API, requests flow through the Kubernetes API aggregation layer to the ARC API Server, and the Order Controller orchestrates workflow execution by decomposing high-level Orders into executable ArtifactWorkflows.
ARC isn't a workflow engine itself but uses Argo Workflows to orchestrate the workflows. This enables operators to define and execute complex workflows without needing to write custom code.
Core Concepts¶
ARC introduces four primary custom resource types under the arc.opendefense.cloud/v1alpha1 API group:
| Resource | Purpose | Scope |
|---|---|---|
| Order | Declares intent to procure one or more artifacts with shared configuration defaults | User-facing, high-level |
| ArtifactWorkflow | Represents a single artifact operation decomposed from an Order | System-generated, execution unit |
| Endpoint | Defines a source or destination location with credentials | Configuration, reusable |
| ArtifactType | Specifies processing rules and workflow templates for artifact types (e.g., "oci", "helm") | Configuration, system-wide |
---
config:
layout: elk
---
flowchart LR
subgraph subGraph0["Declarative Layer"]
Order["Order (User Input)"]
Spec["spec:<br>- defaults<br>- artifacts[]<br>--- <br>status:<br>- endpointGenerations<br>- secretGenerations"]
end
subgraph subGraph1["Generated Layer"]
ArtifactWorkflow1["ArtifactWorkflow-1<br>(Minimal Params)"]
ArtifactWorkflowN["ArtifactWorkflow-N<br>(Minimal Params)"]
end
subgraph Configuration["Configuration & Secrets"]
ArtifactTypeDef@{ label: "ArtifactType (e.g., 'oci')" }
EndpointSrc["Endpoint (Source)"]
EndpointDst["Endpoint (Destination)"]
EndpointSecret@{ shape: procs, label: "Secrets (e.g. Credentials)"}
end
subgraph Execution["Execution"]
WorkflowTemplate["WorkflowTemplate (Argo)"]
WorkflowInstance1["Workflow Instance"]
end
Order -- contains --> Spec
Spec -- generates --> ArtifactWorkflow1 & ArtifactWorkflowN
Spec -- reads --> EndpointSrc & EndpointDst & EndpointSecret
Spec -- type, tracks generation of --> ArtifactTypeDef
ArtifactWorkflow1 -- srcRef --> EndpointSrc
ArtifactWorkflow1 -- dstRef --> EndpointDst
EndpointSrc -- secretRef --> EndpointSecret
EndpointDst -- secretRef --> EndpointSecret
ArtifactTypeDef -- workflowTemplateRef --> WorkflowTemplate
ArtifactWorkflow1 -- references --> EndpointSecret
ArtifactWorkflow1 -- instantiates --> WorkflowInstance1
ArtifactWorkflow1 -- workflowTemplateRef --> WorkflowTemplate
WorkflowInstance1 -- mounts --> EndpointSecret
ArtifactTypeDef@{ shape: rect}
Quickstart¶
Features¶
What ARC provides¶
- Declarative API:
Order,Endpoint, andArtifactTyperesources, managed withkubectlor GitOps - Endpoint and credential handling: Reusable source and destination endpoints with referenced credentials, usage constraints, and reachability probing
- Validation:
Orders are checked on admission and against endpoint andArtifactTyperules before any workflow runs - Idempotency: Each artifact is identified by a hash of its definition, so unchanged artifacts are not re-run and changed ones get a new workflow
- Orchestration: One workflow per artifact, which ARC creates, tracks, schedules, and cleans up
- Aggregated status: Per-artifact progress reported in the
Orderstatus, plus Prometheus metrics - Custom artifact types: Operators define
ArtifactTypes, each bound to a workflow template and parameters
What ARC enables operators to build¶
Pulling, scanning, verifying, and pushing artifacts happen entirely inside the Argo workflow template an ArtifactType references, which operators author. ARC passes the template its parameters and the endpoint credentials as workflow volumes; the template defines all artifact handling, for example:
- Pulling from OCI registries, Helm repositories, S3-compatible storage, or HTTP endpoints
- Malware scanning, CVE analysis, license checks, and signature verification
- Blocking transfer of artifacts that fail security and compliance policies
- Producing attestations or reports as workflow outputs
ARC ships no workflow templates. The templates in the
examplesdirectory illustrate the integration and are not production-ready. See Extending Artifact Types for writing custom templates.
Out of Scope: ARC does not replace existing registry solutions or artifact repositories, nor does it implement transfer or scanning logic itself. It coordinates artifact transfer between existing infrastructure components through operator-authored workflow templates.