Skip to content

Roadmap: Expand OCI Registry Provider Coverage #6436

@evankanderson

Description

@evankanderson

Please describe the enhancement

This is a Roadmap Epic, and needs to be broken into smaller issues

In addition to adding support for Git Forges (where the Minder entity model is
well-tested), Minder has some support for artifact repositories (primarily OCI
repositories such as GHCR and DockerHub). This should be expanded, possibly
following the "rule-driven child entities" work in #6105
to enable automatic generation of dependent entities given a known parent.

Additionally, further work should be done to enable managing OCI registry
security properties:

  • Verify settings (immutable tags, MFA enabled, permissions, etc) for
    repositories and possibly hierarchical namespaces
  • Establish best practices for credential handling for remote OCI registries
  • Expand support for validating both
    artifacts and
    config contents as well as via the
    referrers API

Concrete OCI registries which may need specific implementations (particularly
around credential handling; possibly also enumeration of registries, namespaces,
and repositories) include:

  • Major Cloud Providers (AWS ECR, Google GCR, Azure ACR, etc)
  • Major OSS Providers (Quay.io, Harbor, GHCR, DockerHub)

Solution Proposal

  • Document configuration of OCI registry providers
  • Add support for repositories as well as artifacts
    • Add support for configuring per-registry API settings such as immutable tags on a per-repository basis
  • Add support for at least 3 more OCI registries
  • Document (example rules + documentation) checking at least 3 additional artifact properties besides sigstore signatures on an artifact. These should be checked using either the JQ or Rego engine, possibly using DataSource integration if additional data is needed (like the referrers API for SBOMs). Possible sample rules:
    • All container images support x86 and ARM64 architectures
    • Tagged images have SBOMs which contain a common minimum set of elements
    • Image layers are below a size limit, with a max number of layers

Describe alternatives you've considered

No response

Additional context

No response

Acceptance Criteria

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    epiclarge bodies of work that can be broken down into a number of smaller tasksfeature-request
    No fields configured for Feature.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions