[Feature] First-class curated OCI registry in Cozystack: group RBAC, approvals, and CVE policy

[suse-coder]

Summary

Make Cozystack’s existing managed Harbor application a first-class curated OCI registry. Operators should be able to control who can publish, review and consume OCI artifacts; automatically scan them; apply vulnerability and trust policies; and promote only approved artifacts into a protected catalog.

This should build on the Harbor app already packaged in Cozystack rather than introduce another registry. The initial scope is OCI images and artifacts, not a replacement for every package format supported by JFrog Artifactory (such as Maven, npm or PyPI).

Problem

Cozystack packages Harbor and enables its Trivy scanner, but the Cozystack Harbor app currently exposes mostly deployment and resource settings. Project membership, group-based access, scan-on-push, severity thresholds, CVE exceptions and other Harbor project policies are not represented as Cozystack-managed desired state. As a result, teams can deploy a registry but must separately configure and maintain the security and curation workflow.

A registry used by multiple teams needs more than scan reports. It needs a reliable way to ensure that:

• users and CI jobs can write only to the projects they own;
• consumers can pull only the private or curated projects they are authorized to use;
• vulnerable, unscanned, unsigned or unapproved artifacts do not enter the trusted catalog;
• exceptions are explicit, reviewable and time-limited; and
• security decisions can be audited and re-evaluated when scanner results change.

Proposed behavior

1. Declarative identity and project access

• Support Harbor authentication through the Cozystack platform OIDC/Keycloak provider when enabled, or a documented external OIDC/LDAP provider.
• Map identity-provider groups to Harbor projects and roles. Keep Harbor’s native individual-user and robot-account options available where appropriate.
• Allow private projects to be created for teams, tenants, products or trust levels.
• Support least-privilege project roles, including read-only access for consumers and narrowly scoped, expiring robot credentials for CI.
• Keep project and identity boundaries tenant-scoped; platform-wide policy should not grant one tenant access to another tenant’s artifacts.

2. Staging, review and promotion

Provide an optional curation workflow, for example:

1. A user or CI robot pushes an artifact to an incoming/staging project.
2. Harbor scans it and evaluates applicable policy.
3. If the scan passes, designated reviewer group(s) can approve or reject it. Approval should record the reviewer, time, artifact digest and policy result. Optionally require that an approver is not the artifact’s uploader.
4. Only an approved artifact is promoted by digest to a curated/release project. The promoted digest must be identical to the reviewed artifact.
5. Consumer groups receive pull access to the curated project; only the promotion service or another explicitly authorized publisher can push there.

Approval should fail closed: a missing or failed scan must not count as a passing result. Rejection, rescanning and revocation should be auditable. The interface may be provided through Cozystack’s UI, Harbor UI/API, or both, but the workflow should be supported and documented as a Cozystack feature.

3. Declarative security policies

Allow platform operators to set an inherited baseline and, where permitted, project-specific policies for:

• scan on push and periodic rescanning;
• maximum allowed vulnerability severity, with a configurable action such as warn, block promotion or block pull;
• behavior for unscanned artifacts and scanner errors;
• system and project CVE allowlists, with a justification, owner and expiry for exceptions;
• required Cosign/Notation signature verification and, where practical, provenance/SBOM requirements;
• optional approved upstream registries or proxy-cache sources for curated content.

A newly discovered CVE that breaches policy should cause an alert and re-evaluation of the artifact’s approval. Administrators should be able to choose whether this blocks future pulls, revokes promotion status, or requires re-approval.

4. Registry governance and operations

• Support tag immutability for release projects, project quotas, retention/cleanup policies and audit retention.
• Emit webhooks or notifications for scan completion/failure, policy violations, approvals, rejections and revocations.
• Provide a documented, reconciled configuration path (Cozystack API/CRD and/or supported automation). Manual Harbor changes should not silently undermine an enforced Cozystack policy.
• Preserve Harbor’s OCI compatibility and support scoped project robot accounts for build and promotion pipelines.

Acceptance criteria

• An operator can configure group-based Harbor login and project membership using the platform OIDC provider when enabled, or a supported external provider.
• A tenant/team can have a private project with distinct read, write, administration and review permissions.
• A policy can enable scan-on-push and define a vulnerability threshold and behavior for missing/failed scan results.
• CVE exceptions require a reason and can expire; exceptions and policy changes are included in the audit trail.
• Artifacts in staging cannot be promoted to the curated project until scan policy passes and the required approval(s) are recorded.
• The approved artifact is promoted by immutable digest; only designated publishers can write to the curated project, and consumer groups can be granted pull-only access.
• A later scan or policy change can flag an already-approved artifact and trigger the configured response.
• CI can use scoped robot credentials, with revocation/rotation and expiry documented.
• The configuration is documented, tested, and reconciles safely across Harbor upgrades and Cozystack upgrades.

Non-goals

• Replacing Harbor with a new registry implementation.
• Replacing Artifactory for non-OCI package ecosystems such as Maven, npm or PyPI.
• Treating a successful vulnerability scan as a complete security guarantee. Cluster admission controls may still be needed to ensure workloads use approved images.

Implementation note

Harbor already provides much of the underlying capability—Trivy scanning, project RBAC, OIDC/LDAP group membership, CVE controls, robot accounts and signature policies. The Cozystack feature would make these controls configurable, tenant-aware, auditable and reproducible instead of leaving them as post-install manual setup.

An illustrative API could describe projects, identity groups, scanner policy and curation stages declaratively. The exact CRD shape is open for design; the key requirement is that policy and approval state be safely reconciled rather than implemented as an untracked one-time script.

Current implementation references

• Cozystack Harbor app: packages/apps/harbor
• Harbor values, including the Trivy component: values.yaml
• Cozystack issue documenting the limited Harbor resource surface and missing upstream configuration knob: #3972
• Harbor project vulnerability settings: Harbor 2.15 documentation
• Harbor project user/group membership: Harbor 2.15 documentation