Funktioniert Red Hat OpenShift in China? Data Residency, ICP & Grenzregeln

Was die offizielle Red Hat OpenShift-Dokumentation über China sagt

Fakt	Primärquelle
Red Hat liefert OpenShift in zwei Formen. Unter „Self-managed editions" bietet es „Granular control on your own infrastructure," mit Red Hat OpenShift Container Platform beschrieben als „A complete platform with services and tools to develop, operate, and modernize applications"; seine Managed „Cloud services editions" sind „Fully managed in the public cloud of your choice." Die Managed-Cloud-Control-Plane läuft auf der Infrastruktur außerhalb Chinas des Anbieters; die selbstverwaltete Edition ist eine, die Sie auf Ihrer eigenen Infrastruktur betreiben — einschließlich im Inland.	Red Hat — Red Hat OpenShift product page, abgerufen 2026-10-13
OpenShift konzentriert Ihre privaten Images und Geheimnisse auf dem Cluster. Red Hats Dokumentation erklärt „OpenShift Container Platform provides a built-in container image registry that runs as a standard workload on the cluster" — der Speicher für Images, die der Cluster baut, und die Workloads, die er betreibt — und dass ein Secret „provides a mechanism to hold sensitive information such as passwords, OpenShift Container Platform client configuration files, private source repository credentials, and so on." Diese privaten Images backen proprietären Code in ihre Layer ein; auf einer Managed-Cloud-Control-Plane betrieben, sitzen diese Registry und diese Secrets offshore, während ein selbstverwalteter Cluster, den Sie im Inland betreiben, sie resident hält.	Red Hat OpenShift Container Platform 4.17 Documentation — Registry overview; Nodes (secrets), abgerufen 2026-10-13
Für einen Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen müssen in China erhobene und erzeugte personenbezogene Daten und wichtige Daten innerhalb des Festlands gespeichert werden, mit einer Sicherheitsbewertung vor jeder Ausfuhr — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Artikel 39 (vormals Artikel 37), wie umnummeriert durch die Novelle von 2025, in Kraft seit 2026-01-01. Eine Cluster-Control-Plane, Registry und Secrets, die auf einer Infrastruktur außerhalb Chinas gehalten werden, haben keine Festland-Grundlage, um das zu erfüllen.	PRC Cybersecurity Law, Article 39 (formerly Article 37); 2025 amendment in force 2026-01-01
Workload-Daten, die Identitäten in den Zugriffs- und Audit-Logs Ihres Clusters, eingebettete Geheimnisse und jegliche personenbezogenen Daten innerhalb von Images oder Secrets, auf einer Control-Plane außerhalb Chinas gehalten, sind ein PIPL-Grenztransfer (Artikel 38–40): der Verarbeiter muss informieren, eine gesonderte Einwilligung einholen und einen Mechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung.	PRC Personal Information Protection Law, Articles 38–40; CAC cross-border rules (March 2024)

Quellen vom 21YunBox Compliance-Team am 13. Oktober 2026 geprüft.

Für einen Betrieb auf dem Festland China ist die entscheidende Frage zu Red Hat OpenShift nicht, ob ein Knoten in Shanghai ein öffentliches Base-Image ziehen kann — sie ist, wo die Control-Plane Ihres Clusters, seine eingebaute Image-Registry und seine Secrets leben, was sie halten und auf welcher rechtlichen Grundlage sie dorthin gelangt sind. Community-Images und Open-Source-Charts zu ziehen ist ein Erreichbarkeitsthema, und nicht das, das klärt, ob Ihr Setup verteidigbar ist. Ihre privaten Images sind anders: ein Container-Image ist ein Artefakt, das Ihren proprietären Code in seine Layer einbackt, und es bettet routinemäßig Build-Zugangsdaten, API-Tokens und Konfiguration ein; Ihre Helm-Charts tragen diese Deployment-Paketierung und ihre Secret-Referenzen; und ein laufender Cluster hält seine Workloads und seine Secrets. OpenShift konzentriert genau das — eine integrierte Registry und die Secret-Objekte des Clusters — an einem Ort. Auf den Managed-Cloud-OpenShift-Varianten laufen diese Control-Plane und Registry auf der Infrastruktur des Anbieters außerhalb Chinas, und die Image- und Chart-Lieferkette Ihres China-Deployments löst über die Grenze auf. Residency und grenzüberschreitender Transfer, nicht Ladezeit, entscheiden dies.

Funktioniert Red Hat OpenShift in China? Auf einen Blick

Tür eins — Ihre privaten Images und Secrets sind proprietärer Code, und Residency folgt dort, wo die Control-Plane läuft

