Exploitation de la politique d'isolation

platform.isolation_policy est la couche de renforcement appartenant à l'organisation pour l'isolation des étapes non fiables. Seul un propriétaire ou administrateur de l'organisation peut la modifier. Un workflow, une intégration ou un compte de service ne peut ni choisir un niveau ni affaiblir cette politique.

Forme de la politique

type IsolationPolicy = {
  isolateUntrusted?: boolean
  requireTrueVm?: boolean
  fallback?: 'hardened' | 'hard_refuse'
}

Chaque champ est facultatif et hérite de la valeur du déploiement lorsqu'il est absent. Une valeur false explicite ou un repli plus faible ne peut jamais réduire le plancher immuable du déploiement. Le schéma est strict : les champs inconnus, replis invalides et indicateurs non booléens sont refusés. mediated n'est pas accepté comme politique d'organisation dans cette version, car l'enforcer natif ne fonctionne pas sous gVisor. Le protocole du runtime-plane reste lisible, tandis que les anciennes valeurs de déploiement deviennent hard_refuse.

Créer ou modifier

Utilisez le client Better Auth authentifié depuis une session propriétaire/admin. La même opération upsert crée l'enregistrement à la première utilisation puis le met à jour :

const result = await authClient.organization.policy.update({
  organizationId,
  key: 'platform.isolation_policy',
  value: {
    isolateUntrusted: true,
    requireTrueVm: true,
    fallback: 'hard_refuse',
  },
})

if (result.error) throw result.error

Les écritures exigent une session utilisateur. Il n'existe aucun endpoint d'écriture service-à-service, chemin de mutation par clé API ou capacité de mutation depuis un workflow : un service d'exécution ne peut donc pas modifier son propre contrôle.

Consulter la surcharge

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 surcharge stockée et non un document calculé de politique effective. lastModifiedBy et updatedAt fournissent les métadonnées du changement. Un hook après écriture tente d'émettre isolation.policy.updated avec les valeurs précédente et suivante. L'écriture de la politique peut réussir si la livraison d'audit échoue ; les opérateurs doivent donc confirmer l'événement correspondant après chaque changement et surveiller les échecs du hook.

Révoquer la surcharge

Il n'existe pas d'opération publique de suppression. Écrivez la politique stricte vide :

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

La ligne auditable est conservée, mais les trois champs héritent à nouveau du déploiement. Ne supprimez pas directement la ligne en base : cela contournerait l'autorisation et l'événement de cycle de vie.

Procédure de changement

1. Conservez la ligne actuelle, les valeurs du déploiement, le cluster cible et le ticket.
2. Vérifiez que le runtime plane voit la RuntimeClass et un nœud Ready et planifiable.
3. Modifiez la politique depuis une session propriétaire/admin et conservez lastModifiedBy et updatedAt.
4. Exécutez un canari hors production pour chaque surface concernée. Un canari vraie VM doit tracer microvm, kata-vm-isolation, une identité de workload/pod neuve et l'image candidate.
5. Rendez le niveau requis indisponible. Avec requireTrueVm: true ou fallback: 'hard_refuse', le canari doit être refusé et jamais réussir sur un niveau plus faible.
6. Restaurez la valeur capturée, ou écrivez {} pour revenir à l'héritage.

Base de déploiement et IaC

Les valeurs par défaut sont des entrées de version Helm/GitOps : RUNTIME_PLANE_ISOLATE_UNTRUSTED, RUNTIME_PLANE_EXEC_REQUIRE_TRUE_VM et RUNTIME_PLANE_EXEC_FALLBACK (hard_refuse par défaut). Versionnez et approuvez-les comme IaC de déploiement.

Ces valeurs constituent un minimum immuable imposé côté serveur. Les exigences booléennes sont combinées par OU et la résolution retient le repli pris en charge le plus strict (hard_refuse > hardened). Un administrateur d'organisation peut renforcer la frontière, jamais l'affaiblir.

L'écriture exige une session utilisateur ; la réconciliation automatisée Terraform/GitOps des lignes d'organisation n'est pas prise en charge. N'utilisez ni cookies de navigateur stockés ni écriture directe en base. GitOps gère les valeurs du déploiement, et un changement admin autorisé gère les surcharges d'organisation.

Limites de portée

La politique est limitée à l'organisation. Elle ne prend pas en charge les liaisons à un workspace ou environnement, l'activation planifiée, un workflow d'approbation ou des exceptions par bloc. Le schéma strict rejette les champs de liaison inconnus. Utilisez des organisations/déploiements séparés lorsqu'une posture différente par workspace est exigée, jusqu'à la livraison d'un contrat de liaison autorisé de première classe.