Opérations de politique d’isolation

Gérer l’exigence microVM d’une organisation indépendamment des backends d’exécution déployés.

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.

Forme de la politique

type IsolationPolicy = {
  requireIsolatedExecution?: boolean
}

Une valeur absente ou true impose microvm. false autorise le résolveur produit à utiliser un backend managed_process déployé et prêt lorsque la microVM est indisponible. Cela ne force pas ce niveau et ne déploie aucun backend.

Les anciennes lignes peuvent contenir isolateUntrusted, requireTrueVm ou fallback. Scrydon les lit pendant les mises à niveau progressives, mais ces champs ne sélectionnent plus un niveau produit. L’enregistrement depuis Paramètres → Plateforme → Compute réécrit la forme canonique.

Créer ou modifier

Utilisez la page Compute ou le client Better Auth authentifié d’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

Il n’existe aucun chemin de modification depuis un workflow, une clé API ou un service. Un service d’exécution ne peut donc pas modifier sa propre politique de placement.

Inspecter

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

if (result.error) throw result.error
console.log(result.data?.value ?? {})
console.log(result.data?.lastModifiedBy, result.data?.updatedAt)

get renvoie la valeur stockée, pas la décision effective du déploiement et de l’état de préparation. Confirmez l’événement isolation.policy.updated après chaque modification.

Restaurer la valeur sécurisée par défaut

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

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

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

Procédure de changement

Enregistrez la politique actuelle, les backends déployés, leur état et le ticket.
Vérifiez les profils de charge sur chaque niveau que le déploiement peut sélectionner.
Modifiez la politique depuis une session propriétaire/admin et conservez lastModifiedBy et updatedAt.
Exécutez des canaris Agent, Function/implémentation et notebook.
Testez le cas négatif : exigence activée, une microVM indisponible doit être refusée même si l’acteur géré est prêt. Exigence relâchée, un profil acteur indisponible doit aussi être refusé, sans exécution dans un service produit.
Restaurez la valeur capturée ou écrivez {} pour revenir en arrière.

Le niveau est lié avant l’envoi. Un échec après liaison n’est jamais réessayé sur un niveau plus faible.

Déploiement des backends et IaC

executionFabric:
  managedProcess:
    enabled: true

runtimePlane:
  enabled: true

Le déploiement peut fournir un backend ou les deux. L'ordre produit est fixe : microVM d'abord, puis processus géré uniquement si l'organisation l'autorise. Si l'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.

La modification d’organisation exige une session utilisateur ; sa réconciliation Terraform/GitOps sans surveillance n’est pas prise en charge.

Limites de portée

La politique s’applique à l’organisation. Elle ne propose ni liaison workspace, ni activation planifiée, ni workflow d’approbation, ni exception par bloc. Un manifeste peut exiger microvm, mais ne peut pas relâcher le minimum de l’organisation.