70```70```

71 71 

72<h2 id="deploy-the-gateway">72<h2 id="deploy-the-gateway">

73 Distribuire il gateway73 Eseguire il deploy del gateway

74</h2>74</h2>

75 75 

76I passaggi seguenti eseguono il provisioning della distribuzione completa con comandi `aws`.76I passaggi seguenti eseguono il provisioning del deploy completo con comandi `aws`.

77 77 

78<Steps>78<Steps>

79 <Step title="Creare i gruppi di sicurezza">79 <Step title="Creare i gruppi di sicurezza">

80 Tre gruppi di sicurezza concatenano il percorso del traffico: la vostra rete aziendale raggiunge il load balancer sulla porta 443, il load balancer raggiunge il gateway sulla porta 8080 e il gateway raggiunge Postgres sulla porta 5432. Nient'altro è raggiungibile. Come li collegate dipende dal percorso di calcolo:80 Tre gruppi di sicurezza concatenano il percorso del traffico: la tua rete aziendale raggiunge il load balancer sulla porta 443, il load balancer raggiunge il gateway sulla porta 8080 e il gateway raggiunge Postgres sulla porta 5432. Nient'altro è raggiungibile. Il modo in cui li colleghi dipende dal percorso di calcolo:

81 81 

82 * Su ECS Fargate, il passaggio di distribuzione allega `$ALB_SG` al load balancer e `$GW_SG` al servizio.82 * Su ECS Fargate, il passaggio di deploy collega `$ALB_SG` al load balancer e `$GW_SG` al servizio.

83 * Su EKS, AWS Load Balancer Controller crea il proprio gruppo di sicurezza frontend per l'ALB, quindi `$ALB_SG` e `$GW_SG` non vengono utilizzati: l'annotazione `inbound-cidrs` del passaggio di distribuzione limita il listener alla vostra rete aziendale e il gruppo di sicurezza del database ammette il gruppo di sicurezza del cluster al posto di `$GW_SG`.83 * Su EKS, AWS Load Balancer Controller crea il proprio gruppo di sicurezza frontend per l'ALB, quindi `$ALB_SG` e `$GW_SG` non vengono utilizzati: l'annotazione `inbound-cidrs` del passaggio di deploy limita il listener alla tua rete aziendale e il gruppo di sicurezza del database ammette invece il gruppo di sicurezza del cluster.

84 84 

85 ```bash theme={null}85 ```bash theme={null}