Beginnen Sie mit dem, was der Cluster hält, denn das ist das, worauf Chinas Recht antwortet. Die öffentlichen Registries, die Community-Base-Images speisen, sind ein Erreichbarkeitsthema, und nicht der Teil, der dies entscheidet. OpenShifts eigene Registry ist der maßgebliche Speicher dessen, was Sie nicht veröffentlichen: Red Hat dokumentiert, dass „OpenShift Container Platform provides a built-in container image registry that runs as a standard workload on the cluster” — das Veröffentlichungsziel für Images, die Ihr Cluster baut, und die Quelle für die Workloads, die er betreibt. Diese privaten Images backen Ihren proprietären Code in ihre Layer ein und tragen eingebackene Zugangsdaten und Tokens; neben ihnen halten die Secret-Objekte des Clusters den Rest. In Red Hats Worten: „The Secret object type provides a mechanism to hold sensitive information such as passwords, OpenShift Container Platform client configuration files, private source repository credentials, and so on.”

Wo das lebt, ist der Punkt. Red Hat liefert OpenShift in zwei Formen. Seine Managed „Cloud services editions” sind „Fully managed in the public cloud of your choice” — die Control-Plane und ihre Registry laufen auf der Infrastruktur des Anbieters außerhalb Chinas. Seine „Self-managed editions” bieten „Granular control on your own infrastructure”: ein Cluster, den Sie installieren und betreiben, wo immer Sie wählen. Wenn Sie ein Betreiber kritischer Informationsinfrastruktur sind oder personenbezogene Daten in Mengen verarbeiten, müssen in China erhobene und erzeugte personenbezogene Daten und wichtige Daten auf dem Festland gespeichert werden, mit einer Sicherheitsbewertung vor jeder Ausfuhr — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Artikel 39 (vormals Artikel 37), wie umnummeriert durch die Novelle von 2025, in Kraft seit 2026-01-01. Eine Control-Plane, Registry und Secrets, die offshore gehalten werden, haben keine Festland-Grundlage, um das zu erfüllen; ein selbstverwalteter Cluster, den Sie im Inland betreiben, hat eine.

Tür zwei — Identitäten, Geheimnisse und Lieferketten-Provenienz

Die zweite Tür ist PIPL und die Integrität dessen, was tatsächlich auf dem Festland läuft. Ein Cluster und seine Pipeline tragen mehr als Code: die Benutzernamen und E-Mail-Adressen derer, die ein Release gebaut, signiert und befördert haben, Zugriffs- und Audit-Logs und jegliche personenbezogenen Daten, die innerhalb eines Image oder Secret mitreiten. Nach dem Gesetz zum Schutz personenbezogener Daten ist das Halten dieser Daten auf einer Infrastruktur außerhalb des Festlands ein grenzüberschreitender Transfer (Artikel 38–40): der Verarbeiter muss informieren, eine gesonderte Einwilligung für den Transfer einholen und einen Mechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Die Geheimnisse und personenbezogenen Daten zu minimieren, die überhaupt erst in Image-Layer und Secrets eintreten, ist Teil der Lösung, aber es bewegt den Speicher nicht von selbst. Und weil Ihr China-Cluster seine Images und Charts von dort zieht, wo immer die Registry läuft, werden die Provenienz und Integrität dessen, was in Ihr China-Deployment eintritt, ebenfalls über die Grenze geregelt — eine Software-Lieferketten-Exponierung, die eine Konnektivitätsprüfung nie zutage fördert.

Warum eine Erreichbarkeitsprüfung dies verfehlt

Ein „kann mein Knoten ein Image aus Shanghai ziehen”-Test beantwortet die falsche Frage. Ein Registry-Spiegel oder -Cache, oder Konnektivitäts-Tuning, verändert, wie schnell und wie zuverlässig ein Image oder Chart auflöst — es verändert nicht, wo Ihre privaten Images, Ihre Secrets und die Control-Plane Ihres Clusters tatsächlich leben. Ein Deployment kann also von innerhalb Chinas vollkommen gesund aussehen, während jedes private Image, jeder darin eingebackene Token und jede Zugangsdaten in einem Secret weiterhin offshore sitzt. Die Residency- und Grenz-Fragen oben sind für eine Erreichbarkeitssonde genau deshalb unsichtbar, weil die Pulls weiterhin gelingen — weshalb der Zug, der zählt, das Bewegen der Control-Plane, Registry und Secrets ins Inland ist, nicht das bloße Erreichbar- oder Gespiegelt-Machen einer Control-Plane außerhalb Chinas. Wir veröffentlichen keine erstanbieterliche Messung der OpenShift-Registry-Konnektivität aus dem Inneren Chinas, wir setzen hier also keine Zahlen; es ist etwas, das wir gegen Ihr tatsächliches Setup messen würden, statt es zu behaupten.

Dies ist eine Risikokarte, kein Urteil: ob Sie inländische Speicherung, einen Transfermechanismus, einen überarbeiteten Einwilligungsfluss, eine ICP-Beian für eine öffentlich ausgerichtete Konsole oder Ingress oder eine Kombination davon brauchen, hängt davon ab, was Ihre Images und Secrets tragen, wie viel und wer Ihre Operatoren sind — wert, mit Rechtsbeistand geklärt zu werden, bevor Sie bauen.

Der Hebel — kartieren, lokalisieren, ausliefern

Weil OpenShift eine echte selbstverwaltete Edition liefert, gibt es einen echten inländischen Pfad, und 21YunBox nutzt oder empfiehlt niemals eine Umgehung jeglicher Art.

