169 </Step>169 </Step>
170 170
171 <Step title="Provisionner Amazon RDS pour PostgreSQL">171 <Step title="Provisionner Amazon RDS pour PostgreSQL">
172 L'instance s'exécute dans les sous-réseaux privés sans adresse publique et avec le chiffrement du stockage activé. La version du moteur est épinglée à Postgres 16, ce qui satisfait le plancher pris en charge de PostgreSQL 14 de la passerelle et garantit que la famille du groupe de paramètres ci-dessous correspond à l'instance.172 L'instance exécute Postgres 16 dans les sous-réseaux privés, sans adresse publique et avec le chiffrement du stockage activé.
173 173
174 Tout d'abord, créez le groupe de sous-réseaux qui place la base de données dans les sous-réseaux privés, et un groupe de paramètres avec `rds.force_ssl=1` pour que le serveur rejette les connexions en texte brut. La version du moteur est épinglée une fois car la famille du groupe de paramètres doit correspondre à la version majeure du moteur que l'instance exécute :174 Tout d'abord, créez le groupe de sous-réseaux qui place la base de données dans les sous-réseaux privés, et un groupe de paramètres avec `rds.force_ssl=1` pour que le serveur rejette les connexions en texte brut. La version du moteur est épinglée une fois car la famille du groupe de paramètres doit correspondre à la version majeure du moteur que l'instance exécute :
175 175
203 203
204 L'argument littéral `--master-user-password` est visible dans la table des processus et dans les journaux d'audit/EDR pendant l'exécution de la commande, la même exposition que celle couverte par la note de l'étape des secrets. Sur un hôte partagé ou surveillé, passez le mot de passe via `--cli-input-json` à partir d'un fichier `0600` à la place, de la même façon que le `setup.sh` du bundle.204 L'argument littéral `--master-user-password` est visible dans la table des processus et dans les journaux d'audit/EDR pendant l'exécution de la commande, la même exposition que celle couverte par la note de l'étape des secrets. Sur un hôte partagé ou surveillé, passez le mot de passe via `--cli-input-json` à partir d'un fichier `0600` à la place, de la même façon que le `setup.sh` du bundle.
205 205
206 Attendez que l'instance soit opérationnelle, ce qui peut prendre plusieurs minutes, puis lisez son point de terminaison privé et assemblez la chaîne de connexion que la passerelle utilisera :206 Attendez que l'instance soit opérationnelle, ce qui peut prendre plusieurs minutes, puis lisez son endpoint privé et assemblez la chaîne de connexion que la passerelle utilisera :
207 207
208 ```bash theme={null}208 ```bash theme={null}
209 aws rds wait db-instance-available --db-instance-identifier claude-gateway-db209 aws rds wait db-instance-available --db-instance-identifier claude-gateway-db
212 GATEWAY_POSTGRES_URL="postgres://gateway:${PGPASS}@${DB_HOST}:5432/claude_gateway?sslmode=verify-full"212 GATEWAY_POSTGRES_URL="postgres://gateway:${PGPASS}@${DB_HOST}:5432/claude_gateway?sslmode=verify-full"
213 ```213 ```
214 214
215 `sslmode=verify-full` fait que la passerelle vérifie la chaîne du certificat du serveur RDS et le nom d'hôte, pas seulement le chiffrement. L'ancre de confiance est le [bundle de certificats AWS RDS](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem), que l'étape de construction d'image ci-dessous copie à `/etc/claude/rds-global-bundle.pem` et approuve via `NODE_EXTRA_CA_CERTS`. N'ajoutez pas de paramètre `sslrootcert=` de style libpq à l'URL : le pilote de la passerelle lit uniquement `sslmode` à partir de la chaîne de requête et transmettrait `sslrootcert` à Postgres en tant que paramètre de démarrage, que le serveur rejette.215 `sslmode=verify-full` fait que la passerelle vérifie la chaîne du certificat du serveur RDS et le nom d'hôte, pas seulement le chiffrement. L'ancre de confiance est le [bundle de certificats AWS RDS](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem), que l'étape de build d'image ci-dessous copie à `/etc/claude/rds-global-bundle.pem` et approuve via `NODE_EXTRA_CA_CERTS`. N'ajoutez pas de paramètre `sslrootcert=` de style libpq à l'URL : le pilote de la passerelle lit uniquement `sslmode` à partir de la chaîne de requête et transmettrait `sslrootcert` à Postgres en tant que paramètre de démarrage, que le serveur rejette.
216 216
217 Le service ECS ou les pods EKS doivent s'exécuter dans ce VPC pour pouvoir atteindre le point de terminaison privé de l'instance, et le groupe de sécurité `claude-gateway-db` n'admet que le groupe de sécurité de la passerelle.217 Le service ECS ou les pods EKS doivent s'exécuter dans ce VPC pour pouvoir atteindre l'endpoint privé de l'instance, et le groupe de sécurité `claude-gateway-db` n'admet que le groupe de sécurité de la passerelle.
218 </Step>218 </Step>
219 219
220 <Step title="Écrire gateway.yaml">220 <Step title="Écrire gateway.yaml">
221 Le bloc `upstreams` pointe vers Bedrock avec `auth: {}`, donc la passerelle s'authentifie via la chaîne de credentials par défaut d'AWS à partir du rôle de tâche sur ECS ou du rôle IRSA sur EKS. Consultez la [référence de configuration](/docs/fr/claude-apps-gateway-config) pour chaque champ.221 Le bloc `upstreams` pointe vers Bedrock avec `auth: {}`, donc la passerelle s'authentifie via la chaîne d'identifiants par défaut d'AWS à partir du rôle de tâche sur ECS ou du rôle IRSA sur EKS. Consultez la [référence de configuration](/docs/fr/claude-apps-gateway-config) pour chaque champ.
222 222
223 Deux champs `listen` décrivent ce qui est en face de la passerelle :223 Deux champs `listen` décrivent ce qui est en face de la passerelle :
224 224
225 * `public_url` : l'origine `https://` externe, requise pour tout bind non-loopback ; consultez la [référence `listen`](/docs/fr/claude-apps-gateway-config#listen). La passerelle construit l'`redirect_uri` de l'IdP et son document de découverte uniquement à partir de cette valeur, jamais à partir des en-têtes `X-Forwarded-*`.225 * `public_url` : l'origine `https://` externe, requise pour tout bind non-loopback ; consultez la [référence `listen`](/docs/fr/claude-apps-gateway-config#listen). La passerelle construit l'`redirect_uri` de l'IdP et son document de découverte uniquement à partir de cette valeur, jamais à partir des en-têtes `X-Forwarded-*`.
226 * `trusted_proxies` : les plages source du frontal. La passerelle honore `X-Forwarded-For` uniquement lorsque le pair TCP est dans cette liste, puis parcourt la chaîne au-delà des sauts de confiance, donc les limites de taux de connexion par IP et les événements d'audit enregistrent les adresses IP des développeurs au lieu de celle de l'équilibreur de charge.226 * `trusted_proxies` : les plages source du frontal. La passerelle honore `X-Forwarded-For` uniquement lorsque le pair TCP est dans cette liste, puis parcourt la chaîne au-delà des sauts de confiance, donc les limites de débit de connexion par IP et les événements d'audit enregistrent les adresses IP des développeurs au lieu de celle de l'équilibreur de charge.
227 227
228 Sur les deux pistes, le frontal est un ALB interne, qu'il soit créé directement ou par le contrôleur AWS Load Balancer, et les nœuds d'un ALB prennent des adresses à partir des sous-réseaux auxquels il est attaché, donc définissez `trusted_proxies` sur les CIDR de ces sous-réseaux. Cela approuve chaque hôte de ces sous-réseaux en tant que proxy. Gardez la source d'entrée de l'ALB, votre CIDR d'entreprise, de ne pas chevaucher, et ne partagez pas les sous-réseaux avec des charges de travail non fiables qui pourraient usurper les adresses IP des clients via `X-Forwarded-For`.228 Sur les deux pistes, le frontal est un ALB interne, qu'il soit créé directement ou par le contrôleur AWS Load Balancer, et les nœuds d'un ALB prennent des adresses à partir des sous-réseaux auxquels il est attaché, donc définissez `trusted_proxies` sur les CIDR de ces sous-réseaux. Cela approuve chaque hôte de ces sous-réseaux en tant que proxy. Veillez à ce que la source d'entrée de l'ALB, votre CIDR d'entreprise, ne les chevauche pas, et ne partagez pas les sous-réseaux avec des charges de travail non fiables qui pourraient usurper les adresses IP des clients via `X-Forwarded-For`.
229 229
230 L'attribut de préservation du port client de l'ALB, `routing.http.xff_client_port.enabled`, peut rester à l'un ou l'autre paramètre : avec lui activé, l'ALB écrit le client comme `203.0.113.7:54321` ou `[2001:db8::1]:54321`, et la passerelle lit les deux avec le port supprimé.230 L'attribut de préservation du port client de l'ALB, `routing.http.xff_client_port.enabled`, peut rester à l'un ou l'autre paramètre : avec lui activé, l'ALB écrit le client comme `203.0.113.7:54321` ou `[2001:db8::1]:54321`, et la passerelle lit les deux avec le port supprimé.
231 231
244 # Le serveur d'autorisation org Okta retourne un id_token mince qui omet244 # Le serveur d'autorisation org Okta retourne un id_token mince qui omet
245 # l'email et les groupes ; la passerelle les remplit à partir de /userinfo.245 # l'email et les groupes ; la passerelle les remplit à partir de /userinfo.
246 userinfo_fallback: true246 userinfo_fallback: true
247 # Okta émet des groupes uniquement lorsque la portée `groups` est demandée et que247 # Okta émet des groupes uniquement lorsque le scope `groups` est demandé et que
248 # le filtre de revendication de groupes de l'application les autorise.248 # le filtre de revendication de groupes de l'application les autorise.
249 scopes: [openid, profile, email, offline_access, groups]249 scopes: [openid, profile, email, offline_access, groups]
250 250
262 - provider: bedrock262 - provider: bedrock
263 region: <your-region> # correspondre à $AWS_REGION pour que les ARN de la politique IAM263 region: <your-region> # correspondre à $AWS_REGION pour que les ARN de la politique IAM
264 # le couvrent264 # le couvrent
265 auth: {} # chaîne de credentials par défaut d'AWS :265 auth: {} # chaîne d'identifiants par défaut d'AWS :
266 # rôle de tâche ECS, ou IRSA sur EKS266 # rôle de tâche ECS, ou IRSA sur EKS
267 ```267 ```
268 268
269 <Note>269 <Note>
270 Seul le bloc `oidc` est spécifique à Okta. Pour utiliser Microsoft Entra ID à la place, définissez `issuer` sur `https://login.microsoftonline.com/<tenant-id>/v2.0`, supprimez `userinfo_fallback` et la portée `groups`, et notez qu'Entra émet des ID d'objet de groupe plutôt que des noms, donc [`managed.policies`](/docs/fr/claude-apps-gateway-config#managed) doit correspondre sur les GUID, ou sur les rôles d'application avec `oidc.groups_claim: roles`. Consultez [Configuration du fournisseur d'identité](/docs/fr/claude-apps-gateway-deploy#identity-provider-setup).270 Seul le bloc `oidc` est spécifique à Okta. Pour utiliser Microsoft Entra ID à la place, définissez `issuer` sur `https://login.microsoftonline.com/<tenant-id>/v2.0`, supprimez `userinfo_fallback` et le scope `groups`, et notez qu'Entra émet des ID d'objet de groupe plutôt que des noms, donc [`managed.policies`](/docs/fr/claude-apps-gateway-config#managed) doit correspondre sur les GUID, ou sur les rôles d'application avec `oidc.groups_claim: roles`. Consultez [Configuration du fournisseur d'identité](/docs/fr/claude-apps-gateway-deploy#identity-provider-setup).
271 </Note>271 </Note>
272 </Step>272 </Step>
273 273
289 Les arguments littéraux `--secret-string` sont visibles dans la table des processus et dans les journaux d'audit/EDR pendant l'exécution de chaque commande. Sur un hôte partagé ou surveillé, mettez la valeur dans un fichier `0600` et passez `--secret-string file://<path>` à la place. Le `setup.sh` du bundle garde les valeurs secrètes hors de l'argv du processus de la même façon, en passant des fichiers temporaires `0600` à `--cli-input-json`.289 Les arguments littéraux `--secret-string` sont visibles dans la table des processus et dans les journaux d'audit/EDR pendant l'exécution de chaque commande. Sur un hôte partagé ou surveillé, mettez la valeur dans un fichier `0600` et passez `--secret-string file://<path>` à la place. Le `setup.sh` du bundle garde les valeurs secrètes hors de l'argv du processus de la même façon, en passant des fichiers temporaires `0600` à `--cli-input-json`.
290 </Note>290 </Note>
291 291
292 Contrairement aux secrets, `gateway.yaml` lui-même ne contient aucune valeur secrète, car chaque credential se résout au démarrage via l'expansion [`${VAR}` ou `${file:...}`](/docs/fr/claude-apps-gateway-config#secret-expansion). La façon dont tout atteint le conteneur diffère selon la piste :292 Contrairement aux secrets, `gateway.yaml` lui-même ne contient aucune valeur secrète, car tous les identifiants se résolvent au démarrage via l'expansion [`${VAR}` ou `${file:...}`](/docs/fr/claude-apps-gateway-config#secret-expansion). La façon dont tout atteint le conteneur diffère selon la piste :
293 293
294 * Sur ECS, l'étape de construction suivante copie `gateway.yaml` dans l'image à `/etc/claude/gateway.yaml`, et la définition de tâche injecte les trois secrets en tant que variables d'environnement via son champ `secrets`, donc le YAML référence `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` et `${GATEWAY_POSTGRES_URL}`.294 * Sur ECS, l'étape de build suivante copie `gateway.yaml` dans l'image à `/etc/claude/gateway.yaml`, et la définition de tâche injecte les trois secrets en tant que variables d'environnement via son champ `secrets`, donc le YAML référence `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` et `${GATEWAY_POSTGRES_URL}`.
295 * Sur EKS, montez `gateway.yaml` à partir d'une ConfigMap et les secrets en tant que fichiers à `/secrets`, référencés comme `${file:/secrets/...}`. Sourcez les secrets Kubernetes à partir de Secrets Manager avec External Secrets Operator ou le pilote AWS du pilote CSI Secrets Store, ou créez-les directement avec `kubectl`.295 * Sur EKS, montez `gateway.yaml` à partir d'une ConfigMap et les secrets en tant que fichiers à `/secrets`, référencés comme `${file:/secrets/...}`. Sourcez les secrets Kubernetes à partir de Secrets Manager avec External Secrets Operator ou le fournisseur AWS du pilote CSI Secrets Store, ou créez-les directement avec `kubectl`.
296 </Step>296 </Step>
297 297
298 <Step title="Construire et pousser l'image vers Amazon ECR">298 <Step title="Construire et pousser l'image vers Amazon ECR">
299 Construisez l'image selon les [exigences d'image de conteneur](/docs/fr/claude-apps-gateway-deploy#container-image), en plaçant le binaire glibc `linux-x64` à `./claude` dans le contexte de construction. Écrivez votre propre Dockerfile selon ces exigences ou commencez par le [`Dockerfile`](https://github.com/anthropics/claude-code/blob/main/examples/gateway/aws/Dockerfile) du bundle, qui copie le `gateway.yaml` rempli des étapes précédentes dans l'image à `/etc/claude/gateway.yaml`. Sur ECS, cette copie intégrée est la façon dont la configuration atteint le conteneur, c'est pourquoi la construction vient après l'écriture du fichier. La piste EKS monte plutôt `gateway.yaml` à partir d'une ConfigMap au déploiement, donc la copie intégrée n'est pas utilisée là.299 Construisez l'image selon les [exigences d'image de conteneur](/docs/fr/claude-apps-gateway-deploy#container-image), en plaçant le binaire glibc `linux-x64` à `./claude` dans le contexte de build. Écrivez votre propre Dockerfile selon ces exigences ou commencez par le [`Dockerfile`](https://github.com/anthropics/claude-code/blob/main/examples/gateway/aws/Dockerfile) du bundle, qui copie le `gateway.yaml` rempli des étapes précédentes dans l'image à `/etc/claude/gateway.yaml`. Sur ECS, cette copie intégrée est la façon dont la configuration atteint le conteneur, c'est pourquoi le build vient après l'écriture du fichier. La piste EKS monte plutôt `gateway.yaml` à partir d'une ConfigMap au déploiement, donc la copie intégrée n'est pas utilisée là.
300 300
301 L'image porte également le bundle de certificats AWS RDS comme ancre de confiance pour la chaîne de connexion `sslmode=verify-full`, donc téléchargez-le d'abord dans le contexte de construction. AWS fait tourner le bundle (les nouvelles autorités de certification régionales sont ajoutées), donc téléchargez-le par construction plutôt que d'épingler une somme de contrôle ou de le valider :301 L'image porte également le bundle de certificats AWS RDS comme ancre de confiance pour la chaîne de connexion `sslmode=verify-full`, donc téléchargez-le d'abord dans le contexte de build. AWS fait tourner le bundle (les nouvelles autorités de certification régionales sont ajoutées), donc téléchargez-le à chaque build plutôt que d'épingler une somme de contrôle ou de le valider :
302 302
303 ```bash theme={null}303 ```bash theme={null}
304 curl -fL --proto '=https' -o rds-global-bundle.pem \304 curl -fL --proto '=https' -o rds-global-bundle.pem \
305 https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem305 https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
306 ```306 ```
307 307
308 Les exigences d'image de conteneur ne couvrent pas le bundle, donc si vous écrivez votre propre Dockerfile, ajoutez les deux lignes qui le copient et le font confiance ; le Dockerfile du bundle les inclut déjà :308 Les exigences d'image de conteneur ne couvrent pas le bundle, donc si vous écrivez votre propre Dockerfile, ajoutez les deux lignes qui le copient et le font confiance ; le `Dockerfile` du bundle les inclut déjà :
309 309
310 ```dockerfile theme={null}310 ```dockerfile theme={null}
311 COPY rds-global-bundle.pem /etc/claude/rds-global-bundle.pem311 COPY rds-global-bundle.pem /etc/claude/rds-global-bundle.pem
312 ENV NODE_EXTRA_CA_CERTS=/etc/claude/rds-global-bundle.pem312 ENV NODE_EXTRA_CA_CERTS=/etc/claude/rds-global-bundle.pem
313 ```313 ```
314 314
315 Créez le référentiel ECR et connectez Docker à celui-ci. Les balises immuables signifient que la balise `<version>` que l'étape de déploiement épingle ne peut pas être ultérieurement silencieusement réorientée vers une image différente :315 Créez le dépôt ECR et connectez Docker à celui-ci. Les balises immuables signifient que la balise `<version>` que l'étape de déploiement épingle ne peut pas être ultérieurement silencieusement réorientée vers une image différente :
316 316
317 ```bash theme={null}317 ```bash theme={null}
318 aws ecr create-repository --repository-name claude-gateway \318 aws ecr create-repository --repository-name claude-gateway \
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 La période de grâce de 60 secondes donne à une tâche froide le temps de tirer l'image, de se connecter au store et de répondre à sa première vérification de santé avant qu'ECS ne commence à compter les défaillances par rapport au déploiement. La vérification de santé du groupe cible sur `GET /readyz` vérifie que le store est accessible, donc une tâche qui ne peut pas atteindre Postgres n'entre jamais en rotation. Pour garder les tâches passant la vérification lors d'une courte panne de base de données telle qu'un basculement RDS, définissez `store.readiness_grace_seconds` comme décrit dans [Comportement en cas de panne](/docs/fr/claude-apps-gateway-deploy#outage-behavior), qui couvre également l'alternative `/healthz`.428 La période de grâce de 60 secondes donne à une tâche froide le temps de tirer l'image, de se connecter au store et de répondre à sa première vérification de santé avant qu'ECS ne commence à compter les défaillances par rapport au déploiement.
429 429
430 Les tâches s'exécutent dans des sous-réseaux privés sans IP publique, donc tout le trafic sortant (vers Bedrock, votre IdP, Secrets Manager, ECR et CloudWatch Logs) passe par la passerelle NAT. Pour garder le trafic Bedrock hors du chemin public, créez un point de terminaison VPC d'interface `bedrock-runtime` et pointez l'`base_url` upstream vers celui-ci, comme indiqué dans la [référence upstream Bedrock](/docs/fr/claude-apps-gateway-config#amazon-bedrock) ; l'IdP a toujours besoin d'une sortie Internet.430 La vérification de santé du groupe cible sur `GET /readyz` vérifie que le store est accessible, donc une tâche qui ne peut pas atteindre Postgres n'entre jamais en rotation. Pour garder les tâches passant la vérification lors d'une courte panne de base de données telle qu'un basculement RDS, définissez `store.readiness_grace_seconds` comme décrit dans [Comportement en cas de panne](/docs/fr/claude-apps-gateway-deploy#outage-behavior), qui couvre également l'alternative `/healthz`.
431
432 Les tâches s'exécutent dans des sous-réseaux privés sans IP publique, donc tout le trafic sortant (vers Bedrock, votre IdP, Secrets Manager, ECR et CloudWatch Logs) passe par la passerelle NAT. Pour garder le trafic Bedrock hors du chemin public, créez un endpoint VPC d'interface `bedrock-runtime` et pointez l'`base_url` upstream vers celui-ci, comme indiqué dans la [référence upstream Bedrock](/docs/fr/claude-apps-gateway-config#amazon-bedrock) ; l'IdP a toujours besoin d'une sortie Internet.
431 433
432 Terminez en donnant aux développeurs un nom d'hôte privé résolvable : dans une zone hébergée privée Route 53, aliasez le nom DNS interne de la passerelle à l'ALB, et définissez `listen.public_url` sur ce nom d'hôte. Le nom `*.elb.amazonaws.com` propre de l'ALB se résout en adresses privées sur un ALB interne, mais il ne peut pas porter votre certificat ACM, donc utilisez votre propre nom.434 Terminez en donnant aux développeurs un nom d'hôte privé résolvable : dans une zone hébergée privée Route 53, aliasez le nom DNS interne de la passerelle à l'ALB, et définissez `listen.public_url` sur ce nom d'hôte. Le nom `*.elb.amazonaws.com` propre de l'ALB se résout en adresses privées sur un ALB interne, mais il ne peut pas porter votre certificat ACM, donc utilisez votre propre nom.
433 435
435 </Tab>437 </Tab>
436 438
437 <Tab title="EKS">439 <Tab title="EKS">
438 Cette piste a besoin de `kubectl` et `eksctl` installés localement, et d'un cluster EKS existant avec un fournisseur OIDC IAM et le contrôleur AWS Load Balancer installé. Le cluster doit être sur `$VPC_ID` pour que les pods puissent atteindre le point de terminaison privé RDS, et le groupe de sécurité `claude-gateway-db` doit admettre le groupe de sécurité du pod ou du nœud du cluster à la place de `$GW_SG`.440 Cette piste a besoin de `kubectl` et `eksctl` installés localement, et d'un cluster EKS existant avec un fournisseur OIDC IAM et le contrôleur AWS Load Balancer installé. Le cluster doit être sur `$VPC_ID` pour que les pods puissent atteindre l'endpoint privé RDS, et le groupe de sécurité `claude-gateway-db` doit admettre le groupe de sécurité du pod ou du nœud du cluster à la place de `$GW_SG`.
439 441
440 Sur EKS, la passerelle obtient ses credentials Bedrock via IRSA plutôt que les rôles ECS. La politique de confiance `ecs-tasks.amazonaws.com` de l'étape IAM ne s'applique pas ici ; IRSA a besoin d'un rôle dont la politique de confiance fédère sur le fournisseur OIDC du cluster, limité à `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` crée ce rôle, attache les politiques et annote le compte de service Kubernetes avec l'ARN du rôle en une seule étape. Transformez les deux documents de politique de l'étape IAM en politiques gérées qu'il peut attacher :442 Sur EKS, la passerelle obtient ses identifiants Bedrock via IRSA plutôt que les rôles ECS. La politique de confiance `ecs-tasks.amazonaws.com` de l'étape IAM ne s'applique pas ici ; IRSA a besoin d'un rôle dont la politique de confiance fédère sur le fournisseur OIDC du cluster, limité à `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` crée ce rôle, attache les politiques et annote le compte de service Kubernetes avec l'ARN du rôle en une seule étape. Transformez les deux documents de politique de l'étape IAM en politiques gérées qu'il peut attacher :
441 443
442 ```bash theme={null}444 ```bash theme={null}
443 BEDROCK_POLICY_ARN="$(aws iam create-policy --policy-name claude-gateway-bedrock-invoke \445 BEDROCK_POLICY_ARN="$(aws iam create-policy --policy-name claude-gateway-bedrock-invoke \
453 --approve455 --approve
454 ```456 ```
455 457
456 La politique des secrets n'est nécessaire que lorsque les pods lisent eux-mêmes Secrets Manager, comme le fait le pilote AWS du pilote CSI Secrets Store en utilisant le compte de service du pod de montage ; supprimez-la si vous créez les secrets Kubernetes d'une autre façon. Le fournisseur a besoin des deux actions de la politique : il appelle `DescribeSecret` lorsqu'il réconcilie les secrets rotatés, donc une subvention `GetSecretValue`-uniquement monte au premier déploiement mais arrête de récupérer les rotations.458 La politique des secrets n'est nécessaire que lorsque les pods lisent eux-mêmes Secrets Manager, comme le fait le fournisseur AWS du pilote CSI Secrets Store en utilisant le compte de service du pod de montage ; supprimez-la si vous créez les secrets Kubernetes d'une autre façon. Le fournisseur a besoin des deux actions de la politique : il appelle `DescribeSecret` lorsqu'il réconcilie les secrets ayant fait l'objet d'une rotation, donc une autorisation limitée à `GetSecretValue` permet le montage au premier déploiement mais cesse de récupérer les rotations.
457 459
458 Déployez la passerelle en tant que Deployment standard plus un Service et un Ingress, comme décrit dans [Déploiement Kubernetes](/docs/fr/claude-apps-gateway-deploy#kubernetes), avec :460 Déployez la passerelle en tant que Deployment standard plus un Service et un Ingress, comme décrit dans [Déploiement Kubernetes](/docs/fr/claude-apps-gateway-deploy#kubernetes), avec :
459 461
476 </Step>478 </Step>
477 479
478 <Step title="Pousser l'URL de la passerelle vers les machines des développeurs">480 <Step title="Pousser l'URL de la passerelle vers les machines des développeurs">
479 La passerelle s'exécute maintenant, mais les développeurs ne peuvent pas la atteindre à partir de `/login` jusqu'à ce que l'URL de la passerelle soit sur leurs machines. Définissez `forceLoginMethod` et `forceLoginGatewayUrl` dans le [fichier de paramètres gérés](/docs/fr/claude-apps-gateway#set-the-gateway-url) que vous déployez sur chaque appareil via MDM. Il n'y a pas d'option de passerelle dans le sélecteur de connexion pour qu'un développeur sélectionne manuellement.481 La passerelle s'exécute maintenant, mais les développeurs ne peuvent pas l'atteindre à partir de `/login` tant que l'URL de la passerelle n'est pas sur leurs machines. Définissez `forceLoginMethod` et `forceLoginGatewayUrl` dans le [fichier de paramètres gérés](/docs/fr/claude-apps-gateway#set-the-gateway-url) que vous déployez sur chaque appareil via MDM. Il n'y a pas d'option de passerelle dans le sélecteur de connexion pour qu'un développeur sélectionne manuellement.
480 </Step>482 </Step>
481</Steps>483</Steps>
482 484
