Unit 6.4: Container Registry and Platform Selection

Introduction

Every container platform needs a trusted place to store images and a defensible story for who can push and pull them. On IONOS the Container Registry gives you that store, but it governs access in a way that will surprise an architect who expects the role-based model common to hyperscaler registries: access is by token only, and the discipline you apply to those tokens is the whole of your access governance. This unit first establishes that governance model and the platform-selection decision behind any container estate, then ends by building a registry, scoping a token, and logging a client in within the Data Center Designer.

FinCorp, our regulated German fintech, is standing up a CI/CD pipeline to ship its new AI-adjacent services onto Managed Kubernetes. The registry sits between the build farm and the cluster, so the access model it imposes becomes a governance control that FinCorp's auditors will examine. The platform-selection question runs alongside it: FinCorp must decide whether Managed Kubernetes carries its container workloads or whether a customer-deployed distribution is warranted, and that decision turns entirely on who is willing to own the control-plane lifecycle.

1. Token-Only Access and Governance by Token Discipline

The Container Registry has no role-based access control. There are no roles, no users mapped to permissions inside the registry, and no policy language. Access is granted exclusively through registry access tokens, so the registry's security posture is precisely the discipline you impose on those tokens. An architect coming from a registry with RBAC must internalise this inversion: you do not assign a principal a role, you mint a credential and scope it.

A token carries a scope built from three parts. The Type is either Registry, which lets the token list the repositories in the registry, or Repository, which lets the token manage the contents of one or more named repositories. The Path names the repositories the token reaches, where * is a wildcard that grants access to all repositories. The Action is one or more of Pull, Push, and Admin, where Admin allows the token to delete artifacts. A push-capable token must also carry pull: when you select Push you must also set Pull. There is no per-repository access-control list beyond this token scoping; the registry does not offer finer-grained ACLs on a single repository than the token model expresses.

Tokens come in two kinds: a permanent registry access token, and a temporary token that carries an expiry date. The minimum expiry you can set on a temporary token is one hour. A token's secret is shown exactly once at creation; if you lose it, you cannot recover it, only replace the token. A token has three lifecycle states: enabled, disabled, and deleted. You can disable a token to suspend it, but the security-relevant fact is what happens at expiry: an expired token is deleted, not merely disabled. This means an expiry is a hard end-of-life for the credential, and there is no anonymous access and no public-pull tier to fall back on. Pulling, like pushing, always requires a valid token.

Because the registry gives you nothing but tokens, governance is token discipline, and the discipline is concrete. Issue one token per pipeline stage rather than one shared credential: the build stage that pushes images gets a push-and-pull token scoped to the repositories it produces, while the deploy stage that pulls images onto the cluster gets a pull-only token. Scope each token as narrowly as the stage allows, preferring a Repository-type token on a named path over a wildcard. Set an expiry that matches the credential's intended life and rotate by minting a replacement before the old one expires, since expiry deletes the token outright and an unrotated pipeline simply stops. Keep these tokens out of personal credentials entirely; the token model exists precisely so that CI/CD never authenticates as a person. For FinCorp this maps cleanly onto its auditors' expectations: each pipeline stage holds a distinct, narrowly scoped, expiring credential, and the absence of long-lived shared secrets is demonstrable from the token list.

The registry is encrypted at rest and publishes a 99.95% per-service uptime SLA. It is currently available in the Frankfurt (DE/FRA) location, and both the registry name and its location are immutable after creation, so the location is a placement decision made once. The registry name must additionally be globally unique across all customers, contain only alphanumeric characters and dashes, be between 3 and 63 characters, begin with a letter a-z, and end with an alphanumeric character.

2. Vulnerability Scanning as a One-Way Toggle

Vulnerability scanning is an add-on feature that analyses the software in your container images against known Common Vulnerabilities and Exposures (CVEs). A scan runs every time an artifact is pushed and again when new vulnerability definitions are published, so coverage tracks both your image churn and the evolving CVE catalogue, with a rescan window of 30 days. The results give per-artifact CVE detail you can wire into a CI/CD gate, which is the value for a regulated shop like FinCorp that must show due diligence on its supply chain.

The architectural detail that matters is irreversibility. Once vulnerability scanning is enabled on a registry it cannot be disabled later. Enabling is therefore a deliberate, one-way decision, not a setting to toggle on for a trial and turn off afterwards. Treat it as a property you commit to for the life of the registry, and decide it consciously at or after creation rather than discovering the constraint when you try to reverse it. For FinCorp the decision is straightforward, scanning stays on, but the architect should still record it as an irreversible commitment.

3. Platform Selection: Who Carries the Control-Plane Lifecycle

The container-platform decision on IONOS is fundamentally about who owns the Kubernetes control plane and its compliance burden, not about feature parity between distributions. Three options sit on the same IONOS compute and storage substrate but differ sharply in their operational model.

The following table summarises the three options and where the lifecycle and compliance burden falls.