• Kartieren — inventarisieren, welche Images und Charts privat sind (Ihr proprietärer Code), ob sie Zugangsdaten, Tokens oder Konfiguration einbetten, wo die Control-Plane, ihre eingebaute Registry und die Secrets des Clusters heute leben, die Residency-Grundlage und wie die Image- und Chart-Lieferkette Ihres China-Deployments die Grenze überquert.
• Lokalisieren / regeln — einen selbstverwalteten Cluster, seine Registry und seine Secrets im Inland betreiben, mit einer inländischen privaten Registry (eine selbst gehostete Registry — Harbor, Nexus oder Artifactory — oder Red Hats eigene selbst hostbare Registry) für Ihre privaten Images und Charts, sodass der proprietäre Code und die eingebetteten Geheimnisse resident bleiben; die Lieferkette Ihres China-Deployments im Inland halten; und minimieren, was die Grenze überquert.
• Ausliefern — einen rechtskonformen, inländischen selbstverwalteten Cluster und eine private Registry vor (oder an die Stelle von) der Control-Plane außerhalb Chinas setzen; 21YunBox stellt die inländische Schicht ohne Neuaufbau auf.

Die öffentliche Registry bloß erreichbar oder gespiegelt zu machen ist nicht die Antwort — Ihre privaten Images, Charts und Secrets sind weiterhin offshore, und sie schneller zu ziehen ändert das nicht. Die Control-Plane, Registry und Secrets im Inland zu halten ist es.

Wo 21YunBox hineinpasst — ein rechtskonformes Overlay, keine Migration

Sie betreiben OpenShift weiter. Wir fügen das Stück hinzu, das eine Control-Plane außerhalb Chinas nicht selbst bieten kann: eine rechtmäßige, inländische Heimat für einen selbstverwalteten Cluster und eine private Registry, sodass Ihre proprietären Images, Charts und die Geheimnisse, die sie tragen, resident bleiben, wo das Recht es verlangt, mit rechtskonformer ICP-eingereichter Auslieferung für den Entwicklerzugang, die Konsole und jeden öffentlich ausgerichteten Ingress davor — um Ihr bestehendes Setup herum gesetzt, ohne Neuaufbau, ohne zweite Plattform und ohne Migration weg von OpenShift. Als Partner der Toolchain, die Sie bereits betreiben, kartiert unser China-Team Ihre PIPL-Grenz-, Einwilligungs- und Data-Residency-Pflichten gegen Ihre Rechtsperson und Ihre Pipeline und stellt dann den inländischen Cluster, die Registry und die Auslieferung auf, die eine verteidigbare China-Präsenz braucht. Wir nutzen oder empfehlen niemals eine Umgehung jeglicher Art.

Compliance-Einschätzung anfordern →

---

Weiterführend:

• Grenzüberschreitende Datentransfers nach PIPL
• Chinas Cybersicherheitsgesetz und Datenlokalisierung
• Wie man eine ICP-Beian für China erhält

Häufige Fragen

Können wir OpenShift in China betreiben?

Öffentliche Base-Images zu ziehen ist eine Erreichbarkeitsfrage, und nicht die eigentliche. Das entscheidende Problem ist, wo die Control-Plane, die eingebaute Image-Registry und die Secrets Ihres Clusters leben — Ihr proprietärer Code, Zugangsdaten und Tokens — und wie die Image- und Chart-Lieferkette Ihres China-Deployments die Grenze überquert. Die Managed-Cloud-OpenShift-Varianten setzen die Control-Plane offshore; ein selbstverwalteter Cluster, den Sie im Inland betreiben, mit einer inländischen Registry, hält diese resident. Das, nicht die Image-Erreichbarkeit, ist das, was das Setup verteidigbar macht.

Ist Managed-Cloud-OpenShift oder selbstverwaltetes OpenShift besser für China-Compliance?

Red Hats Managed „Cloud services editions" betreiben die Control-Plane und Registry auf Public-Cloud-Infrastruktur außerhalb Chinas, Ihre privaten Images, Secrets und Workload-Daten sitzen also im Ausland. Ein „Self-managed" OpenShift gibt Ihnen „granular control on your own infrastructure", das Sie im Inland deployen können — und hält die Images, Charts, Secrets und Workload-Daten resident. Für eine China-Operation unter Datenlokalisierungs- und PIPL-Grenz-Regeln ist der selbstverwaltete, inländische Pfad der verteidigbare.

Kann 21YunBox helfen, unser OpenShift-Setup in China rechtskonform zu machen?

Ja. Unser China-Team kartiert, wo Ihre Control-Plane, Registry, Images, Charts und Secrets leben, welche Zugangsdaten und personenbezogenen Daten sie tragen und wie die Lieferkette Ihres China-Deployments die Grenze überquert, und stellt dann einen rechtskonformen, inländischen selbstverwalteten Cluster und eine private Registry mit ICP-eingereichter Auslieferung vor Ihrem bestehenden Setup auf — kein Neuaufbau, keine Migration weg von OpenShift. Nehmen Sie Kontakt auf, um Ihren spezifischen Stack durchzugehen.