Funktioniert die GitHub Container Registry in China? Datenresidenz, ICP und Grenztransfer-Regeln

Was die offizielle GitHub Container Registry-Dokumentation über China sagt

Fakt	Primärquelle
In GitHubs eigenen Worten: GitHub Packages „is a software package hosting service that allows you to host your software packages privately or publicly“ (ist ein Hosting-Dienst für Softwarepakete, der es Ihnen erlaubt, Ihre Softwarepakete privat oder öffentlich zu hosten), und „GitHub's Container registry is optimized for containers and supports Docker and OCI images“ (GitHubs Container Registry ist für Container optimiert und unterstützt Docker- und OCI-Images). Sie erreichen diese Registry unter ghcr.io. GHCR ist daher GitHubs eigene gehostete Registry für Ihre privaten Container-Images, und GitHub (eine Microsoft-Tochter) nennt keine Festland-China-Region — Ihre privaten Images sitzen also im Ausland (bitte aktuell mit GitHub bestätigen).	GitHub Docs — Introduction to GitHub Packages, abgerufen 2026-10-13
GitHub dokumentiert, dass Sie in der Container Registry „can store and manage Docker and OCI images“ (Docker- und OCI-Images speichern und verwalten können), dass Sie sich „sign in to the Container registry service at ghcr.io“ (beim Container-Registry-Dienst unter ghcr.io anmelden) und dass beim erstmaligen Veröffentlichen eines Pakets die „default visibility is private“ (Standardsichtbarkeit privat ist). Ein privates Image ist ein Artefakt, das Ihren proprietären Code in seine Layer backt und routinemäßig Build-Anmeldedaten, API-Token und Konfiguration einbettet — dieses konzentrierte geistige Eigentum und seine Secrets sind es also, die auf GitHubs Offshore-Registry sitzen.	GitHub Docs — Working with the Container registry, abgerufen 2026-10-13
Mitwirkenden-Identitäten, Pull-/Push- und Zugriffsprotokolle und alle personenbezogenen Daten in privaten Images oder Build-Metadaten, auf einer Offshore-Registry gehalten, sind ein grenzüberschreitender Transfer nach dem Gesetz zum Schutz personenbezogener Daten (Art. 38–40): Der Verarbeiter (Sie, der Registry-Betreiber — nicht GitHub) muss Mitteilung erteilen, eine gesonderte Einwilligung einholen und einen Mechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung.	Gesetz zum Schutz personenbezogener Daten, Art. 38–40 — 21YunBox-Compliance-Referenz, abgerufen 2026-10-13
Für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen müssen in China erhobene und erzeugte personenbezogene Daten und wichtige Daten im Festland gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Art. 39 (vormals Art. 37) in der Nummerierung der Novelle 2025, in Kraft seit 2026-01-01. Eine Offshore-Registry, die Ihre privaten Images hält, hat keine Festland-Grundlage, um das zu erfüllen.	Cybersicherheitsgesetz, Art. 39 (vormals Art. 37) — 21YunBox-Compliance-Referenz, abgerufen 2026-10-13

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

Für einen Festlandchina-Betrieb ist die entscheidende Frage zur GitHub Container Registry nicht, ob ein Knoten in Shanghai ein öffentliches Basis-Image ziehen kann — sondern, wo Ihre privaten Images liegen, was sie tragen und auf welcher Rechtsgrundlage sie dorthin gelangten. Öffentliche Basis-Images der Community zu ziehen, ist ein Erreichbarkeitsthema und nicht das, was darüber entscheidet, ob Ihr Setup verteidigbar ist. Ihre privaten Container-Images sind anders: Ein Container-Image backt Ihren proprietären Code in seine Layer — Geschäftsgeheimnisse — und bettet routinemäßig Build-Anmeldedaten, API-Token, Registry-Auth und Konfiguration ein, mit gelegentlich einem Stück personenbezogener Daten, das in einer Fixture oder einem zwischengespeicherten Artefakt mitreist. In die GitHub Container Registry (GHCR) gepusht, sitzt dieses konzentrierte geistige Eigentum auf GitHubs gehosteter Registry im Ausland, und die Image-Lieferkette Ihres China-Deployments — was im Festland läuft, mit welcher Herkunft und Integrität — überquert die Grenze. Residenz und grenzüberschreitender Transfer, nicht die Pull-Latenz, entscheiden darüber.

Funktioniert die GitHub Container Registry in China? Auf einen Blick

Tür eins — Ihre privaten Images sind proprietärer Code, und die Residenz folgt dem Ort ihres Hostings