Managed Kubernetes is the default. IONOS operates the control plane and provides it free of charge, while you pay only for the node pools. The lifecycle of the control plane, its upgrades, its availability, is IONOS's responsibility under a 99.95% per-service SLA. On compliance, Managed Kubernetes falls under the BSI IT-Grundschutz (ISO 27001) certification scope in German data centers, but it is not within the BSI C5 attestation scope. This is the per-service compliance precision the platform demands: you cannot say "the cluster is C5", because the C5 Type 1 attestation (granted 2023-11-07) covers Compute Engine, Cloud Cubes, and S3 Object Storage, not Managed Kubernetes.

Red Hat OpenShift is not a managed IONOS service. IONOS does not offer a managed OpenShift solution and does not sell or charge for OpenShift subscriptions. Instead, IONOS and Red Hat jointly validated OpenShift running on IONOS infrastructure, producing a reference implementation for Red Hat Certified Cloud Service Provider (CCSP) partners. The customer (the CCSP partner) deploys and manages its own clusters and therefore owns the entire control-plane lifecycle. Licensing is bring-your-own-license, with subscriptions sourced from Red Hat or an individual distributor; the underlying IONOS resources are billed at the regular price list with no OpenShift-specific surcharge. Before running OpenShift in production, partners must schedule a Red Hat validation through an IONOS Cloud representative, who coordinates the review confirming the deployment meets Red Hat's production requirements. Choose this path only when the OpenShift platform itself is a hard requirement and you are prepared to own its operation.

