P2P image registry
Path to Production builds images in fast feedback and deploys by version tag. The cluster registry supports CI build, push, scan, promotion and Kubernetes image pulls on managed k3d and GKE Standard clusters.
Shared cluster registry
When a repository sets CORECTL_CONTEXT, its P2P build job uses the platform’s
shared cluster registry and corectl OIDC cluster access. Portal assigns the
image prefix from the organisation unit and delivery unit. The application
supplies only the image name and version:
127.0.0.1:5000/<org-unit>/<delivery-unit>/<stage>/<image>:<version>corectl p2p registry connect opens a registry-only connection over the
existing private cluster VPN and binds 127.0.0.1:5000 on the CI runner.
It uses a separate Portal session from corectl connect --oidc github, which
reaches the private Pinniped proxy for Kubernetes access. Both sessions can be
active in one job; neither can select an arbitrary in-cluster destination. The
registry session reaches only the cluster registry Service, without a Kubernetes
API port-forward. Docker and Skopeo publish through the loopback port. P2P runs
corectl p2p registry login to authenticate both clients to that local
connection. Corectl renews the job’s short-lived GitHub OIDC token as needed
while uploading, so large images can take longer than one token lifetime. Zot
still checks the job identity and repository permissions on each request. The
connect command only opens the tunnel. P2P closes the session and removes its
local credentials with corectl p2p registry disconnect after the job. No
registry credential is stored as a GitHub secret. Reconnect any existing
registry tunnel after upgrading corectl.
On each Linux node, a platform-managed proxy binds the same 127.0.0.1:5000
address for kubelet pulls and connects to the registry over mutual TLS. Apps
use the image reference above without imagePullSecrets or containerd changes.
The registry permits pulls only from active application prefixes. This is a
cluster-wide pull identity; it does not isolate images by namespace.
Deployment jobs require the matching P2P workflow and managed cluster release. Every enabled managed registry supports both publishing and Kubernetes pulls. The cluster’s registry Deployment and node proxy DaemonSet must be ready before testing deployment. Port 5000 must be free on every Linux node. GKE Autopilot is unsupported; EKS and AKS validation is planned as a follow-up.
The repository-level CORECTL_CONTEXT variable selects the corectl OIDC and
cluster registry path for generated application workflows. The managed cluster
installs the private CI registry and node pull proxies by default. It requires a
default StorageClass and an exact trusted P2P workflow ref. The build job obtains its image prefix
from Portal, so the application repository does not need ZOT_* variables for
this step. Without CORECTL_CONTEXT, the existing GKE and
Artifact Registry workflow remains in use.
The registry authorizes trusted P2P publishers only for the application’s assigned prefix. Unknown or revoked repository identities cannot open the private connection or publish. CI reader permissions remain separate from publisher permissions. Version tags remain the deployment contract.
If the platform changes an application’s assigned prefix, publish images in the new location. The old prefix becomes unavailable after authorization is revoked.