A private image needs somewhere to live and a way for your cluster to pull it. The storage is usually straightforward. Access has a habit of spreading: a credential in CI, a pull Secret in one namespace, another copy when a service moves, and a rotation to remember later. Your existing registry may automate some of that already. We wanted Kupe to take care of it for the clusters it manages.
Kupe now includes an opt-in private container registry for each account. You push images with your usual tools, connect the clusters that need them, and deploy. Connected clusters can pull your images without an imagePullSecrets entry in your manifests. Kupe manages the pull credentials.
The registry belongs to your account
Your images sit alongside the clusters and managed services. Each account can turn on one registry, and you choose which of its clusters to connect. You can use the same image across development and production without setting up a separate registry for each cluster.
The registry has its own lifecycle. Deleting a cluster removes that cluster's connection; it doesn't delete the images. When you create its replacement, you can connect it to the same registry. That keeps an application build available independently of any one cluster.
Access follows your Kupe account too. Members sign in with their existing identity, and CI uses access tokens with pull-only or push-and-pull access. Removing a member revokes the sessions and tokens they created. There is no separate set of registry users to keep in sync when someone joins or leaves.
Kupe operates the registry for you, with no separate installation to maintain or account to administer. The console, CLI, API and Terraform provider all work with the same registry and cluster connections.
Connect once, pull across the cluster
A connection gives a cluster access to the account's images. Once it's ready, new pods can pull from the registry in any namespace. Creating another namespace doesn't give you another pull Secret to distribute, and rotating the connection's credentials doesn't require changes to your application manifests.
The pull credential stays on the host, outside your tenant cluster. Workloads and people with access to that cluster cannot read or copy it. That was a deliberate choice: a cluster needs permission to fetch an image, but the application running from that image doesn't need the credential itself.
There is a tradeoff here. A connection grants pull access to every repository in the account's registry, across the whole cluster. This first version has no per-namespace pull restrictions. If two teams must not be able to pull each other's images, they need separate accounts or a registry setup with that finer boundary. Namespaces alone don't provide it.
Builds running inside a cluster can also receive push access in selected namespaces. That uses a Secret inside those namespaces, so it needs more care: workloads able to use it can push to the registry, including replacing existing tags. We keep that permission separate from the cluster's ordinary pull access.
Keep the build tools you use
The registry works with standard OCI clients and stores container images, multi-platform images, Helm charts and signatures. An existing pipeline can push to Kupe using an access token; you don't need to adopt a Kupe-specific build system.
For a team managing infrastructure in Git, Terraform can declare the registry and its cluster connections alongside the clusters themselves. If you prefer the console or CLI, those expose the same choices. The useful outcome is the same: the image is stored in your account, and the clusters you've connected can run it.
You can browse repositories, images and tags in the console. Storage use, push and pull activity, access tokens and cluster connections also appear in the Registry dashboard in Grafana. Alerts cover storage filling up, expiring tokens and connections that haven't become ready. Registry operations belong with the rest of the platform's monitoring; you shouldn't need another monitoring setup just to see whether your image store is filling up.
What this first version leaves to you
The registry handles image storage and access today. A few limits are worth knowing before you rely on it:
- It doesn't scan stored images yet. Kupe's workload vulnerability reports cover images deployed to clusters.
- Tags are mutable, and there are no automatic retention rules. You decide what to keep and delete.
- The registry isn't backed up, and deleted images cannot be restored. Keep the source and build pipeline needed to publish them again.
Deletion protection is on by default. You can set a storage limit within your plan's allowance; reaching it stops new pushes while existing images remain available to pull.
Scanning on push, per-image SBOMs, retention rules and immutable tags are on the roadmap. They're planned additions, so choose the registry based on what it does today.
To try it, enable Registry in the console and connect one of your clusters. The registry guide covers pushing your first image and setting up CI, with Terraform examples if that's how you manage your account. If the path leaves you managing a pull Secret by hand, we'd like to hear where: support@kupe.cloud.
Top comments (0)