Paramètres gérés (politique de l’organisation)¶
Les paramètres gérés autorisent les administrateurs IT à appliquer le comportement de la CLI Cortex Code au sein d’une organisation. Les paramètres sont déployés dans un fichier appartenant au système que les utilisateurs ne peuvent pas modifier. Ces paramètres ont priorité sur toute la configuration au niveau de l’utilisateur.
Lorsque des paramètres gérés sont présents, la CLI affiche une bannière au démarrage indiquant qu’elle fonctionne en mode géré.
Fonctionnement des paramètres gérés¶
Les paramètres gérés sont lus à partir d’un fichier JSON placé dans un répertoire système spécifique à la plate-forme, un emplacement dans lequel l’écriture nécessite des privilèges d’administrateur ou de racine. Les utilisateurs ne pouvant pas modifier les fichiers à ces emplacements, les paramètres gérés ne peuvent pas être remplacés par les fichiers de configuration utilisateur, les variables d’environnement ou les arguments de ligne de commande (sauf indication contraire).
Les administrateurs déploient généralement le fichier de paramètres géré à l’aide des outils MDM (Jamf, Intune,SCCM), des systèmes de gestion de configuration (Ansible, Chef, Puppet), ou du déploiement manuel pendant la mise en service de l’appareil.
Emplacements de fichier¶
Placez le fichier managed-settings.json dans le répertoire système suivant pour votre système d’exploitation :
Plateforme |
Chemin |
|---|---|
macOS |
|
Linux et WSL |
|
Windows |
|
Si le fichier n’existe pas, la CLI s’exécute en mode non géré et toutes les valeurs par défaut au niveau de l’utilisateur s’appliquent.
Note
Si le fichier existe, mais contient un JSON non valide ou ne peut pas effectuer la validation du schéma, la CLI applique une configuration de secours restrictive et affiche une bannière indiquant « Erreur de configuration de l’application - mode restreint ». Cela empêche un fichier de politique malformé d’accorder silencieusement un accès illimité.
Schéma de configuration¶
Le fichier managed-settings.json doit contenir un champ version. Toutes les sections de niveau supérieur sont facultatives.
Le champ version doit être "1.0".
permissions¶
Contrôle les outils, les compétences, les serveurs MCP, et les comptes Snowflake que la CLI peut utiliser. Pour la syntaxe complète du modèle, voir Modèles d’autorisation.
Champ |
Type |
Par défaut |
Description |
|---|---|---|---|
|
|
— |
Liste d’autorisation des modèles d’autorisation. Si cette option est activée, seuls les éléments correspondants sont autorisés. Les éléments ne correspondant à aucun modèle sont bloqués sauf si |
|
|
— |
Liste d’interdiction des modèles d’autorisation. L’interdiction a la priorité sur l’autorisation. Une correspondance ici bloque toujours, indépendamment de |
|
|
|
Comportement lorsqu’aucun modèle ne correspond. Utilisez |
|
|
|
Contrôle si les utilisateurs peuvent utiliser l’indicateur |
settings¶
Force des comportements d’exécution spécifiques qui ne peuvent pas être remplacés par les utilisateurs.
Champ |
Type |
Par défaut |
Description |
|---|---|---|---|
|
|
|
Lorsque |
|
|
|
Lorsque |
|
|
— |
Force un mode sandbox spécifique. |
Le sandbox limite les répertoires que la CLI peut lire et écrire pendant une session. Il ajoute une étape de confirmation avant que les outils n’accèdent à des chemins en dehors de l’ensemble pré-approuvé. Le mode "regular" nécessite une confirmation de l’utilisateur pour chaque nouveau répertoire ; le mode "autoAllow" fait confiance à tous les répertoires de l’arborescence de travail sans invite. Le sandbox est une fonction expérimentale. Pour plus de détails, voir Sandbox.
required¶
Applique une version de CLI minimale. La CLI se termine avec une erreur si la version installée ne répond pas à l’exigence.
Champ |
Type |
Description |
|---|---|---|
|
|
La version CLI minimale au format sempre (par exemple, |
Utilisez ce champ pour vous assurer que tous les utilisateurs utilisent une version qui prend en charge tout correctif de sécurité ou toute fonctionnalité dont dépend votre politique.
defaults¶
Définit les valeurs par défaut recommandées par l’organisation que les utilisateurs peuvent remplacer dans leur propre settings.json. Contrairement à la section settings, il s’agit de suggestions, et non d’application.
Champ |
Type |
Description |
|---|---|---|
|
|
Nom de la connexion Snowflake par défaut de |
|
|
Profil par défaut à charger au démarrage. |
|
|
Thème de couleur de l’UI par défaut. |
files¶
Pointe la CLI vers les fichiers de configuration fournis par l’administrateur. Ceux-ci sont chargés en plus ou à la place des propres équivalents de l’utilisateur.
Champ |
Type |
Description |
|---|---|---|
|
|
Chemin absolu vers un |
|
|
Chemin absolu vers un |
ui¶
Personnalise les éléments UI pour indiquer un état géré.
Champ |
Type |
Par défaut |
Description |
|---|---|---|---|
|
|
|
Lorsque |
|
|
|
Texte personnalisé pour la bannière gérée. Utilisez-le pour inclure un contact de support ou une référence de politique. |
|
|
|
Lorsque |
Modèles d’autorisation¶
Les tableaux onlyAllow et deny dans la section permissions acceptent des modèles sous deux formes :
Nom simple : correspond exactement à une catégorie d’outil ou de fonctionnalités nommée. Par exemple,
"bash"ou"read"Nom filtré :
type(filter). Correspond à un appel d’outil ou à une ressource spécifique dans une catégorie. Par exemple,"bash(git:*)"ou"account(myorg-prod)"
Les deux formes prennent en charge les caractères génériques glob * (n’importe quel caractère) et ? (caractère unique). La correspondance est insensible à la casse.
Référence de modèle¶
Motif |
Ce qu’il contrôle |
|---|---|
|
L’outil |
|
L’outil |
|
L’outil |
|
Tous les appels aux commandes bash/shell |
|
Bash limité aux commandes |
|
Bash limité aux commandes |
|
Bash limité aux commandes |
|
Commandes |
|
Exécution SQL par rapport à Snowflake |
|
Tous les serveurs MCP |
|
Serveurs MCP correspondant à un glob URL |
|
Compétences intégrées (groupées) |
|
Compétences depuis n’importe quel profil chargé |
|
Compétences d’un profil nommé spécifique |
|
Compétences installées dans le répertoire personnel de l’utilisateur |
|
Compétences dans le répertoire |
|
Compétences installées à distance (via git ou tarball) |
|
Tous les plug-ins |
|
Plug-ins intégrés uniquement |
|
Nom d’utilisateur Snowflake précis |
|
Comptes Snowflake correspondant à un glob |
Filtrage de bash(command:*)¶
Lorsque vous utilisez des modèles de filtrage bash, le filtre correspond au premier jeton de la commande shell. Par exemple,`` »bash(git:*) »`` autorise git status,``git commit``, et toute autre sous-commande git, mais bloque curl, python, et toute autre commande.
Note
Si "bash" (sans filtre) apparaît dans onlyAllow, alors toute commande bash est autorisée pour cette règle. Si "bash(git:*)" apparaît mais la commande "bash" simple ne le fait pas, alors seules les commandes git sont autorisées et toutes les autres commandes bash sont bloquées.
Évaluation des autorisations¶
Lorsque la CLI décide si un outil, une compétence, un serveur MCP ou un compte Snowflake est autorisé, elle évalue les règles suivantes dans l’ordre :
Correspondances ``deny`` gérées : bloc. S’il existe un modèle dans le tableau
denydes paramètres gérés qui correspond, l’accès est refusé. Ceci ne peut pas être écrasé par les profils ou les paramètres des utilisateurs.Correspondances ``deny`` de profil : bloc. Si un modèle de la liste de refus du profil actif correspond, l’accès est refusé.
``onlyAllow`` géré est défini et aucun modèle ne correspond : bloc. Si
onlyAllowest configuré dans des paramètres gérés et que l’élément ne correspond à aucun modèle de la liste, l’accès est refusé.**Le profil
onlyAllowest défini pour ce type et aucun modèle ne correspond : bloc.**Le profileonlyAllowest à l’échelle du type : il ne restreint que les types qui sont explicitement répertoriés. Si le profil répertorieskill(bundled:*)mais n’indique rien surbash, l’accès à bash n’est pas affecté par le profil.``defaultMode`` détermine le résultat. Si
defaultModeest"deny", l’accès est bloqué. Si"allow"(par défaut), l’accès est autorisé.
Principales garanties :
Un profil ne peut pas accorder un accès que les paramètres gérés ont explicitement refusé.
Un profil ne peut pas développer la liste d’autorisation des paramètres gérés.
Les profils ne peuvent que restreindre davantage : ils opèrent dans les limites définies par les paramètres gérés.
Exemples de politiques communes¶
Configuration d’entreprise de base¶
Autorisez tous les outils par défaut, mais bloquez le mode de contournement et affichez une bannière gérée.
Restriction aux comptes Snowflake approuvés¶
Autorisez uniquement les connexions à des comptes spécifiques. Les utilisateurs qui tentent de se connecter à un autre compte voient une erreur.
Verrouiller sur les outils approuvés uniquement¶
Autorisez uniquement la lecture des fichiers, l’exécution SQL, et les compétences regroupées. Bloquer toutes les commandes bash, MCP, et les compétences installées par l’utilisateur.
Autoriser bash mais bloquer les commandes dangereuses¶
Autoriser l’accès à la commande bash mais explicitement refuser rm, curl, et``wget``.
Déploiement de haute sécurité¶
Forcer l’absence d’historique, forcer le sandbox, bloquer le mode de contournement, restreindre à des comptes spécifiques et aux serveurs MCP et bloquer l’installation des compétences à distance.
Vérification¶
Pour confirmer que les paramètres gérés sont actifs et voir quelles restrictions sont appliquées, inspectez la bannière d’accueil au démarrage. Lorsque des paramètres gérés sont présents et que showManagedBanner est true, une bannière est affichée en haut de la sortie de la session.
Pour contrôler le chemin de configuration de l’application de votre plateforme, vérifiez si le fichier existe à l’adresse du chemin spécifique à OS répertorié dans Emplacements de fichier.