Beginnen Sie mit dem, was die Registry hält, denn darauf antwortet Chinas Recht. Öffentliche Basis-Images zu ziehen, zieht Community-Inhalte, aber das ist nicht der Teil, der darüber entscheidet. Ihre privaten Images sind der maßgebliche Speicher des Codes, den Sie nicht der Welt veröffentlichen: proprietäre Dienste, interne Basis-Layer und Build-Werkzeuge — ein konzentrierter Ausschnitt Ihres geistigen Eigentums —, die routinemäßig eingebackene Anmeldedaten, API-Token, Registry-Auth und Konfiguration und manchmal personenbezogene Daten in Test-Fixtures tragen. In GitHubs eigenen Worten „allows you to host your software packages privately or publicly“ (erlaubt GitHub Packages es Ihnen, Ihre Softwarepakete privat oder öffentlich zu hosten), und „GitHub’s Container registry is optimized for containers and supports Docker and OCI images“ (GitHubs Container Registry ist für Container optimiert und unterstützt Docker- und OCI-Images). Sie erreichen diese Registry unter ghcr.io, wo die Standardsichtbarkeit eines veröffentlichten Pakets privat ist.

Dieses Hosting ist der Punkt. Die Container Registry ist GitHubs gehosteter Dienst — GitHub gehört Microsoft — und läuft auf Offshore-Infrastruktur, und GitHub nennt keine Festland-China-Region (etwas, das direkt mit GitHub zu bestätigen und nicht anzunehmen ist). Sind Sie ein Betreiber kritischer Informationsinfrastruktur oder verarbeiten Sie personenbezogene Daten in großem Umfang, müssen in China erhobene und erzeugte personenbezogene Daten und wichtige Daten im Festland gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Art. 39 (vormals Art. 37) in der Nummerierung der Novelle 2025, in Kraft seit 2026-01-01. Eine Offshore-Registry, die Ihre proprietären Images und die darin eingebackenen Secrets hält, hat keine Festland-Grundlage, um das zu erfüllen.

Tür zwei — Mitwirkenden-Identitäten, Secrets und Lieferketten-Herkunft

Die zweite Tür ist PIPL und die Integrität dessen, was in Ihr China-Deployment gelangt. Private Images und die Pipeline um sie herum tragen mehr als Code: Benutzernamen und E-Mail-Adressen derjenigen, die ein Release gebaut, signiert und gepusht haben, Pull-/Push- und Zugriffsprotokolle und alle personenbezogenen Daten, die in Image-Layer oder Build-Metadaten geraten. Nach dem Gesetz zum Schutz personenbezogener Daten ist es ein grenzüberschreitender Transfer (Art. 38–40), diese Daten auf Infrastruktur außerhalb des Festlands zu halten: Der Verarbeiter muss Mitteilung erteilen, eine gesonderte Einwilligung für den Transfer einholen und einen Mechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Die Secrets und personenbezogenen Daten, die überhaupt erst in Image-Layer eingebacken werden, zu minimieren, ist Teil der Lösung, verschiebt den Speicher aber nicht von allein. Und weil Ihr China-Cluster seine Images von dort zieht, wo die Registry läuft, werden die Herkunft und Integrität des Codes, der in Ihr China-Deployment gelangt, ebenfalls über die Grenze geregelt — eine Software-Lieferketten-Exponierung, die eine Konnektivitätsprüfung nie zutage fördert.

Warum eine Erreichbarkeitsprüfung das verfehlt

Ein Test nach dem Muster „can my node pull images from Shanghai“ (kann mein Knoten Images aus Shanghai ziehen) beantwortet die falsche Frage. Ein Registry-Mirror oder Pull-Through-Cache oder Konnektivitäts-Tuning ändert, wie schnell und wie zuverlässig ein Image zieht — es ändert nicht, wo Ihre privaten Images, die in ihre Layer eingebackenen Secrets und die Build-Herkunft tatsächlich liegen. Ein Setup kann also aus China heraus vollkommen gesund aussehen, während jedes private Image, jedes darin eingebackene Token und jeder Mitwirkenden-Datensatz weiterhin im Ausland sitzt. Die Residenz- und Grenztransfer-Fragen oben sind für eine Erreichbarkeits-Sonde gerade deshalb unsichtbar, weil die Images weiter ziehen — weshalb der Zug, auf den es ankommt, darin besteht, den privaten Speicher ins Inland zu verlegen, nicht den Offshore-Speicher bloß erreichbar oder gespiegelt zu machen. Wir veröffentlichen keine eigene Messung der GHCR-Konnektivität aus China, daher setzen wir hier keine Zahlen; das ist etwas, das wir an Ihrem tatsächlichen Setup messen würden, statt es zu behaupten.

Dies ist eine Risikokarte, kein Urteil: Ob Sie Inland-Speicherung, einen Transfermechanismus, einen überarbeiteten Einwilligungsfluss, eine ICP-Beian für ein öffentlich zugängliches Entwicklerportal oder eine Kombination davon brauchen, hängt davon ab, was Ihre privaten Images tragen, wie viel und wer Ihre Mitwirkenden sind — zu klären mit Rechtsbeistand, bevor Sie bauen.

Der Hebel — kartieren, lokalisieren, ausliefern

Weil es für Container-Images eine echte selbst gehostete private Registry gibt, existiert ein echter Inland-Weg, und 21YunBox verwendet oder empfiehlt niemals eine Umgehung welcher Art auch immer.

