AWS décrit une configuration contrôlée de ChatGPT Desktop via Bedrock GovCloud avec vérification séparée de l’identité et de l’appareil

AWS a publié le 30 octobre une procédure pour acheminer l’inférence de l’application de bureau ChatGPT par Amazon Bedrock dans AWS GovCloud (US). Cette édition technique du 1er novembre conserve la date originale. Le guide vise les organisations qui exigent les identités, les points de terminaison et les contrôles régionaux de GovCloud. Il décrit un essai local contrôlé dans `us-gov-west-1` avec Bedrock Mantle. AWS précise expressément que l’usage de GovCloud et la lecture du guide n’autorisent pas à eux seuls une charge de travail. Chaque organisation doit examiner modèle, services, appareil, dépôts, identifiants et flux de données dans sa propre procédure de sécurité.

L’application propose deux usages: Work pour les tâches longues de planification, recherche et fichiers, et Codex pour le code, les tests et la revue de demandes de modification. L’application ou la CLI fonctionne sur un appareil géré par l’organisation et emploie l’identité AWS configurée pour appeler Bedrock. Dans ce chemin direct vers AWS, les contrôles déterminants sont ceux de l’appareil et les droits IAM, plutôt que les rôles habituels d’un espace de travail ChatGPT, selon le billet. AWS évoque un traitement dans la région choisie, une facturation par jeton sans licence par siège et la possibilité d’une conservation nulle des données. Ces propriétés doivent encore être vérifiées dans la configuration approuvée.

Les prérequis dépassent l’installation du logiciel. Il faut confirmer que la version exacte de l’application prend en charge GovCloud, disposer d’un compte et d’une identité IAM approuvés et avoir accès au modèle, à la région et au point de terminaison autorisés. Le parcours comprend l’authentification, les fichiers `requirements.toml` et `config.toml`, puis le démarrage et la vérification. Le profil nommé `codex-il5` est un exemple d’étiquette, pas un secret à recopier. Identifiants, jetons bearer et jetons de session doivent rester hors des fichiers TOML. La configuration du profil, le cache SSO et les outils d’authentification doivent être protégés contre les écritures de tâches.

L’ordre de choix des identifiants est une condition importante. L’application recherche d’abord `AWS_BEARER_TOKEN_BEDROCK` dans l’environnement; s’il est présent, le jeton passe avant le profil. Sinon la chaîne standard d’identifiants AWS SDK peut lire le profil nommé ou une session SSO d’IAM Identity Center. Un profil apparemment correct ne prouve donc pas quelle identité AWS appelle réellement le modèle. En cas de mauvaise identité, il faut examiner la source effective des identifiants et vérifier si un jeton a supplanté le profil. Les restrictions de réseau et de capacité de l’appareil sont des contrôles distincts; la seule connexion en mode API ne les applique pas intégralement.

AWS demande de placer les deux fichiers de configuration avant le premier démarrage. Si le logiciel a déjà été lancé, il doit être quitté puis redémarré pour recharger la politique et le fournisseur. Il s’agit des étapes de déploiement décrites par le fournisseur, non d’actions effectuées par notre rédaction sur un service actif. Après le lancement, l’opérateur vérifie `amazon-bedrock` dans `/status` de Codex CLI et dans les paramètres de l’application. Il vérifie aussi l’identité approuvée, `us-gov-west-1`, le point de terminaison et les restrictions réseau. Voir le seul nom du fournisseur à l’écran ne démontre pas la conformité des flux de données.

Le guide distingue plusieurs échecs: demande de connexion inattendue à un compte OpenAI, point de terminaison non pris en charge, mauvaise identité AWS et limites de capacité manquantes. Changer simplement une URL ne rend pas compatible une version non prise en charge. Un mode de connexion API ne remplace pas la politique complète de l’appareil. Si une vérification échoue, AWS conseille d’arrêter le déploiement, de revenir aux réglages précédemment approuvés, de révoquer les identifiants temporaires et de confirmer que les appareils concernés ne peuvent plus joindre Bedrock.

Nous n’avons ni configuré un poste GovCloud ni validé un environnement administratif. Le fait documenté est le chemin de configuration contrôlé publié par AWS, avec ses limites d’authentification et de politique d’appareil. Toute équipe doit d’abord obtenir ses propres autorisations puis vérifier la prise en charge exacte et le traitement des données dans le guide complet et la documentation à jour. La disponibilité annoncée ne constitue pas une garantie universelle de conformité pour chaque installation.