169 </Step>169 </Step>
170 170
171 <Step title="Stellen Sie Amazon RDS für PostgreSQL bereit">171 <Step title="Stellen Sie Amazon RDS für PostgreSQL bereit">
172 Die Instanz läuft in den privaten Subnetzen ohne öffentliche Adresse und mit aktivierter Speicherverschlüsselung. Die Engine-Version ist auf Postgres 16 festgelegt, was den unterstützten Boden des Gateways von PostgreSQL 14 erfüllt und garantiert, dass die Parametergruppe unten mit der Instanz übereinstimmt.172 Die Instanz läuft mit Postgres 16 in den privaten Subnetzen, ohne öffentliche Adresse und mit aktivierter Speicherverschlüsselung.
173 173
174 Erstellen Sie zunächst die Subnet-Gruppe, die die Datenbank in den privaten Subnetzen platziert, und eine Parametergruppe mit `rds.force_ssl=1`, damit der Server Klartextverbindungen ablehnt. Die Engine-Version ist einmal festgelegt, da die Parametergruppen-Familie mit der Engine-Hauptversion übereinstimmen muss, die die Instanz ausführt:174 Erstellen Sie zunächst die Subnet-Gruppe, die die Datenbank in den privaten Subnetzen platziert, und eine Parametergruppe mit `rds.force_ssl=1`, damit der Server Klartextverbindungen ablehnt. Die Engine-Version ist einmal festgelegt, da die Parametergruppen-Familie mit der Engine-Hauptversion übereinstimmen muss, die die Instanz ausführt:
175 175
201 --no-publicly-accessible --storage-encrypted201 --no-publicly-accessible --storage-encrypted
202 ```202 ```
203 203
204 Das Literal `--master-user-password` Argument ist in der Prozesstabelle und in Audit-/EDR-Protokollen sichtbar, während der Befehl ausgeführt wird, die gleiche Exposition, die der Geheimnisse-Schritt behandelt. Auf einem gemeinsamen oder überwachten Host übergeben Sie das Passwort stattdessen über `--cli-input-json` aus einer `0600` Datei, wie es das `setup.sh` des Bundles tut.204 Das Literal `--master-user-password` Argument ist in der Prozesstabelle und in Audit-/EDR-Logs sichtbar, während der Befehl ausgeführt wird, die gleiche Exposition, die der Geheimnisse-Schritt behandelt. Auf einem gemeinsamen oder überwachten Host übergeben Sie das Passwort stattdessen über `--cli-input-json` aus einer `0600` Datei, wie es das `setup.sh` des Bundles tut.
205 205
206 Warten Sie, bis die Instanz hochfährt, was mehrere Minuten dauern kann, lesen Sie dann ihren privaten Endpunkt und stellen Sie die Verbindungszeichenfolge zusammen, die das Gateway verwendet:206 Warten Sie, bis die Instanz hochfährt, was mehrere Minuten dauern kann, lesen Sie dann ihren privaten Endpunkt und stellen Sie die Verbindungszeichenfolge zusammen, die das Gateway verwendet:
207 207
223 Zwei `listen` Felder beschreiben, was das Gateway frontet:223 Zwei `listen` Felder beschreiben, was das Gateway frontet:
224 224
225 * `public_url`: die externe `https://` Herkunft, erforderlich für jeden nicht-Loopback-Bind; siehe die [`listen` Referenz](/docs/de/claude-apps-gateway-config#listen). Das Gateway erstellt den IdP `redirect_uri` und sein Discovery-Dokument nur aus diesem Wert, niemals aus `X-Forwarded-*` Headern.225 * `public_url`: die externe `https://` Herkunft, erforderlich für jeden nicht-Loopback-Bind; siehe die [`listen` Referenz](/docs/de/claude-apps-gateway-config#listen). Das Gateway erstellt den IdP `redirect_uri` und sein Discovery-Dokument nur aus diesem Wert, niemals aus `X-Forwarded-*` Headern.
226 * `trusted_proxies`: die Quellbereiche des Front-End. Das Gateway berücksichtigt `X-Forwarded-For` nur, wenn der TCP-Peer in dieser Liste ist, geht dann die Kette über vertrauenswürdige Hops, sodass Anmelderate-Limits pro IP und Audit-Events Entwickler-IPs statt der Load-Balancer-IP aufzeichnen.226 * `trusted_proxies`: die Quellbereiche des Front-End. Das Gateway berücksichtigt `X-Forwarded-For` nur, wenn der TCP-Peer in dieser Liste ist, geht dann die Kette über vertrauenswürdige Hops, sodass Anmelde-Rate-Limits pro IP und Audit-Events Entwickler-IPs statt der Load-Balancer-IP aufzeichnen.
227 227
228 Auf beiden Pfaden ist das Front-End ein interner ALB, ob direkt erstellt oder vom AWS Load Balancer Controller, und ALB-Knoten nehmen Adressen aus den Subnetzen, an die sie angehängt sind, daher setzen Sie `trusted_proxies` auf die CIDRs dieser Subnetze. Dies vertraut jedem Host in diesen Subnetzen als Proxy. Halten Sie die Ingress-Quelle des ALB, Ihre Unternehmens-CIDR, davon ab, sich zu überlappen, und teilen Sie die Subnetze nicht mit nicht vertrauenswürdigen Workloads, die Client-IPs über `X-Forwarded-For` fälschen könnten.228 Auf beiden Pfaden ist das Front-End ein interner ALB, ob direkt erstellt oder vom AWS Load Balancer Controller, und ALB-Knoten nehmen Adressen aus den Subnetzen, an die sie angehängt sind, daher setzen Sie `trusted_proxies` auf die CIDRs dieser Subnetze. Dies vertraut jedem Host in diesen Subnetzen als Proxy. Halten Sie die Ingress-Quelle des ALB, Ihre Unternehmens-CIDR, davon ab, sich zu überlappen, und teilen Sie die Subnetze nicht mit nicht vertrauenswürdigen Workloads, die Client-IPs über `X-Forwarded-For` fälschen könnten.
229 229
286 Beachten Sie die ARN, die jeder Aufruf ausgibt; die ECS-Task-Definition referenziert Geheimnisse nach ARN.286 Beachten Sie die ARN, die jeder Aufruf ausgibt; die ECS-Task-Definition referenziert Geheimnisse nach ARN.
287 287
288 <Note>288 <Note>
289 Literal `--secret-string` Argumente sind in der Prozesstabelle und in Audit-/EDR-Protokollen sichtbar, während jeder Befehl ausgeführt wird. Auf einem gemeinsamen oder überwachten Host legen Sie den Wert in eine `0600` Datei und übergeben Sie stattdessen `--secret-string file://<path>`. Das `setup.sh` des Bundles hält Geheimniswerte auf die gleiche Weise aus dem Prozess-argv, indem es `0600` temporäre Dateien an `--cli-input-json` übergibt.289 Literal `--secret-string` Argumente sind in der Prozesstabelle und in Audit-/EDR-Logs sichtbar, während jeder Befehl ausgeführt wird. Auf einem gemeinsamen oder überwachten Host legen Sie den Wert in eine `0600` Datei und übergeben Sie stattdessen `--secret-string file://<path>`. Das `setup.sh` des Bundles hält Geheimniswerte auf die gleiche Weise aus dem Prozess-argv, indem es `0600` temporäre Dateien an `--cli-input-json` übergibt.
290 </Note>290 </Note>
291 291
292 Im Gegensatz zu den Geheimnissen enthält `gateway.yaml` selbst keine Geheimniswerte, da jede Anmeldedaten beim Start über [`${VAR}` oder `${file:...}` Erweiterung](/docs/de/claude-apps-gateway-config#secret-expansion) aufgelöst wird. Wie alles den Container erreicht, unterscheidet sich je nach Pfad:292 Im Gegensatz zu den Geheimnissen enthält `gateway.yaml` selbst keine Geheimniswerte, da alle Anmeldedaten beim Start über [`${VAR}` oder `${file:...}` Erweiterung](/docs/de/claude-apps-gateway-config#secret-expansion) aufgelöst werden. Wie alles den Container erreicht, unterscheidet sich je nach Pfad:
293 293
294 * Auf ECS kopiert der Build des nächsten Schritts `gateway.yaml` in das Image bei `/etc/claude/gateway.yaml`, und die Task-Definition injiziert die drei Geheimnisse als Umgebungsvariablen über sein `secrets` Feld, daher referenziert die YAML `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` und `${GATEWAY_POSTGRES_URL}`.294 * Auf ECS kopiert der Build des nächsten Schritts `gateway.yaml` in das Image bei `/etc/claude/gateway.yaml`, und die Task-Definition injiziert die drei Geheimnisse als Umgebungsvariablen über ihr `secrets` Feld, daher referenziert die YAML `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` und `${GATEWAY_POSTGRES_URL}`.
295 * Auf EKS mounten Sie `gateway.yaml` aus einer ConfigMap und die Geheimnisse als Dateien bei `/secrets`, referenziert als `${file:/secrets/...}`. Beziehen Sie die Kubernetes Secrets aus Secrets Manager mit dem External Secrets Operator oder dem AWS-Provider des Secrets Store CSI-Treibers, oder erstellen Sie sie direkt mit `kubectl`.295 * Auf EKS mounten Sie `gateway.yaml` aus einer ConfigMap und die Geheimnisse als Dateien bei `/secrets`, referenziert als `${file:/secrets/...}`. Beziehen Sie die Kubernetes Secrets aus Secrets Manager mit dem External Secrets Operator oder dem AWS-Provider des Secrets Store CSI-Treibers, oder erstellen Sie sie direkt mit `kubectl`.
296 </Step>296 </Step>
297 297
335 <Step title="Bereitstellen">335 <Step title="Bereitstellen">
336 <Tabs>336 <Tabs>
337 <Tab title="ECS Fargate">337 <Tab title="ECS Fargate">
338 Erstellen Sie den Cluster und eine Log-Gruppe für die stderr des Gateways, die sowohl seine Audit-Events als auch Betriebsprotokolle trägt. Die Aufbewahrung ist ein separater Aufruf, und ohne eine CloudWatch behält die Protokolle für immer; richten Sie die 90 Tage auf Ihre Audit-Aufbewahrungsrichtlinie aus:338 Erstellen Sie den Cluster und eine Log-Gruppe für die stderr des Gateways, die sowohl seine Audit-Events als auch Betriebslogs trägt. Die Aufbewahrung ist ein separater Aufruf, und ohne einen behält CloudWatch die Logs für immer; richten Sie die 90 Tage auf Ihre Audit-Aufbewahrungsrichtlinie aus:
339 339
340 ```bash theme={null}340 ```bash theme={null}
341 aws ecs create-cluster --cluster-name claude-gateway341 aws ecs create-cluster --cluster-name claude-gateway
401 401
402 Fügen Sie den HTTPS-Listener hinzu. `--ssl-policy` pinnt einen modernen TLS-Boden, da das Weglassen auf die Legacy-Standard-Richtlinie `ELBSecurityPolicy-2016-08` zurückfällt, die immer noch TLS 1.0/1.1 akzeptiert.402 Fügen Sie den HTTPS-Listener hinzu. `--ssl-policy` pinnt einen modernen TLS-Boden, da das Weglassen auf die Legacy-Standard-Richtlinie `ELBSecurityPolicy-2016-08` zurückfällt, die immer noch TLS 1.0/1.1 akzeptiert.
403 403
404 Der ALB schließt eine Verbindung nach 60 Sekunden ohne Daten standardmäßig. Die Keepalive-Pings des Gateways halten Streams innerhalb dieses Standards, daher erhöht das Erhöhen des Timeouts die Marge über der Ping-Kadenz; die [Troubleshooting](#troubleshooting) Zeile auf abgebrochenen Streams behandelt den Mechanismus und ältere Gateways. Die folgenden Befehle fügen den Listener hinzu und erhöhen das Timeout:404 Der ALB schließt eine Verbindung nach 60 Sekunden ohne Daten standardmäßig. Die Keepalive-Pings des Gateways halten Streams innerhalb dieses Standards, daher erhöht das Erhöhen des Timeouts die Marge über der Ping-Kadenz; die Zeile zu abgebrochenen Streams in der [Fehlerbehebung](#troubleshooting) behandelt den Mechanismus und ältere Gateways. Die folgenden Befehle fügen den Listener hinzu und erhöhen den Timeout:
405 405
406 ```bash theme={null}406 ```bash theme={null}
407 aws elbv2 create-listener --load-balancer-arn "$ALB_ARN" \407 aws elbv2 create-listener --load-balancer-arn "$ALB_ARN" \
425 --load-balancers "targetGroupArn=$TG_ARN,containerName=gateway,containerPort=8080"425 --load-balancers "targetGroupArn=$TG_ARN,containerName=gateway,containerPort=8080"
426 ```426 ```
427 427
428 Die 60-Sekunden-Gnadenfrist gibt einer kalten Task Zeit, das Image zu ziehen, sich mit dem Store zu verbinden und seinen ersten Health-Check zu beantworten, bevor ECS beginnt, Fehler gegen die Bereitstellung zu zählen. Der Health-Check der Zielgruppe auf `GET /readyz` überprüft, ob der Store erreichbar ist, daher kommt eine Task, die Postgres nicht erreichen kann, nie in Rotation. Um Tasks durch einen kurzen Datenbankausfall wie ein RDS-Failover hindurch den Health-Check bestehen zu lassen, setzen Sie `store.readiness_grace_seconds` wie in [Ausfallverhalten](/docs/de/claude-apps-gateway-deploy#outage-behavior) beschrieben, das auch die `/healthz` Alternative abdeckt.428 Die 60-Sekunden-Gnadenfrist gibt einer kalten Task Zeit, das Image zu ziehen, sich mit dem Store zu verbinden und seinen ersten Health-Check zu beantworten, bevor ECS beginnt, Fehler gegen die Bereitstellung zu zählen.
429
430 Der Health-Check der Zielgruppe auf `GET /readyz` überprüft, ob der Store erreichbar ist, daher kommt eine Task, die Postgres nicht erreichen kann, nie in Rotation. Um Tasks durch einen kurzen Datenbankausfall wie ein RDS-Failover hindurch den Health-Check bestehen zu lassen, setzen Sie `store.readiness_grace_seconds` wie in [Ausfallverhalten](/docs/de/claude-apps-gateway-deploy#outage-behavior) beschrieben, das auch die `/healthz` Alternative abdeckt.
429 431
430 Die Tasks laufen in privaten Subnetzen ohne öffentliche IP, daher geht der gesamte Egress (zu Bedrock, Ihrem IdP, Secrets Manager, ECR und CloudWatch Logs) durch das NAT-Gateway. Um Bedrock-Verkehr vom öffentlichen Pfad zu halten, erstellen Sie einen `bedrock-runtime` Interface VPC-Endpunkt und zeigen Sie die `base_url` des Upstream darauf, wie in der [Bedrock Upstream-Referenz](/docs/de/claude-apps-gateway-config#amazon-bedrock) gezeigt; der IdP benötigt immer noch Internet-Egress.432 Die Tasks laufen in privaten Subnetzen ohne öffentliche IP, daher geht der gesamte Egress (zu Bedrock, Ihrem IdP, Secrets Manager, ECR und CloudWatch Logs) durch das NAT-Gateway. Um Bedrock-Verkehr vom öffentlichen Pfad zu halten, erstellen Sie einen `bedrock-runtime` Interface VPC-Endpunkt und zeigen Sie die `base_url` des Upstream darauf, wie in der [Bedrock Upstream-Referenz](/docs/de/claude-apps-gateway-config#amazon-bedrock) gezeigt; der IdP benötigt immer noch Internet-Egress.
431 433
432 Beenden Sie, indem Sie Entwicklern einen privat auflösbaren Hostnamen geben: In einer Route 53 privaten gehosteten Zone, alias den internen DNS-Namen des Gateways zum ALB, und setzen Sie `listen.public_url` auf diesen Hostnamen. Der eigene `*.elb.amazonaws.com` Name des ALB wird zu privaten Adressen auf einem internen ALB aufgelöst, kann aber Ihr ACM-Zertifikat nicht tragen, daher verwenden Sie Ihren eigenen Namen.434 Beenden Sie, indem Sie Entwicklern einen privat auflösbaren Hostnamen geben: In einer Route 53 privaten gehosteten Zone, alias den internen DNS-Namen des Gateways zum ALB, und setzen Sie `listen.public_url` auf diesen Hostnamen. Der eigene `*.elb.amazonaws.com` Name des ALB wird zu privaten Adressen auf einem internen ALB aufgelöst, kann aber Ihr ACM-Zertifikat nicht tragen, daher verwenden Sie Ihren eigenen Namen.
433 435
434 Aktualisieren Sie die autorisierte Redirect-URI des OAuth-Clients auf `<public_url>/oauth/callback`, bevor die erste Anmeldung. Nach dem Ändern von `public_url` erstellen Sie das Image unter einem neuen Tag neu, registrieren Sie eine neue Task-Definition-Revision und stellen Sie erneut bereit. Auf ECS lebt die Einstellung in der eingebetteten `gateway.yaml` des Images, und das Gateway erstellt seinen öffentlichen Ursprung nur aus dieser Einstellung, ignoriert `X-Forwarded-Host` und `X-Forwarded-Proto`. `X-Forwarded-For` wird nur berücksichtigt, wenn `listen.trusted_proxies` gesetzt ist.436 Aktualisieren Sie die autorisierte Redirect-URI des OAuth-Clients auf `<public_url>/oauth/callback` vor der ersten Anmeldung. Nach dem Ändern von `public_url` erstellen Sie das Image unter einem neuen Tag neu, registrieren Sie eine neue Task-Definition-Revision und stellen Sie erneut bereit. Auf ECS lebt die Einstellung in der eingebetteten `gateway.yaml` des Images, und das Gateway erstellt seinen öffentlichen Ursprung nur aus dieser Einstellung, ignoriert `X-Forwarded-Host` und `X-Forwarded-Proto`. `X-Forwarded-For` wird für Client-IPs nur berücksichtigt, wenn `listen.trusted_proxies` gesetzt ist.
435 </Tab>437 </Tab>
436 438
437 <Tab title="EKS">439 <Tab title="EKS">
438 Dieser Pfad benötigt `kubectl` und `eksctl` lokal installiert, und einen bestehenden EKS-Cluster mit einem IAM OIDC-Provider und dem AWS Load Balancer Controller installiert. Der Cluster muss auf `$VPC_ID` sein, damit Pods den RDS-Privatendpunkt erreichen können, und die `claude-gateway-db` Sicherheitsgruppe muss die Sicherheitsgruppe des Clusters oder des Pods des Clusters anstelle von `$GW_SG` zulassen.440 Dieser Pfad benötigt `kubectl` und `eksctl` lokal installiert, und einen bestehenden EKS-Cluster mit einem IAM OIDC-Provider und dem AWS Load Balancer Controller installiert. Der Cluster muss auf `$VPC_ID` sein, damit Pods den RDS-Privatendpunkt erreichen können, und die `claude-gateway-db` Sicherheitsgruppe muss die Pod- oder Node-Sicherheitsgruppe des Clusters anstelle von `$GW_SG` zulassen.
439 441
440 Auf EKS erhält das Gateway seine Bedrock-Anmeldedaten über IRSA statt der ECS-Rollen. Die `ecs-tasks.amazonaws.com` Vertrauensrichtlinie aus dem IAM-Schritt gilt hier nicht; IRSA benötigt eine Rolle, deren Vertrauensrichtlinie auf dem OIDC-Provider des Clusters föderiert ist, begrenzt auf `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` erstellt diese Rolle, hängt die Richtlinien an und kommentiert das Kubernetes-Dienstkonto mit der Rollen-ARN in einem Schritt. Verwandeln Sie die zwei Richtliniendokumente aus dem IAM-Schritt in verwaltete Richtlinien, die es anhängen kann:442 Auf EKS erhält das Gateway seine Bedrock-Anmeldedaten über IRSA statt der ECS-Rollen. Die `ecs-tasks.amazonaws.com` Vertrauensrichtlinie aus dem IAM-Schritt gilt hier nicht; IRSA benötigt eine Rolle, deren Vertrauensrichtlinie auf dem OIDC-Provider des Clusters föderiert ist, begrenzt auf `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` erstellt diese Rolle, hängt die Richtlinien an und kommentiert das Kubernetes-Dienstkonto mit der Rollen-ARN in einem Schritt. Verwandeln Sie die zwei Richtliniendokumente aus dem IAM-Schritt in verwaltete Richtlinien, die es anhängen kann:
441 443
453 --approve455 --approve
454 ```456 ```
455 457
456 Die Geheimnisse-Richtlinie wird nur benötigt, wenn die Pods Secrets Manager selbst lesen, wie es der AWS-Provider des Secrets Store CSI-Treibers mit dem Dienstkonto des Mounting-Pods tut; lassen Sie sie weg, wenn Sie die Kubernetes Secrets auf andere Weise erstellen. Der Provider benötigt beide Aktionen der Richtlinie: Er ruft `DescribeSecret` auf, wenn er rotierte Geheimnisse abstimmt, daher gewährt ein `GetSecretValue`-only Grant Mounts beim ersten Deploy, stoppt aber das Abholen von Rotationen.458 Die Geheimnisse-Richtlinie wird nur benötigt, wenn die Pods Secrets Manager selbst lesen, wie es der AWS-Provider des Secrets Store CSI-Treibers mit dem Dienstkonto des Mounting-Pods tut; lassen Sie sie weg, wenn Sie die Kubernetes Secrets auf andere Weise erstellen. Der Provider benötigt beide Aktionen der Richtlinie: Er ruft `DescribeSecret` auf, wenn er rotierte Geheimnisse abstimmt, daher funktioniert ein Grant nur mit `GetSecretValue` beim ersten Deploy, übernimmt aber keine Rotationen mehr.
457 459
458 Stellen Sie das Gateway als Standard-Deployment plus Service und Ingress bereit, wie in [Kubernetes-Bereitstellung](/docs/de/claude-apps-gateway-deploy#kubernetes) beschrieben, mit:460 Stellen Sie das Gateway als Standard-Deployment plus Service und Ingress bereit, wie in [Kubernetes-Bereitstellung](/docs/de/claude-apps-gateway-deploy#kubernetes) beschrieben, mit:
459 461
460 * `serviceAccountName: gateway`462 * `serviceAccountName: gateway`
461 * `gateway.yaml` gemountet aus einer ConfigMap und die Geheimnisse als Dateien bei `/secrets` gemountet463 * `gateway.yaml` gemountet aus einer ConfigMap und die Geheimnisse bei `/secrets` gemountet
462 * die Readiness-Probe auf `GET /readyz` gerichtet464 * die Readiness-Probe auf `GET /readyz` gerichtet
463 465
464 Für das Front-End, ein Ingress, das vom AWS Load Balancer Controller verwaltet wird, stellt den internen ALB bereit. Kommentieren Sie es mit:466 Für das Front-End stellt ein Ingress, das vom AWS Load Balancer Controller verwaltet wird, den internen ALB bereit. Annotieren Sie es mit:
465 467
466 * `alb.ingress.kubernetes.io/scheme: internal` und `alb.ingress.kubernetes.io/target-type: ip`468 * `alb.ingress.kubernetes.io/scheme: internal` und `alb.ingress.kubernetes.io/target-type: ip`
467 * `alb.ingress.kubernetes.io/ip-address-type: ipv4`, daher werden keine öffentlichen AAAA-Datensätze für die `/login` [private-Netzwerk-Prüfung](/docs/de/claude-apps-gateway#prerequisites) veröffentlicht, die sie ablehnt469 * `alb.ingress.kubernetes.io/ip-address-type: ipv4`, daher werden keine öffentlichen AAAA-Datensätze veröffentlicht, die die `/login` [private-Netzwerk-Prüfung](/docs/de/claude-apps-gateway#prerequisites) ablehnen würde
468 * `alb.ingress.kubernetes.io/inbound-cidrs: <your-corporate-cidr>`, daher lässt die Controller-verwaltete Frontend-Sicherheitsgruppe nur Ihr Unternehmensnetzwerk anstelle des `0.0.0.0/0` Standards zu470 * `alb.ingress.kubernetes.io/inbound-cidrs: <your-corporate-cidr>`, daher lässt die Controller-verwaltete Frontend-Sicherheitsgruppe nur Ihr Unternehmensnetzwerk anstelle des `0.0.0.0/0` Standards zu
469 * `alb.ingress.kubernetes.io/certificate-arn` mit dem ACM-Zertifikat471 * `alb.ingress.kubernetes.io/certificate-arn` mit dem ACM-Zertifikat
470 * `alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06`, daher fällt der Listener nicht auf die Legacy-Standard-Richtlinie zurück, die TLS 1.0 und 1.1 akzeptiert472 * `alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06`, daher fällt der Listener nicht auf die Legacy-Standard-Richtlinie zurück, die TLS 1.0 und 1.1 akzeptiert
471 * `alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=3600`, eine Marge über dem Streaming-Keepalive des Gateways; siehe [Troubleshooting](#troubleshooting)473 * `alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=3600`, eine Marge über dem Streaming-Keepalive des Gateways; siehe [Fehlerbehebung](#troubleshooting)
472 474
473 Mit IRSA liest das AWS SDK ein projiziertes Service-Account-Token und tauscht es mit AWS STS aus, daher benötigt der Pod niemals den EC2-Instanz-Metadaten-Service; eine Egress-NetworkPolicy kann `169.254.169.254` für Gateway-Pods blockieren. Das Node-Hop-Limit-Problem in [Troubleshooting](#troubleshooting) unten gilt nur für Cluster, die IRSA überspringen und sich auf Node-Instanzrollen verlassen.475 Mit IRSA liest das AWS SDK ein projiziertes Service-Account-Token und tauscht es mit AWS STS aus, daher benötigt der Pod niemals den EC2-Instanz-Metadaten-Service; eine Egress-NetworkPolicy kann `169.254.169.254` für Gateway-Pods blockieren. Das Node-Hop-Limit-Problem in der [Fehlerbehebung](#troubleshooting) unten gilt nur für Cluster, die IRSA überspringen und sich auf Node-Instanzrollen verlassen.
474 </Tab>476 </Tab>
475 </Tabs>477 </Tabs>
476 </Step>478 </Step>
477 479
478 <Step title="Pushen Sie die Gateway-URL zu Entwicklermaschinen">480 <Step title="Pushen Sie die Gateway-URL zu Entwicklermaschinen">
479 Das Gateway läuft jetzt, aber Entwickler können es von `/login` nicht erreichen, bis die Gateway-URL auf ihren Maschinen ist. Setzen Sie `forceLoginMethod` und `forceLoginGatewayUrl` in der [verwalteten Einstellungsdatei](/docs/de/claude-apps-gateway#set-the-gateway-url), die Sie über MDM auf jedes Gerät bereitstellen. Es gibt keine Gateway-Option im Login-Picker für einen Entwickler, um manuell auszuwählen.481 Das Gateway läuft jetzt, aber Entwickler können es von `/login` nicht erreichen, bis die Gateway-URL auf ihren Maschinen ist. Setzen Sie `forceLoginMethod` und `forceLoginGatewayUrl` in der [verwalteten Einstellungsdatei](/docs/de/claude-apps-gateway#set-the-gateway-url), die Sie über MDM auf jedes Gerät bereitstellen. Es gibt keine Gateway-Option im Login-Picker, die ein Entwickler manuell auswählen könnte.
480 </Step>482 </Step>
481</Steps>483</Steps>
482 484