• Kartieren — inventarisieren, welche Ihrer Images privat sind (Ihr proprietärer Code), ob ihre Layer Anmeldedaten, Token oder Konfiguration einbetten, wo diese private Registry heute gehostet wird, die Residenzgrundlage und wie die Image-Lieferkette Ihres China-Deployments die Grenze überquert.
• Lokalisieren / steuern — die private Registry und den Artefakt-Speicher im Inland betreiben (selbst gehostet — Harbor oder Nexus / Artifactory in Ihrer eigenen Infrastruktur), sodass die proprietären Images und eingebetteten Secrets resident bleiben; die Lieferkette Ihres China-Deployments im Inland halten; und minimieren, was die Grenze überquert.
• Ausliefern — eine rechtskonforme, inländische private Registry und Image-Auslieferung vor den (oder an die Stelle des) Offshore-Dienst setzen; 21YunBox baut die Inland-Schicht ohne Neuaufbau auf.

Die öffentliche Registry bloß erreichbar oder gespiegelt zu machen, ist nicht die Antwort — Ihre privaten Images und Secrets liegen weiterhin im Ausland, und sie schneller zu ziehen ändert das nicht. Die private Registry und die Image-Artefakte im Inland zu halten, ist die Antwort.

Wo 21YunBox hineinpasst — eine Compliance-Overlay, keine Migration

Sie nutzen weiter GitHub und GHCR. Wir ergänzen das Stück, das eine Offshore-Registry nicht allein bieten kann: ein rechtmäßiges, inländisches Zuhause für eine selbst gehostete private Registry, sodass Ihre proprietären Images, ihre Layer und eingebetteten Secrets dort resident bleiben, wo das Recht es verlangt, mit rechtskonformer ICP-gemeldeter Auslieferung für den Entwicklerzugang und jedes öffentlich zugängliche Portal davor — um Ihr bestehendes Setup herum gelegt, ohne Neuaufbau, ohne zweite Codebasis und ohne Migration weg von GitHub. Als Partnerin der Toolchain, die Sie bereits betreiben, kartiert unser China-Team Ihre PIPL-Grenztransfer-, Einwilligungs- und Datenresidenzpflichten anhand Ihrer Rechtsperson und Ihrer Pipeline und baut dann die Inland-Registry und -Auslieferung auf, die eine verteidigbare China-Präsenz braucht. Wir verwenden oder empfehlen niemals eine Umgehung welcher Art auch immer.

Compliance-Einschätzung anfordern →

---

Weiterführend:

• Grenzüberschreitende Datentransfers nach PIPL
• Chinas Cybersicherheitsgesetz und Datenlokalisierung
• So erhalten Sie eine ICP-Beian für China

Häufige Fragen

Kann ich die GitHub Container Registry in China nutzen?

Technisch kann ein Knoten meist daraus ziehen, aber das ist nicht die Frage, die über Compliance entscheidet. GHCR ist GitHubs gehostete Registry, erreichbar unter ghcr.io, und GitHub nennt keine Festland-China-Region — Ihre privaten Images, die in ihre Layer eingebackenen Secrets und die Mitwirkenden-Datensätze um sie herum sitzen also im Ausland. Für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen steht das im Widerspruch zur Datenlokalisierung, und die betroffenen personenbezogenen Daten sind ein grenzüberschreitender Transfer nach PIPL. Der rechtskonforme Weg ist eine selbst gehostete private Registry, im Festland betrieben.

Wo liegen meine privaten Images auf GHCR, und hat es eine Festland-China-Region?

Auf GitHubs eigener gehosteter Registry. GitHub dokumentiert, dass GitHub Packages es Ihnen „erlaubt, Ihre Softwarepakete privat oder öffentlich zu hosten“ und dass Sie sich beim Container-Registry-Dienst unter ghcr.io anmelden, wo die Standardsichtbarkeit eines veröffentlichten Pakets privat ist. GitHub ist eine Microsoft-Tochter und nennt keine Festland-China-Region (etwas, das direkt mit GitHub zu bestätigen ist), sodass die privaten Images eines China-Deployments im Ausland gehostet werden — weshalb Residenz, nicht Erreichbarkeit, die entscheidende Frage ist.

Kann 21YunBox helfen, unser GHCR- und Container-Setup in China rechtskonform zu machen?

Ja. Unser China-Team kann Ihre ICP- und Datenresidenz-Exponierung für das, was Ihre privaten Images tragen, einschätzen, eine rechtskonforme, selbst gehostete Inland-Registry aufbauen, sodass Ihre proprietären Images und eingebetteten Secrets resident bleiben, und ICP-gemeldete Auslieferung vor Ihrem Entwicklerzugang und jedem öffentlich zugänglichen Portal bereitstellen — um Ihre bestehende GitHub-Toolchain herum gelegt, ohne Neuaufbau oder Migration weg von GitHub. Nehmen Sie Kontakt auf, um Ihr konkretes Setup durchzugehen.