Accessing the Registry
Use this page to access Alauda Container Platform Registry from inside the cluster, from external clients, and through the Image API.
TOC
PrerequisitesRequired Namespace PermissionsAccess the Registry from Inside the ClusterAuthenticate an External OCI ClientPush and Pull ImagesQuery Image API ResourcesPrerequisites
- Alauda Container Platform Registry is installed and available in the target cluster.
- The image namespace exists.
- The current user or service account has the required namespace permissions.
- The
acCLI is installed and authenticated when you use the Registry or Image API commands.
For ac Image API commands, select the ACP 4.4 Registry backend:
Required Namespace Permissions
Your user account or workload service account must have permissions in the namespace that owns the image repository. Ask a namespace administrator to grant the required image roles when you need cross-namespace access.
The Registry uses ImageStream layer authorization:
Additional Registry roles (system:image-signature-writer,
system:image-registry-catalog-reader, and system:image-registry-metrics-reader) are listed in the
full permission table in
Managing access and cleanup.
For role binding examples, see Managing access and cleanup.
Access the Registry from Inside the Cluster
Use the internal service address for workloads inside the cluster:
Example workload image reference:
Save the manifest as my-app.yaml and apply it:
Expected results:
- The Deployment is created in
team-aand its Pod becomes ready using the internal Registry image.
The image repository path is namespace-scoped. Use <registry-host>/<namespace>/<repository>:<tag>;
do not include additional path segments after the namespace.
For a custom service account, make sure it has pull permission in the image namespace. The Operator injects the managed pull secret when the Registry is configured to manage service account pull secrets.
Create the service account in the workload namespace:
Have a namespace administrator grant the service account pull permission in the image namespace:
Verify that the managed pull secret is injected:
Expected result:
- The command prints a managed pull Secret name and a non-zero data size. Do not print or decode the Secret data.
The controller refreshes managed pull credentials asynchronously. If no pull Secret is listed, wait for reconciliation and ask a Registry administrator to verify that managed service account pull secrets are enabled and that the workload namespace is not ignored.
Use the service account in the workload:
Save the manifest as my-app-app-puller.yaml and apply it:
Verify the rollout:
Expected results:
- The rollout completes successfully.
- The Pod is ready and does not report an image pull error. If the Pod is in
ImagePullBackOff, verify the ServiceAccount permission, injected pull Secret, internal service address, and image repository path.
Authenticate an External OCI Client
For external access, use ac registry login to write credentials for a account that has namespace permissions:
To write credentials to a specific OCI registry auth file, use --to:
The command writes credentials for registry.example.com to the specified auth file. Use the
exported REGISTRY_AUTH_FILE with ac image commands that need Registry authentication.
If the registry uses a private CA, configure client trust before push and pull operations. Use --insecure only for an HTTP endpoint or a non-production test certificate that the client does not trust.
Push and Pull Images
Tag and push an image:
Pull by tag:
Pull by digest:
Query Image API Resources
List ImageStreams:
Show one ImageStream:
Show the current and historical digest for a tag:
Show the Image metadata for a digest:
List cluster-scoped Image resources through the current modern registry mode:
For namespace-scoped repository views, query ImageStream resources instead of passing a Registry URL override: