Opérations de politique d’isolation

platform.isolation_policy est le contrôle d’organisation de la fabrique d’exécution. Seul un propriétaire ou administrateur de l’organisation peut le modifier. Les workflows, les intégrations et les comptes de service ne peuvent ni sélectionner un niveau ni modifier la politique.

Forme de la politique

type IsolationPolicy = {
  requireIsolatedExecution?: boolean
}

Une valeur absente ou true signifie que les charges exécutables exigent microvm. false autorise le résolveur produit à se rabattre sur un backend managed_process déployé et prêt lorsque la microVM est indisponible. Cela ne force pas le processus géré et ne déploie aucun backend.

Les anciennes lignes peuvent contenir isolateUntrusted, requireTrueVm ou fallback. Scrydon lit ces champs pendant les mises à niveau progressives, mais ils ne sélectionnent plus un niveau d’exécution produit. L’enregistrement de la page de paramètres Compute réécrit la ligne dans la forme canonique ci-dessus.

Créer ou modifier

Utilisez Paramètres → Plateforme → Compute, ou le client Better Auth authentifié depuis une session propriétaire/admin :

const result = await authClient.organization.policy.update({
  organizationId,
  key: 'platform.isolation_policy',
  value: { requireIsolatedExecution: false },
})

if (result.error) throw result.error
// A reply with neither `error` nor `data` did not confirm the write.
if (!result.data) throw new Error('Policy update was not confirmed')

Les écritures se font uniquement par session. Il n’existe aucun chemin de modification depuis un workflow, une clé API ou un service à service ; un service d’exécution ne peut donc pas modifier la politique qui gouverne son propre placement.

Inspecter

const result = await authClient.organization.policy.get({
  organizationId,
  key: 'platform.isolation_policy',
})

if (result.error) throw result.error
// A reply with neither `error` nor `data` is a failed read, not an empty policy.
if (!('data' in result)) throw new Error('Policy read returned no result')
// `data` is `null` only when no row is stored; the default requirement then applies.
console.log(result.data?.value ?? {})
console.log(result.data?.lastModifiedBy, result.data?.updatedAt)

Traitez toute erreur, ou une réponse qui ne porte ni data ni error, comme « politique inconnue » et arrêtez-vous. Lire une requête échouée comme une politique vide signalerait la valeur par défaut à échec fermé comme active alors que vous n’avez pas réellement lu la ligne.

get renvoie la valeur stockée de l’organisation, et non la décision effective du déploiement et de l’état de préparation. Confirmez l’événement isolation.policy.updated correspondant après chaque modification ; l’écriture peut réussir même si la livraison de l’événement échoue par la suite.

Restaurer la valeur par défaut à échec fermé

Écrivez { requireIsolatedExecution: true } ou {}. Une politique vide signifie que l’exigence par défaut est active.

await authClient.organization.policy.update({
  organizationId,
  key: 'platform.isolation_policy',
  value: {},
})

Ne supprimez et ne modifiez pas directement la ligne en base de données : cela contourne l’autorisation et l’événement de cycle de vie de la politique.

Procédure de changement

1. Enregistrez la ligne actuelle de l’organisation, les backends déployés, l’état de préparation des backends et le ticket de changement.
2. Vérifiez que les profils de charge prévus sont prêts sur chaque niveau que le déploiement peut sélectionner.
3. Modifiez la politique depuis une session propriétaire/admin et conservez lastModifiedBy et updatedAt.
4. Exécutez des canaris pour Agent, l’implémentation Function/fournisseur et les jobs de notebook.
5. Testez le cas négatif. Avec l’exigence activée, une microVM indisponible doit être refusée même si l’acteur géré est sain. Avec le relâchement activé, un profil d’acteur indisponible doit aussi être refusé plutôt que de s’exécuter dans un service produit.
6. Revenez en arrière en restaurant la valeur capturée ou en écrivant {}.

Déploiement des backends et IaC

Le déploiement des backends relève de Helm/GitOps :

executionFabric:
  managedProcess:
    enabled: true

runtimePlane:
  enabled: true

Les opérateurs peuvent déployer la microVM, le processus géré, ou les deux. L’ordre produit est fixe : microVM d’abord, puis processus géré uniquement pour une organisation qui l’autorise. Si une organisation exige l’isolation et que la microVM est indisponible, l’exécution est refusée même si le backend géré est prêt.

Le point de terminaison d’écriture de l’organisation exige une session utilisateur ; la réconciliation Terraform/GitOps sans surveillance des lignes d’organisation n’est donc pas prise en charge. Ne l’automatisez pas avec des cookies de navigateur stockés ni avec des écritures directes en base de données.

Limites de portée

La politique s’applique à l’organisation. Elle ne prend pas en charge les liaisons de workspace, l’activation planifiée, les workflows d’approbation ni les exceptions par bloc. Un manifeste peut exiger microvm pour sa propre capacité, mais ne peut pas relâcher le minimum de l’organisation.