86 ALB_SG="$(aws ec2 create-security-group --group-name claude-gateway-alb \86 ALB_SG="$(aws ec2 create-security-group --group-name claude-gateway-alb \

103 </Step>103 </Step>

104 104 

105 <Step title="Creare i ruoli IAM e inviare il modulo del caso d'uso">105 <Step title="Creare i ruoli IAM e inviare il modulo del caso d'uso">

106 Il gateway viene eseguito con un ruolo di attività dedicato la cui unica autorizzazione è invocare i modelli Claude su Bedrock. Secondo il [riferimento upstream Bedrock](/docs/it/claude-apps-gateway-config#amazon-bedrock), la politica deve coprire sia gli ARN del profilo di inferenza cross-region che gli ARN del modello di base sottostante:106 Il gateway viene eseguito con un ruolo di attività dedicato il cui unico permesso è invocare i modelli Claude su Bedrock. Secondo il [riferimento upstream Bedrock](/docs/it/claude-apps-gateway-config#amazon-bedrock), la policy deve coprire sia gli ARN dei profili di inferenza cross-region sia gli ARN dei modelli di base sottostanti:

107 107 

108 ```bash theme={null}108 ```bash theme={null}

109 cat > bedrock-invoke.json <<EOF109 cat > bedrock-invoke.json <<EOF

136 --policy-name bedrock-invoke --policy-document file://bedrock-invoke.json136 --policy-name bedrock-invoke --policy-document file://bedrock-invoke.json

137 ```137 ```

138 138 

139 ECS ha anche bisogno di un ruolo di esecuzione, che l'agente ECS stesso utilizza per estrarre l'immagine da ECR e iniettare i valori di Secrets Manager creati in seguito. È separato dal ruolo di attività che l'AWS SDK del gateway utilizza in fase di esecuzione:139 ECS ha anche bisogno di un ruolo di esecuzione, che l'agente ECS stesso utilizza per scaricare l'immagine da ECR e iniettare i valori di Secrets Manager creati in seguito. È separato dal ruolo di attività che l'AWS SDK del gateway utilizza in fase di esecuzione:

140 140 

141 ```bash theme={null}141 ```bash theme={null}

142 aws iam create-role --role-name claude-gateway-execution \142 aws iam create-role --role-name claude-gateway-execution \

161 --policy-name read-gateway-secrets --policy-document file://secrets-read.json161 --policy-name read-gateway-secrets --policy-document file://secrets-read.json

162 ```162 ```

163 163 

164 I nomi della politica specificano un ARN per segreto piuttosto che un wildcard semplice `gateway-*`, che in un account condiviso corrisponderebbe anche a segreti non correlati; il suffisso finale `-??????` corrisponde esattamente al suffisso di sei caratteri casuale che Secrets Manager aggiunge all'ARN di ogni segreto. Un `-*` finale sarebbe un glob di prefisso semplice e corrisponderebbe anche a nomi più lunghi come `gateway-postgres-url-prod`.164 La policy specifica un ARN per ogni segreto anziché un semplice wildcard `gateway-*`, che in un account condiviso corrisponderebbe anche a segreti non correlati; il suffisso finale `-??????` corrisponde esattamente al suffisso casuale di sei caratteri che Secrets Manager aggiunge all'ARN di ogni segreto. Un `-*` finale sarebbe un semplice glob di prefisso e corrisponderebbe anche a nomi più lunghi come `gateway-postgres-url-prod`.

165 165 

166 La politica IAM concede al gateway il permesso di chiamare Bedrock, e Bedrock abilita l'accesso al modello per impostazione predefinita nelle regioni commerciali. Il gate rimanente a livello di account è il modulo del caso d'uso una tantum di Anthropic: se nessuno nel vostro account lo ha inviato, aprite la [console Amazon Bedrock](https://console.aws.amazon.com/bedrock/), selezionate un modello Anthropic dal catalogo dei modelli e completate il modulo. L'accesso viene concesso immediatamente dopo l'invio; consultate [Claude Code su Amazon Bedrock](/docs/it/amazon-bedrock#1-submit-use-case-details) per il modulo AWS Organizations e i permessi IAM di cui il mittente ha bisogno.166 La policy IAM concede al gateway il permesso di chiamare Bedrock, e Bedrock abilita l'accesso ai modelli per impostazione predefinita nelle regioni commerciali. Il vincolo rimanente a livello di account è il modulo del caso d'uso una tantum di Anthropic: se nessuno nel tuo account lo ha inviato, apri la [console Amazon Bedrock](https://console.aws.amazon.com/bedrock/), seleziona un modello Anthropic dal catalogo dei modelli e compila il modulo. L'accesso viene concesso immediatamente dopo l'invio; consulta [Claude Code su Amazon Bedrock](/docs/it/amazon-bedrock#1-submit-use-case-details) per il modulo AWS Organizations e i permessi IAM di cui ha bisogno chi lo invia.

167 167 

168 Il percorso EKS riutilizza entrambi i documenti della politica su un ruolo IRSA al posto dei due ruoli ECS; consultate il passaggio di distribuzione.168 Il percorso EKS riutilizza entrambi i documenti di policy su un ruolo IRSA al posto dei due ruoli ECS; consulta il passaggio di deploy.

169 </Step>169 </Step>

170 170 

171 <Step title="Eseguire il provisioning di Amazon RDS per PostgreSQL">171 <Step title="Eseguire il provisioning di Amazon RDS per PostgreSQL">

172 L'istanza viene eseguita nelle subnet private senza indirizzo pubblico e con crittografia dell'archiviazione attivata. La versione del motore è fissata a Postgres 16, che soddisfa il limite supportato del gateway di PostgreSQL 14 e garantisce che la famiglia del gruppo di parametri sottostante corrisponda all'istanza.172 L'istanza esegue Postgres 16 nelle subnet private, senza indirizzo pubblico e con la crittografia dell'archiviazione attivata.

173 173 

174 Per prima cosa, create il gruppo di subnet che posiziona il database nelle subnet private e un gruppo di parametri con `rds.force_ssl=1` in modo che il server rifiuti le connessioni in testo semplice. La versione del motore è fissata una volta perché la famiglia del gruppo di parametri deve corrispondere alla versione principale del motore che l'istanza esegue:174 Per prima cosa, crea il gruppo di subnet che colloca il database nelle subnet private e un gruppo di parametri con `rds.force_ssl=1` in modo che il server rifiuti le connessioni in testo semplice. La versione del motore viene fissata una sola volta perché la famiglia del gruppo di parametri deve corrispondere alla versione principale del motore eseguita dall'istanza:

175 175 

176 ```bash theme={null}176 ```bash theme={null}

177 aws rds create-db-subnet-group --db-subnet-group-name claude-gateway-db \177 aws rds create-db-subnet-group --db-subnet-group-name claude-gateway-db \

186 --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=immediate"186 --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=immediate"

187 ```187 ```

188 188 

189 Quindi create l'istanza con una password principale generata:189 Quindi crea l'istanza con una password principale generata:

190 190 

191 ```bash theme={null}191 ```bash theme={null}

192 PGPASS="$(openssl rand -hex 24)"192 PGPASS="$(openssl rand -hex 24)"

201 --no-publicly-accessible --storage-encrypted201 --no-publicly-accessible --storage-encrypted

202 ```202 ```

203 203 

204 L'argomento letterale `--master-user-password` è visibile nella tabella dei processi e nei log di audit/EDR mentre il comando viene eseguito, la stessa esposizione che la nota del passaggio dei segreti copre. Su un host condiviso o monitorato, passate la password tramite `--cli-input-json` da un file `0600` al posto, il modo in cui `setup.sh` del bundle lo fa.204 L'argomento letterale `--master-user-password` è visibile nella tabella dei processi e nei log di audit/EDR mentre il comando è in esecuzione, la stessa esposizione trattata nella nota del passaggio dei segreti. Su un host condiviso o monitorato, passa invece la password tramite `--cli-input-json` da un file `0600`, come fa il `setup.sh` del bundle.

205 205 

206 Attendete che l'istanza si avvii, il che può richiedere diversi minuti, quindi leggete il suo endpoint privato e assemblate la stringa di connessione che il gateway utilizzerà:206 Attendi che l'istanza sia disponibile, il che può richiedere diversi minuti, quindi leggi il suo endpoint privato e componi la stringa di connessione che il gateway utilizzerà:

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` fa sì che il gateway verifichi la catena del certificato del server RDS e il nome host, non solo crittografare. L'ancora di fiducia è il [bundle di certificati AWS RDS](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem), che il passaggio di compilazione dell'immagine sottostante copia in `/etc/claude/rds-global-bundle.pem` e affida tramite `NODE_EXTRA_CA_CERTS`. Non aggiungete un parametro `sslrootcert=` in stile libpq all'URL: il driver del gateway legge solo `sslmode` dalla stringa di query e inoltrerebbe `sslrootcert` a Postgres come parametro di avvio, che il server rifiuta.215 `sslmode=verify-full` fa sì che il gateway verifichi la catena e il nome host del certificato del server RDS, e non si limiti a crittografare. L'ancora di fiducia è il [bundle di certificati AWS RDS](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem), che il passaggio di build dell'immagine più avanti copia in `/etc/claude/rds-global-bundle.pem` e considera attendibile tramite `NODE_EXTRA_CA_CERTS`. Non aggiungere all'URL un parametro `sslrootcert=` in stile libpq: il driver del gateway legge solo `sslmode` dalla stringa di query e inoltrerebbe `sslrootcert` a Postgres come parametro di avvio, che il server rifiuta.

216 216 

217 Il servizio ECS o i pod EKS devono essere eseguiti in questo VPC in modo che possano raggiungere l'endpoint privato dell'istanza, e il gruppo di sicurezza `claude-gateway-db` ammette solo il gruppo di sicurezza del gateway.217 Il servizio ECS o i pod EKS devono essere eseguiti in questo VPC per poter raggiungere l'endpoint privato dell'istanza, e il gruppo di sicurezza `claude-gateway-db` ammette solo il gruppo di sicurezza del gateway.

218 </Step>218 </Step>

219 219 

220 <Step title="Scrivere gateway.yaml">220 <Step title="Scrivere gateway.yaml">

221 Il blocco `upstreams` punta a Bedrock con `auth: {}`, quindi il gateway si autentica tramite la catena di credenziali predefinita di AWS dal ruolo di attività su ECS o dal ruolo IRSA su EKS. Consultate il [riferimento di configurazione](/docs/it/claude-apps-gateway-config) per ogni campo.221 Il blocco `upstreams` punta a Bedrock con `auth: {}`, quindi il gateway si autentica tramite la catena di credenziali predefinita di AWS, dal ruolo di attività su ECS o dal ruolo IRSA su EKS. Consulta il [riferimento di configurazione](/docs/it/claude-apps-gateway-config) per ogni campo.

222 222 

223 Due campi `listen` descrivono cosa sta davanti al gateway:223 Due campi `listen` descrivono ciò che sta davanti al gateway:

224 224 

225 * `public_url`: l'origine esterna `https://`, obbligatoria per qualsiasi bind non-loopback; consultate il [riferimento `listen`](/docs/it/claude-apps-gateway-config#listen). Il gateway costruisce l'`redirect_uri` dell'IdP e il suo documento di scoperta solo da questo valore, mai da intestazioni `X-Forwarded-*`.225 * `public_url`: l'origine esterna `https://`, obbligatoria per qualsiasi bind non di loopback; consulta il [riferimento `listen`](/docs/it/claude-apps-gateway-config#listen). Il gateway costruisce il `redirect_uri` dell'IdP e il proprio documento di discovery solo da questo valore, mai dalle intestazioni `X-Forwarded-*`.

226 * `trusted_proxies`: gli intervalli di origine del front end. Il gateway onora `X-Forwarded-For` solo quando il peer TCP è in questo elenco, quindi cammina nella catena oltre i hop affidabili, in modo che i limiti di velocità di accesso per IP e gli eventi di audit registrino gli IP degli sviluppatori al posto di quello del load balancer.226 * `trusted_proxies`: gli intervalli di origine del front end. Il gateway considera `X-Forwarded-For` solo quando il peer TCP è in questo elenco, quindi percorre la catena oltre gli hop attendibili, in modo che i rate limit di accesso per IP e gli eventi di audit registrino gli IP degli sviluppatori anziché quelli del load balancer.

227 227 

228 Su entrambi i percorsi il front end è un ALB interno, creato direttamente o da AWS Load Balancer Controller, e i nodi di un ALB prendono indirizzi dalle subnet a cui è collegato, quindi impostate `trusted_proxies` ai CIDR di quelle subnet. Questo affida ogni host in quelle subnet come proxy. Evitate che l'origine di ingresso dell'ALB, il vostro CIDR aziendale, si sovrapponga ad essi, e non condividete le subnet con carichi di lavoro non affidabili che potrebbero falsificare gli IP dei client tramite `X-Forwarded-For`.228 Su entrambi i percorsi il front end è un ALB interno, creato direttamente o da AWS Load Balancer Controller, e i nodi di un ALB prendono gli indirizzi dalle subnet a cui è collegato, quindi imposta `trusted_proxies` sui CIDR di quelle subnet. In questo modo ogni host in quelle subnet viene considerato un proxy attendibile. Evita che l'origine di ingresso dell'ALB, il tuo CIDR aziendale, si sovrapponga a esse, e non condividere le subnet con carichi di lavoro non attendibili che potrebbero falsificare gli IP dei client tramite `X-Forwarded-For`.

229 229 

230 L'attributo di conservazione del client port dell'ALB, `routing.http.xff_client_port.enabled`, può rimanere a entrambe le impostazioni: con esso attivato, l'ALB scrive il client come `203.0.113.7:54321` o `[2001:db8::1]:54321`, e il gateway legge entrambi con la porta eliminata.230 L'attributo di conservazione della porta del client dell'ALB, `routing.http.xff_client_port.enabled`, può restare su entrambe le impostazioni: se è attivo, l'ALB scrive il client come `203.0.113.7:54321` o `[2001:db8::1]:54321`, e il gateway legge entrambi i formati scartando la porta.

231 231 

232 ```yaml gateway.yaml theme={null}232 ```yaml gateway.yaml theme={null}

233 listen:233 listen:

241 client_id: 0oa1example2241 client_id: 0oa1example2

242 client_secret: ${OIDC_CLIENT_SECRET} # EKS: ${file:/secrets/oidc-client-secret}242 client_secret: ${OIDC_CLIENT_SECRET} # EKS: ${file:/secrets/oidc-client-secret}

243 allowed_email_domains: [example.com]243 allowed_email_domains: [example.com]

244 # Il server di autorizzazione dell'organizzazione Okta restituisce un id_token sottile che omette244 # Il server di autorizzazione dell'organizzazione Okta restituisce un id_token ridotto che omette

245 # email e gruppi; il gateway li riempie da /userinfo.245 # email e gruppi; il gateway li ricava da /userinfo.

246 userinfo_fallback: true246 userinfo_fallback: true

247 # Okta emette gruppi solo quando viene richiesto lo scope `groups` e il247 # Okta emette i gruppi solo quando viene richiesto lo scope `groups` e il

248 # filtro della rivendicazione dei gruppi dell'app lo consente.248 # filtro del claim dei gruppi dell'app li consente.

249 scopes: [openid, profile, email, offline_access, groups]249 scopes: [openid, profile, email, offline_access, groups]

250 250 

251 session:251 session:

252 jwt_secret: ${GATEWAY_JWT_SECRET} # EKS: ${file:/secrets/jwt-secret}252 jwt_secret: ${GATEWAY_JWT_SECRET} # EKS: ${file:/secrets/jwt-secret}

253 ttl_hours: 8 # limita la latenza di deprovisioning; abbassate253 ttl_hours: 8 # limita la latenza di deprovisioning; abbassa

254 # verso 1 per una revoca più stretta254 # verso 1 per una revoca più rapida

255 255 

256 store:256 store:

257 postgres_url: ${GATEWAY_POSTGRES_URL} # EKS: ${file:/secrets/postgres-url}257 postgres_url: ${GATEWAY_POSTGRES_URL} # EKS: ${file:/secrets/postgres-url}

258 # readiness_grace_seconds: 300 # mantieni il passaggio del controllo di stato258 # readiness_grace_seconds: 300 # continua a superare il controllo di stato

259 # attraverso un failover RDS259 # durante un failover RDS

260 260 

261 upstreams:261 upstreams:

262 - provider: bedrock262 - provider: bedrock

263 region: <your-region> # corrispondere a $AWS_REGION in modo che gli ARN della politica IAM263 region: <your-region> # uguale a $AWS_REGION affinché gli ARN della

264 # lo coprano264 # policy IAM la coprano

265 auth: {} # catena di credenziali predefinita di AWS:265 auth: {} # catena di credenziali predefinita di AWS:

266 # ruolo di attività ECS, o IRSA su EKS266 # ruolo di attività ECS, o IRSA su EKS

267 ```267 ```

268 268 

269 <Note>269 <Note>

270 Solo il blocco `oidc` è specifico di Okta. Per utilizzare Microsoft Entra ID al posto, impostate `issuer` su `https://login.microsoftonline.com/<tenant-id>/v2.0`, eliminate `userinfo_fallback` e lo scope `groups`, e notate che Entra emette Object ID dei gruppi piuttosto che nomi, quindi [`managed.policies`](/docs/it/claude-apps-gateway-config#managed) deve corrispondere ai GUID, o su App Roles con `oidc.groups_claim: roles`. Consultate [Configurazione del provider di identità](/docs/it/claude-apps-gateway-deploy#identity-provider-setup).270 Solo il blocco `oidc` è specifico di Okta. Per utilizzare invece Microsoft Entra ID, imposta `issuer` su `https://login.microsoftonline.com/<tenant-id>/v2.0`, rimuovi `userinfo_fallback` e lo scope `groups`, e tieni presente che Entra emette gli Object ID dei gruppi anziché i nomi, quindi [`managed.policies`](/docs/it/claude-apps-gateway-config#managed) deve corrispondere ai GUID, oppure agli App Roles con `oidc.groups_claim: roles`. Consulta [Configurazione del provider di identità](/docs/it/claude-apps-gateway-deploy#identity-provider-setup).

271 </Note>271 </Note>

272 </Step>272 </Step>

273 273 

274 <Step title="Archiviare i segreti in AWS Secrets Manager">274 <Step title="Archiviare i segreti in AWS Secrets Manager">

275 Create tre segreti; il ruolo di esecuzione dal passaggio IAM può già leggerli:275 Crea tre segreti; il ruolo di esecuzione del passaggio IAM può già leggerli:

276 276 

277 ```bash theme={null}277 ```bash theme={null}

278 aws secretsmanager create-secret --name gateway-jwt-secret \278 aws secretsmanager create-secret --name gateway-jwt-secret \

283 --secret-string "$GATEWAY_POSTGRES_URL"283 --secret-string "$GATEWAY_POSTGRES_URL"

284 ```284 ```

285 285 

286 Notate l'ARN che ogni chiamata stampa; la definizione di attività ECS fa riferimento ai segreti per ARN.286 Annota l'ARN stampato da ogni chiamata; la definizione di attività ECS fa riferimento ai segreti tramite ARN.

287 287 

288 <Note>288 <Note>

289 Gli argomenti letterali `--secret-string` sono visibili nella tabella dei processi e nei log di audit/EDR mentre ogni comando viene eseguito. Su un host condiviso o monitorato, mettete il valore in un file `0600` e passate `--secret-string file://<path>` al posto. `setup.sh` del bundle mantiene i valori dei segreti fuori da argv del processo allo stesso modo, passando file temporanei `0600` a `--cli-input-json`.289 Gli argomenti letterali `--secret-string` sono visibili nella tabella dei processi e nei log di audit/EDR mentre ogni comando è in esecuzione. Su un host condiviso o monitorato, inserisci invece il valore in un file `0600` e passa `--secret-string file://<path>`. Il `setup.sh` del bundle tiene allo stesso modo i valori dei segreti fuori dagli argv dei processi, passando file temporanei `0600` a `--cli-input-json`.

290 </Note>290 </Note>

291 291 

292 A differenza dei segreti, `gateway.yaml` stesso non contiene valori segreti, perché ogni credenziale si risolve all'avvio tramite l'espansione [`${VAR}` o `${file:...}`](/docs/it/claude-apps-gateway-config#secret-expansion). Come tutto raggiunge il contenitore differisce per percorso:292 A differenza dei segreti, `gateway.yaml` non contiene valori segreti, perché ogni credenziale viene risolta all'avvio tramite l'[espansione `${VAR}` o `${file:...}`](/docs/it/claude-apps-gateway-config#secret-expansion). Il modo in cui tutto arriva al container varia in base al percorso:

293 293 

294 * Su ECS, il passaggio di compilazione successivo copia `gateway.yaml` nell'immagine a `/etc/claude/gateway.yaml`, e la definizione di attività inietta i tre segreti come variabili di ambiente tramite il suo campo `secrets`, quindi lo YAML fa riferimento a `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` e `${GATEWAY_POSTGRES_URL}`.294 * Su ECS, la build del passaggio successivo copia `gateway.yaml` nell'immagine in `/etc/claude/gateway.yaml`, e la definizione di attività inietta i tre segreti come variabili d'ambiente tramite il suo campo `secrets`, quindi lo YAML fa riferimento a `${GATEWAY_JWT_SECRET}`, `${OIDC_CLIENT_SECRET}` e `${GATEWAY_POSTGRES_URL}`.

295 * Su EKS, montate `gateway.yaml` da una ConfigMap e i segreti come file a `/secrets`, referenziati come `${file:/secrets/...}`. Originare i Kubernetes Secrets da Secrets Manager con External Secrets Operator o il provider AWS del driver CSI Secrets Store, o crearli direttamente con `kubectl`.295 * Su EKS, monta `gateway.yaml` da una ConfigMap e i segreti come file in `/secrets`, referenziati come `${file:/secrets/...}`. Ricava i Kubernetes Secrets da Secrets Manager con External Secrets Operator o con il provider AWS del driver CSI Secrets Store, oppure creali direttamente con `kubectl`.

296 </Step>296 </Step>

297 297 

298 <Step title="Compilare e spingere l'immagine ad Amazon ECR">298 <Step title="Eseguire la build e il push dell'immagine su Amazon ECR">

299 Compilate l'immagine secondo i [requisiti dell'immagine del contenitore](/docs/it/claude-apps-gateway-deploy#container-image), posizionando il binario glibc `linux-x64` a `./claude` nel contesto di compilazione. Scrivete il vostro Dockerfile secondo questi requisiti o iniziate dal [`Dockerfile`](https://github.com/anthropics/claude-code/blob/main/examples/gateway/aws/Dockerfile) del bundle, che copia il `gateway.yaml` compilato dai passaggi precedenti nell'immagine a `/etc/claude/gateway.yaml`. Su ECS quella copia incorporata è come la configurazione raggiunge il contenitore, motivo per cui la compilazione viene dopo che il file è stato scritto. Il percorso EKS al posto monta `gateway.yaml` da una ConfigMap al momento della distribuzione, quindi la copia incorporata non viene utilizzata lì.299 Esegui la build dell'immagine secondo i [requisiti dell'immagine del container](/docs/it/claude-apps-gateway-deploy#container-image), posizionando il binario glibc `linux-x64` in `./claude` nel contesto di build. Scrivi il tuo Dockerfile secondo questi requisiti oppure parti dal [`Dockerfile`](https://github.com/anthropics/claude-code/blob/main/examples/gateway/aws/Dockerfile) del bundle, che copia il `gateway.yaml` compilato nei passaggi precedenti nell'immagine in `/etc/claude/gateway.yaml`. Su ECS è questa copia incorporata a portare la configurazione nel container, ed è per questo che la build viene dopo la scrittura del file. Il percorso EKS monta invece `gateway.yaml` da una ConfigMap al momento del deploy, quindi lì la copia incorporata non viene utilizzata.

300 300 

301 L'immagine porta anche il bundle di certificati AWS RDS come ancora di fiducia per la stringa di connessione `sslmode=verify-full`, quindi scaricatelo nel contesto di compilazione per primo. AWS ruota il bundle (nuove CA regionali vengono aggiunte), quindi scaricatelo per compilazione piuttosto che fissare un checksum o impegnarlo:301 L'immagine contiene anche il bundle di certificati AWS RDS come ancora di fiducia per il `sslmode=verify-full` della stringa di connessione, quindi scaricalo prima nel contesto di build. AWS aggiorna periodicamente il bundle (vengono aggiunte nuove CA regionali), quindi scaricalo a ogni build anziché fissarne un checksum o eseguirne il commit:

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 I requisiti dell'immagine del contenitore non coprono il bundle, quindi se scrivete il vostro Dockerfile, aggiungete le due righe che lo copiano e lo affidano; il `Dockerfile` del bundle include già entrambi:308 I requisiti dell'immagine del container non coprono il bundle, quindi se scrivi il tuo Dockerfile, aggiungi le due righe che lo copiano e lo rendono attendibile; il `Dockerfile` del bundle le include già entrambe:

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 Create il repository ECR e accedete Docker ad esso. I tag immutabili significano che il tag `<version>` che il passaggio di distribuzione fissa non può essere successivamente reindirizzato silenziosamente a un'immagine diversa:315 Crea il repository ECR ed esegui l'accesso di Docker a esso. I tag immutabili fanno sì che il tag `<version>` fissato nel passaggio di deploy non possa essere in seguito reindirizzato silenziosamente a un'immagine diversa:

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 \

323 "${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"323 "${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"

324 ```324 ```

325 325 

326 Compilate e spingete l'immagine. La definizione di attività sottostante esegue `linux/amd64`, quindi la piattaforma deve corrispondere qui; per Fargate su ARM64 (Graviton), compilate `linux/arm64` con il binario `linux-arm64` e impostate `cpuArchitecture` su `ARM64` al posto:326 Esegui la build e il push dell'immagine. La definizione di attività più avanti esegue `linux/amd64`, quindi la piattaforma deve corrispondere qui; per Fargate su ARM64 (Graviton), esegui invece la build per `linux/arm64` con il binario `linux-arm64` e imposta `cpuArchitecture` su `ARM64`:

327 327 

328 ```bash theme={null}328 ```bash theme={null}

329 docker build --platform=linux/amd64 \329 docker build --platform=linux/amd64 \

332 ```332 ```

333 </Step>333 </Step>

334 334 

335 <Step title="Distribuire">335 <Step title="Eseguire il deploy">

336 <Tabs>336 <Tabs>

337 <Tab title="ECS Fargate">337 <Tab title="ECS Fargate">

338 Create il cluster e un gruppo di log per stderr del gateway, che porta sia i suoi eventi di audit che i log operazionali. La conservazione è una chiamata separata, e senza una CloudWatch mantiene i log per sempre; allineate i 90 giorni con la vostra politica di conservazione dell'audit:338 Crea il cluster e un gruppo di log per lo stderr del gateway, che contiene sia gli eventi di audit sia i log operativi. La conservazione richiede una chiamata separata, e senza di essa CloudWatch conserva i log per sempre; allinea i 90 giorni alla tua policy di conservazione dell'audit:

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

344 --retention-in-days 90344 --retention-in-days 90

345 ```345 ```

346 346 

347 Scrivete la definizione di attività. Il ruolo di attività porta il permesso Bedrock e il ruolo di esecuzione inietta i segreti; utilizzate gli ARN dei segreti dal passaggio Secrets Manager:347 Scrivi la definizione di attività. Il ruolo di attività ha il permesso per Bedrock e il ruolo di esecuzione inietta i segreti; usa gli ARN dei segreti del passaggio Secrets Manager:

348 348 

349 ```json claude-gateway-task.json theme={null}349 ```json claude-gateway-task.json theme={null}

350 {350 {

379 }379 }

380 ```380 ```

381 381 

382 Registratela:382 Registrala:

383 383 

384 ```bash theme={null}384 ```bash theme={null}

385 aws ecs register-task-definition --cli-input-json file://claude-gateway-task.json385 aws ecs register-task-definition --cli-input-json file://claude-gateway-task.json

386 ```386 ```

387 387 

388 Mettete un ALB interno davanti con un gruppo di destinazione che verifica lo stato del gateway. `--ip-address-type ipv4` è importante: un ALB interno dual-stack pubblica record AAAA di intervallo pubblico, che il controllo della rete privata `/login` rifiuta:388 Metti davanti un ALB interno con un gruppo di destinazione che verifica lo stato del gateway. `--ip-address-type ipv4` è importante: un ALB interno dual-stack pubblica record AAAA di intervallo pubblico, che il controllo della rete privata di `/login` rifiuta:

389 389 

390 ```bash theme={null}390 ```bash theme={null}

391 ALB_ARN="$(aws elbv2 create-load-balancer --name claude-gateway \391 ALB_ARN="$(aws elbv2 create-load-balancer --name claude-gateway \

399 --query 'TargetGroups[0].TargetGroupArn' --output text)"399 --query 'TargetGroups[0].TargetGroupArn' --output text)"

400 ```400 ```

401 401 

402 Aggiungete il listener HTTPS. `--ssl-policy` fissa un limite TLS moderno, poiché ometterlo ricade nella politica predefinita legacy `ELBSecurityPolicy-2016-08`, che ancora accetta TLS 1.0/1.1.402 Aggiungi il listener HTTPS. `--ssl-policy` fissa un livello minimo di TLS moderno, poiché ometterlo fa ricadere sulla policy predefinita legacy `ELBSecurityPolicy-2016-08`, che accetta ancora TLS 1.0/1.1.

403 403 

404 L'ALB chiude una connessione dopo 60 secondi senza dati per impostazione predefinita. I ping di keepalive del gateway mantengono i flussi entro quel default, quindi aumentare il timeout aggiunge margine sopra la cadenza del ping; la riga [Troubleshooting](#troubleshooting) sui flussi interrotti copre il meccanismo e i gateway più vecchi. I comandi sottostanti aggiungono il listener e aumentano il timeout:404 Per impostazione predefinita, l'ALB chiude una connessione dopo 60 secondi senza dati. I ping di keepalive del gateway mantengono i flussi entro questo valore predefinito, quindi aumentare il timeout aggiunge margine rispetto alla cadenza dei ping; la riga di [Risoluzione dei problemi](#troubleshooting) sui flussi interrotti descrive il meccanismo e i gateway meno recenti. I comandi seguenti aggiungono il listener e aumentano il 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" \

414 --attributes Key=idle_timeout.timeout_seconds,Value=3600414 --attributes Key=idle_timeout.timeout_seconds,Value=3600

415 ```415 ```

416 416 

417 Create il servizio. Il circuito di distribuzione del deployment fa rotolare una distribuzione le cui attività continuano a fallire, da un'immagine cattiva o una configurazione non avviabile, indietro allo stato stabile precedente al posto di rilanciare attività fallite per sempre:417 Crea il servizio. Il circuit breaker del deploy riporta all'ultimo stato stabile un deploy le cui attività continuano a fallire, a causa di un'immagine difettosa o di una configurazione che non si avvia, anziché rilanciare all'infinito attività che falliscono:

418 418 

419 ```bash theme={null}419 ```bash theme={null}

420 aws ecs create-service --cluster claude-gateway --service-name claude-gateway \420 aws ecs create-service --cluster claude-gateway --service-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 Il periodo di grazia di 60 secondi dà a un'attività fredda il tempo di estrarre l'immagine, connettersi allo store e rispondere al suo primo controllo di stato prima che ECS inizi a contare i fallimenti rispetto alla distribuzione. Il controllo di stato del gruppo di destinazione su `GET /readyz` verifica che lo store sia raggiungibile, quindi un'attività che non può raggiungere Postgres non entra mai in rotazione. Per mantenere le attività che passano il controllo attraverso una breve interruzione del database come un failover RDS, impostate `store.readiness_grace_seconds` come descritto in [Comportamento di interruzione](/docs/it/claude-apps-gateway-deploy#outage-behavior), che copre anche l'alternativa `/healthz`.428 Il periodo di tolleranza di 60 secondi dà a un'attività avviata a freddo il tempo di scaricare l'immagine, connettersi allo store e rispondere al primo controllo di stato prima che ECS inizi a contare i fallimenti a carico del deploy.

429 429 

430 Le attività vengono eseguite in subnet private senza IP pubblico, quindi tutto l'egresso (verso Bedrock, il vostro IdP, Secrets Manager, ECR e CloudWatch Logs) passa attraverso il gateway NAT. Per mantenere il traffico Bedrock fuori dal percorso pubblico, create un endpoint VPC dell'interfaccia `bedrock-runtime` e puntate l'`base_url` dell'upstream ad esso, come mostrato nel [riferimento upstream Bedrock](/docs/it/claude-apps-gateway-config#amazon-bedrock); l'IdP ha ancora bisogno di uscita a Internet.430 Il controllo di stato del gruppo di destinazione su `GET /readyz` verifica che lo store sia raggiungibile, quindi un'attività che non riesce a raggiungere Postgres non entra mai in rotazione. Per far sì che le attività continuino a superare il controllo durante una breve interruzione del database, come un failover RDS, imposta `store.readiness_grace_seconds` come descritto in [Comportamento in caso di interruzione](/docs/it/claude-apps-gateway-deploy#outage-behavior), che tratta anche l'alternativa `/healthz`.

431 431 

432 Finite dando agli sviluppatori un nome host risolvibile privatamente: in una zona ospitata privata Route 53, alias il nome DNS interno del gateway all'ALB, e impostate `listen.public_url` a quel nome host. Il nome `*.elb.amazonaws.com` dell'ALB stesso si risolve in indirizzi privati su un ALB interno, ma non può portare il vostro certificato ACM, quindi utilizzate il vostro nome.432 Le attività vengono eseguite in subnet private senza IP pubblico, quindi tutto il traffico in uscita (verso Bedrock, il tuo IdP, Secrets Manager, ECR e CloudWatch Logs) passa attraverso il gateway NAT. Per tenere il traffico Bedrock fuori dal percorso pubblico, crea un endpoint VPC di interfaccia `bedrock-runtime` e punta il `base_url` dell'upstream a esso, come mostrato nel [riferimento upstream Bedrock](/docs/it/claude-apps-gateway-config#amazon-bedrock); l'IdP ha comunque bisogno di uscita verso Internet.

433 433 

434 Aggiornate l'URI di reindirizzamento autorizzato del client OAuth a `<public_url>/oauth/callback` prima del primo accesso. Dopo aver cambiato `public_url`, ricompilate e spingete l'immagine sotto un nuovo tag, registrate una nuova revisione della definizione di attività e ridistribuite. Su ECS l'impostazione vive nel `gateway.yaml` incorporato dell'immagine, e il gateway costruisce la sua origine pubblica solo da quell'impostazione, ignorando `X-Forwarded-Host` e `X-Forwarded-Proto`. `X-Forwarded-For` è onorato per gli IP dei client solo quando `listen.trusted_proxies` è impostato.434 Per finire, fornisci agli sviluppatori un nome host risolvibile privatamente: in una zona ospitata privata di Route 53, crea un alias dal nome DNS interno del gateway all'ALB e imposta `listen.public_url` su quel nome host. Il nome `*.elb.amazonaws.com` dell'ALB si risolve in indirizzi privati su un ALB interno, ma non può usare il tuo certificato ACM, quindi usa un nome tuo.

435 

436 Aggiorna l'URI di reindirizzamento autorizzato del client OAuth a `<public_url>/oauth/callback` prima del primo accesso. Dopo aver modificato `public_url`, esegui di nuovo la build e il push dell'immagine con un nuovo tag, registra una nuova revisione della definizione di attività ed esegui di nuovo il deploy. Su ECS l'impostazione si trova nel `gateway.yaml` incorporato nell'immagine, e il gateway costruisce la propria origine pubblica solo da quell'impostazione, ignorando `X-Forwarded-Host` e `X-Forwarded-Proto`. `X-Forwarded-For` viene considerato per gli IP dei client solo quando `listen.trusted_proxies` è impostato.

435 </Tab>437 </Tab>

436 438 

437 <Tab title="EKS">439 <Tab title="EKS">

438 Questo percorso ha bisogno di `kubectl` e `eksctl` installati localmente, e di un cluster EKS esistente con un provider OIDC IAM e AWS Load Balancer Controller installato. Il cluster deve essere su `$VPC_ID` in modo che i pod possano raggiungere l'endpoint privato RDS, e il gruppo di sicurezza `claude-gateway-db` deve ammettere il gruppo di sicurezza del pod o del nodo del cluster al posto di `$GW_SG`.440 Questo percorso richiede `kubectl` ed `eksctl` installati localmente e un cluster EKS esistente con un provider OIDC IAM e AWS Load Balancer Controller installato. Il cluster deve trovarsi su `$VPC_ID` affinché i pod possano raggiungere l'endpoint privato RDS, e il gruppo di sicurezza `claude-gateway-db` deve ammettere il gruppo di sicurezza dei pod o dei nodi del cluster al posto di `$GW_SG`.

439 441 

440 Su EKS il gateway ottiene le sue credenziali Bedrock tramite IRSA piuttosto che i ruoli ECS. La politica di fiducia `ecs-tasks.amazonaws.com` dal passaggio IAM non si applica qui; IRSA ha bisogno di un ruolo la cui politica di fiducia si federi sul provider OIDC del cluster, scoped a `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` crea quel ruolo, allega le politiche e annota l'account di servizio Kubernetes con l'ARN del ruolo in un passaggio. Trasformate i due documenti della politica dal passaggio IAM in politiche gestite che può allegare:442 Su EKS il gateway ottiene le credenziali Bedrock tramite IRSA anziché tramite i ruoli ECS. La policy di attendibilità `ecs-tasks.amazonaws.com` del passaggio IAM non si applica qui; IRSA ha bisogno di un ruolo la cui policy di attendibilità sia federata sul provider OIDC del cluster, limitata a `system:serviceaccount:claude-gateway:gateway`. `eksctl create iamserviceaccount` crea quel ruolo, collega le policy e annota l'account di servizio Kubernetes con l'ARN del ruolo in un unico passaggio. Trasforma i due documenti di policy del passaggio IAM in policy gestite che il comando può collegare:

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 politica dei segreti è necessaria solo quando i pod leggono Secrets Manager stessi, come fa il provider AWS del driver CSI Secrets Store utilizzando l'account di servizio del pod di montaggio; eliminatela se create i Kubernetes Secrets in un altro modo. Il provider ha bisogno di entrambe le azioni della politica: chiama `DescribeSecret` quando riconcilia i segreti ruotati, quindi una concessione `GetSecretValue`-only monta sulla prima distribuzione ma smette di raccogliere rotazioni.458 La policy dei segreti è necessaria solo quando i pod leggono direttamente Secrets Manager, come fa il provider AWS del driver CSI Secrets Store usando l'account di servizio del pod che esegue il montaggio; rimuovila se crei i Kubernetes Secrets in un altro modo. Il provider ha bisogno di entrambe le azioni della policy: chiama `DescribeSecret` quando riconcilia i segreti ruotati, quindi una concessione limitata a `GetSecretValue` esegue il montaggio al primo deploy ma smette di recepire le rotazioni.

457 459 

458 Distribuite il gateway come Deployment standard più un Service e un Ingress, come descritto in [Distribuzione Kubernetes](/docs/it/claude-apps-gateway-deploy#kubernetes), con:460 Esegui il deploy del gateway come Deployment standard più un Service e un Ingress, come descritto in [Deploy su Kubernetes](/docs/it/claude-apps-gateway-deploy#kubernetes), con:

459 461 

460 * `serviceAccountName: gateway`462 * `serviceAccountName: gateway`

461 * `gateway.yaml` montato da una ConfigMap e i segreti montati a `/secrets`463 * `gateway.yaml` montato da una ConfigMap e i segreti montati in `/secrets`

462 * il probe di prontezza puntato a `GET /readyz`464 * il readiness probe puntato a `GET /readyz`

463 465 

464 Per il front end, un Ingress gestito da AWS Load Balancer Controller esegue il provisioning dell'ALB interno. Annotatelo con:466 Per il front end, un Ingress gestito da AWS Load Balancer Controller esegue il provisioning dell'ALB interno. Annotalo con:

465 467 

466 * `alb.ingress.kubernetes.io/scheme: internal` e `alb.ingress.kubernetes.io/target-type: ip`468 * `alb.ingress.kubernetes.io/scheme: internal` e `alb.ingress.kubernetes.io/target-type: ip`

467 * `alb.ingress.kubernetes.io/ip-address-type: ipv4`, in modo che nessun record AAAA di intervallo pubblico venga pubblicato per il controllo della rete privata `/login` [private-network check](/docs/it/claude-apps-gateway#prerequisites) da rifiutare469 * `alb.ingress.kubernetes.io/ip-address-type: ipv4`, in modo che non vengano pubblicati record AAAA di intervallo pubblico che il [controllo della rete privata](/docs/it/claude-apps-gateway#prerequisites) di `/login` rifiuterebbe

468 * `alb.ingress.kubernetes.io/inbound-cidrs: <your-corporate-cidr>`, in modo che il gruppo di sicurezza gestito dal controller ammetta solo la vostra rete aziendale al posto del suo default `0.0.0.0/0`470 * `alb.ingress.kubernetes.io/inbound-cidrs: <your-corporate-cidr>`, in modo che il gruppo di sicurezza frontend gestito dal controller ammetta solo la tua rete aziendale al posto del suo valore predefinito `0.0.0.0/0`

469 * `alb.ingress.kubernetes.io/certificate-arn` con il certificato ACM471 * `alb.ingress.kubernetes.io/certificate-arn` con il certificato ACM

470 * `alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06`, in modo che il listener non ricada nella politica predefinita legacy che accetta TLS 1.0 e 1.1472 * `alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06`, in modo che il listener non ricada sulla policy predefinita legacy che accetta TLS 1.0 e 1.1

471 * `alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=3600`, un margine sopra il keepalive di streaming del gateway; consultate [Troubleshooting](#troubleshooting)473 * `alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=3600`, un margine rispetto al keepalive di streaming del gateway; consulta [Risoluzione dei problemi](#troubleshooting)

472 474 

473 Con IRSA, l'AWS SDK legge un token dell'account di servizio proiettato e lo scambia con AWS STS, quindi il pod non ha mai bisogno del servizio di metadati dell'istanza EC2; una NetworkPolicy di egresso può bloccare `169.254.169.254` per i pod del gateway. Il problema del limite di hop del nodo in [Troubleshooting](#troubleshooting) sottostante si applica solo ai cluster che saltano IRSA e si affidano ai ruoli dell'istanza del nodo.475 Con IRSA, l'AWS SDK legge un token proiettato dell'account di servizio e lo scambia con AWS STS, quindi il pod non ha mai bisogno del servizio di metadati dell'istanza EC2; una NetworkPolicy in uscita può bloccare `169.254.169.254` per i pod del gateway. Il problema del limite di hop dei nodi descritto in [Risoluzione dei problemi](#troubleshooting) più avanti riguarda solo i cluster che non usano IRSA e si affidano ai ruoli delle istanze dei nodi.

474 </Tab>476 </Tab>

475 </Tabs>477 </Tabs>

476 </Step>478 </Step>

477 479 

478 <Step title="Spingere l'URL del gateway alle macchine degli sviluppatori">480 <Step title="Distribuire l'URL del gateway ai computer degli sviluppatori">

479 Il gateway è ora in esecuzione, ma gli sviluppatori non possono raggiungerlo da `/login` fino a quando l'URL del gateway non è sulle loro macchine. Impostate `forceLoginMethod` e `forceLoginGatewayUrl` nel [file delle impostazioni gestite](/docs/it/claude-apps-gateway#set-the-gateway-url) che distribuite a ogni dispositivo tramite MDM. Non c'è opzione di gateway nel selettore di accesso per uno sviluppatore da selezionare manualmente.481 Il gateway è ora in esecuzione, ma gli sviluppatori non possono raggiungerlo da `/login` finché l'URL del gateway non è presente sui loro computer. Imposta `forceLoginMethod` e `forceLoginGatewayUrl` nel [file delle impostazioni gestite](/docs/it/claude-apps-gateway#set-the-gateway-url) che distribuisci su ogni dispositivo tramite MDM. Nel selettore di accesso non esiste un'opzione gateway che uno sviluppatore possa selezionare manualmente.

480 </Step>482 </Step>

481</Steps>483</Steps>

482 484