{"meta":{"title":"Zulassen des Codespacezugriffs auf eine private Registrierung","intro":"Sie können GitHub Codespaces den Zugriff auf Container-Images oder andere Pakete in einer privaten Registry erlauben.","product":"Codespaces","breadcrumbs":[{"href":"/de/codespaces","title":"Codespaces"},{"href":"/de/codespaces/reference","title":"Verweis"},{"href":"/de/codespaces/reference/allowing-your-codespace-to-access-a-private-registry","title":"Zugreifen auf eine private Registrierung"}],"documentType":"article"},"body":"# Zulassen des Codespacezugriffs auf eine private Registrierung\n\nSie können GitHub Codespaces den Zugriff auf Container-Images oder andere Pakete in einer privaten Registry erlauben.\n\n## Über private Registries und GitHub Codespaces\n\nEine Registrierung ist ein sicherer Ort für das Speichern, Verwalten und Abrufen von Containerimages und anderen Paketen. Es gibt viele Beispiele für Registrierungen, z. B.:\n\n* GitHub's Container registry, die Azure Container Registry und DockerHub für Container-Images\n* Die npm registry für Node.js-Pakete.\n\nBestimmte GitHub Packages Registrys, einschließlich der Container registry, können so konfiguriert werden, dass Pakete bei der Erstellung des Codespaces nahtlos in GitHub Codespaces heruntergeladen werden können, ohne dass dafür Anmeldeinformationen angegeben werden müssen.\n\nUm auf andere Container-Image-Registrys zuzugreifen, können Sie in GitHub Secrets erstellen, um die Zugriffsdaten zu speichern. Dadurch kann GitHub Codespaces auf Images zugreifen, die in dieser Registry gespeichert sind.\n\n## Zugreifen auf Pakete in Registrierungen mit spezifischen Berechtigungen\n\nGitHub Packages-Registrys, die granulare Berechtigungen unterstützen, darunter Container registry, bieten GitHub Codespaces die einfachste Möglichkeit, Pakete zu beziehen. Die Liste der GitHub Packages Registrierungen, die granulare Berechtigungen und nahtlosen GitHub Codespaces Zugriff unterstützen, finden Sie unter [Informationen zu Berechtigungen für GitHub-Pakete](/de/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages).\n\n### Zugreifen auf ein im selben Repository wie der Codespace veröffentlichtes Paket\n\nWenn du ein Paket im selben Repository veröffentlichst, in dem der Codespace gestartet wird, kannst du dieses beim Erstellen des Codespace automatisch abrufen. Du musst keine zusätzlichen Anmeldeinformationen angeben, es sei denn, die Option **Zugriff von Repository erben** wurde bei der Veröffentlichung des Pakets deaktiviert.\n\n#### Vererbung des Zugriffs von dem Repository, aus dem ein Paket veröffentlicht wurde\n\nStandardmäßig erbt das Paket die Zugriffseinstellung des Repositorys, aus dem es veröffentlicht wurde. Wenn das Repository zum Beispiel öffentlich ist, ist auch das Paket öffentlich. Ist das Repository privat, ist auch das Paket privat, aber über das Repository zugänglich.\n\nDieses Verhalten wird über die Option **Zugriff von Repository erben** gesteuert.\n**Zugriff aus dem Repository übernehmen** ist bei der Veröffentlichung über GitHub Actions standardmäßig ausgewählt, jedoch nicht bei der direkten Veröffentlichung in eine Registry mithilfe einer personal access token.\n\nWenn die Option **Zugriff von Repository erben** bei der Veröffentlichung des Pakets nicht ausgewählt wurde, kannst du das Repository manuell zur Zugriffssteuerung des veröffentlichten Pakets hinzufügen. Weitere Informationen finden Sie unter [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility).\n\n### Zugreifen auf ein Paket, das in der Organisation veröffentlicht wurde, in der ein Codespace gestartet wird\n\nWenn du möchtest, dass ein Paket für alle Codespaces in einer Organisation zugänglich ist, empfehlen wir, es mit interner Sichtbarkeit zu veröffentlichen. Dadurch wird das Paket automatisch für alle Codespaces innerhalb der Organisation sichtbar – es sei denn, das Repository, aus dem der Codespace gestartet wird, ist öffentlich.\n\nWenn der Codespace aus einem öffentlichen Repository gestartet wird, das auf ein internes oder privates Paket verweist, musst du dem öffentlichen Repository manuell Zugriff auf das interne Paket gewähren. So wird verhindert, dass das interne Paket versehentlich öffentlich verfügbar gemacht wird. Weitere Informationen finden Sie unter [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package).\n\n### Zugreifen auf ein privates Paket aus einer Teilmenge der Repositorys in einer Organisation\n\nWenn du einem Teil der Repositorys einer Organisation Zugriff auf ein Paket gewähren oder den Zugriff auf ein internes oder privates Paket von einem Codespace aus zulassen möchtest, der in einem öffentlichen Repository gestartet wurde, kannst du Repositorys manuell zu den Zugriffseinstellungen eines Pakets hinzufügen. Weitere Informationen finden Sie unter [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package).\n\n### Veröffentlichen eines Pakets aus einem Codespace\n\nDer nahtlose Zugriff eines Codespaces auf eine Registrierung ist auf das Pullen von Paketen beschränkt. Wenn Sie ein Paket von innerhalb eines Codespace veröffentlichen möchten, müssen Sie einen personal access token (classic) mit dem `write:packages` Gültigkeitsbereich verwenden.\n\nWir empfehlen, Pakete über GitHub Actions zu veröffentlichen. Weitere Informationen findest du unter [Veröffentlichen von Docker-Images](/de/actions/tutorials/publish-packages/publish-docker-images) und [Node.js-Pakete veröffentlichen](/de/actions/tutorials/publish-packages/publish-nodejs-packages).\n\n## Zugreifen auf in anderen Registrierungen gespeicherte Images\n\nSie können Secrets definieren, um GitHub Codespaces den Zugriff auf andere Container-Image-Registrys als GitHubs Container registry zu ermöglichen. Wenn Sie von einer Registrierung aus auf ein Containerimage zugreifen, das keinen nahtlosen Zugriff unterstützt, überprüfen Sie, GitHub Codespaces ob drei geheime Schlüssel vorhanden sind, die den Servernamen, den Benutzernamen und personal access token eine Registrierung definieren. Wenn diese geheimen Schlüssel gefunden werden, GitHub Codespaces stellt die Registrierung in Ihrem Codespace zur Verfügung.\n\n* `<*>_CONTAINER_REGISTRY_SERVER`\n* `<*>_CONTAINER_REGISTRY_USER`\n* `<*>_CONTAINER_REGISTRY_PASSWORD`\n\nDu kannst Geheimnisse auf Benutzer-, Repository- oder Organisationsebene speichern, sodass du sie sicher zwischen verschiedenen Codespaces austauschen kannst. Wenn du einen Satz von Geheimnissen für eine private Imageregistrierung erstellst, musst du das <\\*> im Namen durch einen einheitlichen Bezeichner ersetzen. Weitere Informationen findest du unter [Verwalten Ihrer kontospezifischen geheimen Schlüssel für GitHub Codespaces](/de/codespaces/managing-your-codespaces/managing-your-account-specific-secrets-for-github-codespaces) und [Verwalten von Entwicklungsumgebungs-Geheimnissen für Ihr Repository oder Ihre Organisation](/de/codespaces/managing-codespaces-for-your-organization/managing-development-environment-secrets-for-your-repository-or-organization).\n\nWenn du die Geheimnisse auf Benutzer- oder Organisationsebene festlegst, stelle sicher, dass du diese Geheimnisse dem Repository zuweist, in dem du den Codespace erstellst. Wähle dazu eine Zugriffsrichtlinie aus der Dropdownliste aus.\n\n<img src=\"/assets/images/help/codespaces/secret-repository-access.png\" alt='Screenshot of the \"Repository access\" dropdown menu with the options \"All repositories,\" \"Private repositories,\" and \"Selected repositories.\"' style=\"width:400px;\"/>\n\n### Pullen eines Docker-Bildes in Ihren Codespace\n\nGitHub Codespaces verwendet Docker. Um daher zur Laufzeit in Ihrem Codespace ein privates Docker-Image abrufen zu können, müssen Sie Docker-in-Docker verwenden können. Um dies zu ermöglichen, werden die Geheimnisse, die für die Anmeldung bei Docker erforderlich sind, automatisch der `~/.docker/config.json`-Datei in Ihrem Codespace hinzugefügt. Dies geschieht nach dem Lebenszyklushook `onCreateCommand`, aber vor `postCreateCommand`, `postStartCommand` und `postAttachCommand`. Daher kann `postCreateCommand` Docker-in-Docker verwenden, um ein Docker-Bild in den Codespace zu ziehen, aber `onCreateCommand` nicht. Aus diesem Grund ist Docker-in-Docker während der Prebuild-Erstellung nicht verfügbar.\n\nNachdem der Codespace ausgeführt wird, können Sie ein Terminal im Codespace öffnen und den Befehl `docker pull PRIVATE-IMAGE-URL` ausführen.\n\n### Beispielgeheimnisse\n\nFür eine private Imageregistrierung in Azure könnten Sie die folgenden geheimen Schlüssel erstellen:\n\n```shell\nACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io\nACR_CONTAINER_REGISTRY_USER = acr-user-here\nACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>\n```\n\nWeitere Informationen zu gängigen Imageregistrierungen findest du unter [Gängige Imageregistrierungsserver](#common-image-registry-servers). Beachte, dass der Zugriff auf AWS Elastic Container Registry (ECR) anders funktioniert.\n\n![Screenshot: Einstellungen für „Codespaces-Geheimnisse“ für ein Repository. Drei Geheimnisse für die ACR-Containerregistrierung sind festgelegt.](/assets/images/help/codespaces/codespaces-image-registry-secret-example.png)\n\nWenn du die Geheimnisse hinzugefügt hast, musst du den Codespace, in dem du dich befindest, möglicherweise anhalten und anschließend neu starten, damit die neuen Umgebungsvariablen an den Container übergeben werden. Weitere Informationen finden Sie unter [Verwenden der Visual Studio Code Befehlspalette in GitHub Codespaces](/de/codespaces/reference/using-the-vs-code-command-palette-in-codespaces#suspending-or-stopping-a-codespace).\n\n#### Zugreifen auf AWS Elastic Container Registry\n\nUm auf AWS Elastic Container Registry (ECR) zuzugreifen, können Sie eine AWS-Zugriffsschlüssel-ID und einen geheimen Zugriffsschlüssel angeben, und GitHub kann für Sie ein Zugriffstoken abrufen und die Anmeldung in Ihrem Namen übernehmen.\n\n```shell\n*_CONTAINER_REGISTRY_SERVER = <ECR_URL>\n*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>\n*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>\n```\n\nAußerdem musst du sicherstellen, dass du über die entsprechenden AWS-IAM-Berechtigungen verfügst, um den Berechtigungstausch (z. B. `sts:GetServiceBearerToken`) und den ECR-Lesevorgang (entweder `AmazonEC2ContainerRegistryFullAccess` oder `ReadOnlyAccess`) durchzuführen.\n\nAlternativ können Sie, wenn Sie nicht möchten, dass GitHub den Austausch von Anmeldeinformationen für Sie durchführt, ein Autorisierungstoken angeben, das über die AWS-APIs oder die CLI abgerufen wurde.\n\n```shell\n*_CONTAINER_REGISTRY_SERVER = <ECR_URL>\n*_CONTAINER_REGISTRY_USER = AWS\n*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>\n```\n\nDa diese Token kurzlebig sind und regelmäßig erneuert werden müssen, empfehlen wir, eine Zugriffsschlüssel-ID und ein Geheimnis anzugeben.\n\nDiese Geheimnisse können zwar einen beliebigen Namen haben, solange es sich bei `*_CONTAINER_REGISTRY_SERVER` um eine ECR-URL handelt, aber wir empfehlen die Verwendung von `ECR_CONTAINER_REGISTRY_*` – es sei denn, du arbeitest mit mehreren ECR-Registrierungen.\n\nWeitere Informationen findest du in der [Dokumentation zur privaten Registrierungsauthentifizierung](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html) von AWS ECR.\n\n### Gängige Imageregistrierungsserver\n\nIm Folgenden sind einige der gängigen Imageregistrierungsserver aufgeführt:\n\n* [DockerHub](https://docs.docker.com/engine/reference/commandline/info/) - `https://index.docker.io/v1/`\n* [GitHub Containerregistrierung](/de/packages/working-with-a-github-packages-registry/working-with-the-container-registry) - `ghcr.io`\n* [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/) - `<registry name>.azurecr.io`\n* [AWS Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) - `<aws_account_id>.dkr.ecr.<region>.amazonaws.com`\n* [Google Cloud Container Registry](https://cloud.google.com/container-registry/docs/overview#registries) - `gcr.io` (USA), `eu.gcr.io` (EU), `asia.gcr.io` (Asien)\n\n## Debuggen des Registrierungszugriffs für private Images\n\nWenn du Probleme hast, ein Image aus einer privaten Imageregistrierung zu pullen, vergewissere dich, dass du `docker login -u <user> -p <password> <server>` mit den Werten der oben definierten Geheimnisse ausführen kannst. Wenn die Anmeldung fehlschlägt, vergewissere dich, dass die Anmeldedaten gültig sind und dass du auf dem Server die geeigneten Berechtigungen hast, um ein Containerimage abzurufen. Wenn die Anmeldung erfolgreich ist, stellen Sie sicher, dass diese Werte entsprechend in die richtigen GitHub Codespaces geheimen Schlüssel kopiert werden, entweder auf Benutzer-, Repository- oder Organisationsebene, und versuchen Sie es erneut."}