Policy as code (GitOps)

Exportez la gouvernance de votre tenant en bundle JSON déclaratif, prévisualisez les changements façon plan, et appliquez-les depuis la CI.

La gouvernance d'un tenant (accès conditionnel, politique de risque, règles de mot de passe, rôles personnalisés) s'exporte en un seul document JSON déclaratif, se compare à une version candidate, et s'applique. Combiné aux jetons d'API, cela donne une boucle GitOps complète : la configuration vit dans Git, la CI montre le plan à chaque pull request, et la fusion l'applique. Les trois endpoints exigent la permission tenant:manage.

Le bundle de configuration

Le bundle est versionné (version: 1) et contient exactement cinq ressources :

{
  "version": 1,
  "accessPolicy": {
    "rules": [
      {"name": "Réseau du bureau", "networks": ["203.0.113.0/24"], "action": "allow", "enabled": true}
    ],
    "defaultAction": "mfa"
  },
  "riskPolicy": {"enabled": true, "mfaThreshold": 40, "denyThreshold": 80},
  "passwordPolicy": {"minLength": 12, "rejectBreached": true, "rejectContextual": true,
    "requireLower": false, "requireUpper": false, "requireDigit": false, "requireSymbol": false,
    "historyCount": 5, "maxAgeDays": 0},
  "groupPasswordPolicies": [],
  "roles": [
    {"key": "support", "name": "Support", "permissions": ["users:view", "audit:view"]}
  ]
}

Exporter la configuration courante

GET /v1/admin/config sérialise la configuration en vigueur. C'est le fichier que vous versionnez :

curl -s https://accounts.obexal.com/v1/admin/config \
  -H "Authorization: Bearer $OBX_TOKEN" > tenant-config.json

Plan : prévisualiser le diff

POST /v1/admin/config/plan compare la configuration courante à votre bundle candidat et renvoie les changements, dans l'esprit de terraform plan. Rien n'est modifié :

curl -s -X POST https://accounts.obexal.com/v1/admin/config/plan \
  -H "Authorization: Bearer $OBX_TOKEN" \
  -H "Content-Type: application/json" \
  --data @tenant-config.json

{
  "changes": [
    {"resource": "accessPolicy", "action": "update"},
    {"resource": "role:support", "action": "create"},
    {"resource": "role:legacy-ops", "action": "delete"}
  ],
  "hasChanges": true
}

Les ressources sont nommées accessPolicy, riskPolicy, passwordPolicy, groupPasswordPolicy:<groupId> et role:<clé> ; les actions sont create, update et delete.

Appliquer, avec les mêmes garde-fous

POST /v1/admin/config/apply applique le bundle et renvoie le plan exécuté. Il réutilise les validations des endpoints interactifs : l'automatisation ne peut rien faire que la console interdit.

• La politique d'accès passe par la validation anti-verrouillage.
• Les rôles passent par la validation des permissions et l'anti-escalade : un rôle du bundle accordant une permission que vous ne détenez pas vous-même est refusé avec 403.
• Par défaut, l'apply est non destructif : les changements delete sont signalés dans le plan mais ignorés.
• Avec ?prune=true, les rôles et dérogations de groupe absents du bundle sont réellement supprimés (réconciliation destructive).

Chaque changement appliqué est inscrit au journal d'audit.

Une boucle GitOps en trois appels

# 1) Exporter la production et la versionner
curl -s https://accounts.obexal.com/v1/admin/config \
  -H "Authorization: Bearer $OBX_TOKEN" > tenant-config.json
# git add tenant-config.json && git commit

# 2) En CI, à chaque pull request : afficher le plan
curl -s -X POST https://accounts.obexal.com/v1/admin/config/plan \
  -H "Authorization: Bearer $OBX_TOKEN" -H "Content-Type: application/json" \
  --data @tenant-config.json
# {"changes":[{"resource":"role:support","action":"create"}],"hasChanges":true}

# 3) À la fusion : appliquer (prune supprime ce que le fichier ne déclare plus)
curl -s -X POST "https://accounts.obexal.com/v1/admin/config/apply?prune=true" \
  -H "Authorization: Bearer $OBX_TOKEN" -H "Content-Type: application/json" \
  --data @tenant-config.json

Ce que le bundle ne couvre pas

Le bundle, c'est la gouvernance par politique, rien d'autre. Il exclut volontairement :

• Les applications (clients OIDC et SAML) et leurs secrets.
• L'annuaire : utilisateurs, groupes, appartenances, invitations. Les dérogations par groupe référencent des groupes existants par groupId ; le bundle ne crée jamais de groupe.
• Les domaines personnalisés : la propriété repose sur un handshake DNS, qui n'est pas déclaratif. Voir Domaines personnalisés.
• La marque et le logo, gérés par leurs propres endpoints. Voir Marque.
• Les webhooks, connexions SAML, LDAP et sociales, SCIM et jetons d'API : ils portent des secrets, qui ne sont jamais exportés.

Si une ressource n'est pas dans les cinq champs ci-dessus, apply n'y touchera pas.