SUSE Rancher Prime follows a self-managed deployment model on IONOS. IONOS does not provide Rancher Prime as a managed service: the customer is responsible for the full lifecycle of the Rancher Prime environment, including installation, scaling, and ongoing maintenance of the management server, as well as the configuration and administration of the downstream cluster landscapes. The commercial model is bring-your-own-subscription, where IONOS bills the infrastructure (Compute Engine, Block Storage, networking) at standard rates and SUSE (or the customer's SUSE distributor) bills the Rancher Prime and SUSE Linux Enterprise Server licenses, with no hidden integration fees from IONOS. The partnership is positioned for sovereign, DACH-region Kubernetes management with alignments to BSI IT-Grundschutz, NIS2, EU GDPR, and EU supply-chain requirements; the operational caveat is that you, not IONOS, run the management plane. The earlier framing of Rancher Prime as a SUSE-operated managed service does not hold: SUSE supplies the subscription and support, but the customer operates the platform.

The honest summary for FinCorp: the customer-deployed options trade the convenience of a managed control plane for distribution-specific capabilities, and in doing so they transfer the control-plane lifecycle and the bulk of the compliance burden onto FinCorp's own teams. Unless OpenShift or Rancher is a stated requirement, Managed Kubernetes is the lower-burden, IONOS-supported choice that already sits inside the IT-Grundschutz scope.

A boundary that applies to all three: where attestations and certifications cover the IONOS infrastructure layer, they cover that layer only, not the customer's workloads running on the cluster. A cluster sitting on attested infrastructure does not make the application on it compliant; workload compliance remains the customer's responsibility regardless of which distribution runs the control plane.

3.1 Multi-Cluster versus Namespace Isolation

Within whichever platform you choose, separating workloads is a two-level decision. Namespace isolation divides a single cluster logically: tenants share the same control plane and node pools, and you enforce separation with in-cluster network policies and resource quotas. It is the cheaper, denser option and the right default for environments that share a trust and compliance boundary, for example several of FinCorp's internal development teams.

Multi-cluster isolation puts workloads in separate clusters, giving each its own control plane and a hard blast-radius boundary. It is the stronger separation and the one to reach for when workloads sit in different compliance scopes, when a noisy or hostile neighbour is unacceptable, or when an upgrade or failure must not be able to cross between tenants. On Managed Kubernetes the cost of choosing multi-cluster freely is bounded by a per-contract cluster quota (a default that can be raised on request through IONOS Cloud Support), so an estate that needs many hard-isolated tenants must plan around that ceiling, potentially by splitting across contracts (the contract being the governance boundary established in Module 2). FinCorp's pattern is to keep its regulated production workload in its own cluster, isolated from the shared development cluster, precisely so that the production compliance scope is not entangled with development churn.

DCD Implementation Walkthrough

You will create a Container Registry, enable vulnerability scanning, mint a narrowly scoped token, and authenticate a Docker client against it. This realises the access model from Section 1: a single registry whose only access surface is a set of scoped, expiring tokens, ready to back FinCorp's pipeline. The only prerequisite is a contract user with permission to create the registry.

Build goal: Create a registry, issue a scoped token, authenticate a client.

Steps (in the Data Center Designer):

1. Go to Menu > Containers > Container Registry to open the Container Registry Manager.
2. Click Add a Registry. Provide a Name. Remember the name is permanent, globally unique across all customers, alphanumeric-and-dashes only, 3 to 63 characters, starting with a letter and ending alphanumerically.
3. Choose the Location from the drop-down. This too is immutable after creation, and the registry is available in the Frankfurt (DE/FRA) location. Decide it deliberately.
4. Optionally configure the Garbage Collection Schedule, selecting the day(s) and time (UTC) for the weekly run that frees storage held by unreferenced image layers. Garbage collection is disabled by default; note the registry is read-only while it runs, so place the window off-peak.
5. Decide on Vulnerability Scanning. You may enable it here, but once enabled it cannot be disabled later, so treat enabling as a one-way commitment. (You can also add it to an existing registry afterward via the registry's Properties section, where the same irreversibility applies.)
6. Click Add Registry. The registry and its storage are created; it is ready to use when its status reaches Running. The registry hostname is allocated only once it reaches Running.
7. Select the running registry and open the Tokens tab, then click Add Token. Give the token a Name (also not changeable later).
8. Define the token's scope: set the Type (Registry to list repositories, or Repository to manage repository contents), enter the Path of repositories it reaches (avoid the * wildcard unless the stage genuinely needs every repository), and select the Action(s). For a build-stage push token select Push and, because push requires it, also Pull. For an optional expiry, set an expiry date no shorter than one hour. Save the token and copy its secret now: it is shown only once.
9. Authenticate a client. Using the Docker CLI, log in to the registry hostname with the token as the credential:

docker login {registry-name}.cr.de-fra.ionos.com
## Username and Password: supply the token credentials (not a personal login)

The client can now push and pull within the token's scope. The architectural point is that this is the only authentication path: there is no anonymous pull, so even read access flows through a scoped token.

Common mistakes:

• Treating vulnerability scanning as reversible. It is a one-way toggle; once enabled it cannot be turned off. Decide before you enable.
• Expecting to disable an expired token. Expiry deletes the token, it does not disable it, so an unrotated pipeline credential vanishes and the pipeline breaks. Rotate by minting a replacement before expiry.
• Trying to recover a lost token secret. The secret is displayed exactly once at creation; if it is lost, you must create a new token.
• Granting Push without Pull. A push-capable token must also carry pull, or the push fails.
• Reaching for a * wildcard or a single shared token across all stages. Issue one narrowly scoped token per pipeline stage; the registry has no RBAC, so token scope is your only access control.
• Assuming you can rename or relocate the registry later. Both the name and the location are immutable; choosing the wrong location means recreating the registry.
• Relying on a public-pull tier for base images. There is no anonymous access and no public-pull tier; every pull needs a token.

Summary

The IONOS Container Registry governs access through scoped, expiring tokens rather than role-based access control, so the registry's security is exactly the discipline you apply to its tokens: one per pipeline stage, narrowly scoped, expiring, rotated by replacement, and kept out of personal credentials. Vulnerability scanning is a valuable but irreversible add-on, and the registry's name and location are permanent. The platform-selection decision turns on who owns the control-plane lifecycle and compliance burden: Managed Kubernetes keeps both with IONOS inside the IT-Grundschutz scope, while OpenShift and Rancher Prime are customer-deployed and shift that ownership to you. Separate workloads with namespaces when they share a trust boundary and with multiple clusters when they need a hard one, within the per-contract cluster ceiling.

Key Points:

• The Container Registry has no RBAC; access is token-only, with no anonymous access and no public-pull tier. Governance is token discipline.
• Token scope is Type (Registry or Repository) plus Path plus Action (Pull/Push/Admin); Push requires Pull, and the token secret is shown only once.
• Tokens are deleted at expiry, not disabled; rotate by issuing a replacement before expiry. Minimum expiry is one hour.
• Vulnerability scanning is a one-way toggle: once enabled it cannot be disabled. The registry name and location are immutable.
• Managed Kubernetes keeps the control-plane lifecycle and compliance with IONOS (IT-Grundschutz, not C5); OpenShift (CCSP, BYOL) and Rancher Prime (self-managed, BYOS) are customer-deployed, shifting that burden to you.
• Attestations cover the IONOS infrastructure layer only, never the customer's workloads on the cluster.
• Use namespaces for soft, shared-boundary separation and multiple clusters for hard separation, within your per-contract cluster quota (raise on request).

Important Terminology:

• Registry access token: the sole access credential for the Container Registry, scoped by type, path, and action; permanent or temporary (with an expiry deleting it at end of life).
• Vulnerability scanning: an irreversible add-on that scans pushed artifacts against known CVEs, rescanning as new definitions publish.
• CCSP (Certified Cloud Service Provider): the Red Hat partner role under which OpenShift is customer-deployed on validated IONOS infrastructure rather than offered as a managed IONOS service.
• BYOS (Bring Your Own Subscription): the SUSE Rancher Prime model where IONOS bills infrastructure and SUSE bills licenses, with the customer self-managing the platform.