Configuration du Cockpit (appsettings)

L'hôte Cockpit est configuré via appsettings.json (DUOKEY.ADMIN.Web.Host/appsettings.json). Cette page décrit les paramètres que vous devez renseigner pour un déploiement sur site.

Ne jamais valider de vrais secrets

Toutes les valeurs présentées ici sont des valeurs fictives. Les secrets (chaînes de connexion, codes de licence, secrets d'API, secrets client, jetons) ne doivent jamais être codés en dur ni validés dans Git. Dans le déploiement de référence, ils portent la sentinelle set_as_keyvault_secret et sont résolus à l'exécution depuis votre magasin de secrets — voir Sourcing des secrets ci-dessous et Intégration du gestionnaire de secrets.

Comment cela s'applique — stocké dans OpenBao, injecté au déploiement

Le fichier appsettings.json du Cockpit est stocké dans OpenBao (votre moteur de secrets) et injecté au moment du déploiement — jamais intégré dans l'image ni validé dans Git. Au déploiement, l'External Secrets Operator le matérialise depuis OpenBao dans un Secret Kubernetes en mémoire (tmpfs), qui est monté sous forme de fichier appsettings.json dans le pod Cockpit. Mettez à jour la valeur dans OpenBao et redéployez pour déployer un changement de configuration. Voir Sourcing des secrets.

Sourcing des secrets

Sur site, l'intégralité du fichier appsettings.json est conservée dans OpenBao et injectée au déploiement, de sorte que les valeurs des secrets ne résident que dans votre moteur de secrets.

Comment cela fonctionne :

Le fichier appsettings.json complet et spécifique à l'environnement (avec les véritables valeurs de secret à la place de chaque valeur fictive set_as_keyvault_secret) est stocké en tant que secret dans OpenBao.
Au déploiement, l'External Secrets Operator le récupère et matérialise un Secret Kubernetes en mémoire (tmpfs).
Ce Secret est monté sous forme de fichier appsettings.json dans le pod Cockpit.
Pour modifier la configuration : mettez à jour la valeur dans OpenBao et redéployez — rien n'est modifié à l'intérieur de l'image ni stocké dans Git.

Azure Key Vault n'est pas nécessaire sur site

La build de référence peut également résoudre les secrets depuis Azure Key Vault (Configuration:AzureKeyVault) pour les déploiements connectés/cloud. Pour le sur site, laissez-le désactivé — OpenBao est la source de vérité.

"Configuration": { "AzureKeyVault": { "IsEnabled": "false" } }

1. Base de données

Choisissez le fournisseur et la chaîne de connexion. Voir Double fournisseur de base de données pour les détails.

{
  "ConnectionStrings": {
    "Default": "set_as_keyvault_secret"
  },
  "DatabaseProvider": "PostgreSQL"
}

DatabaseProvider : "SqlServer" (par défaut) ou "PostgreSQL".
Le format de la chaîne de connexion dépend du fournisseur (exemples ci-dessous).

2. Cache Redis

"Abp": {
  "RedisCache": {
    "ConnectionString": "<redis-host>:6379",
    "DatabaseId": -1
  }
}

Pointez ceci vers votre service Redis dans le cluster ou vos VM Redis.

3. URL de l'application et CORS

Définissez celles-ci sur vos noms d'hôte (voir Enregistrements DNS).

"App": {
  "ServerRootAddress": "https://cockpit-api.example.com/",
  "ClientRootAddress": "https://cockpit.example.com/",
  "CorsOrigins": "https://cockpit.example.com",
  "SwaggerEndPoint": "/swagger/v1/swagger.json",
  "HomePageUrl": "/index.html"
}

ServerRootAddress / ClientRootAddress : les URL de base de l'API et de l'UI.
CorsOrigins : liste d'origines autorisées séparées par des virgules — gardez-la restrictive.

4. Authentification et SSO

Activez les fournisseurs que vous utilisez et pointez-les vers votre IdP. Guide complet dans Identité, SSO et contrôle d'accès.

"Authentication": {
  "OpenId": {
    "IsEnabled": "true",
    "ClientId": "<entra-app-client-id>",
    "Authority": "https://login.microsoftonline.com/<entra-tenant-id>/v2.0",
    "LoginUrl": "https://login.microsoftonline.com/<entra-tenant-id>/oauth2/v2.0/authorize",
    "TokenEndpoint": "https://login.microsoftonline.com/<entra-tenant-id>/oauth2/v2.0/token",
    "ValidateIssuer": "true",
    "ResponseType": "id_token",
    "ClaimsMapping": [
      { "claim": "unique_name", "key": "preferred_username" }
    ]
  },
  "Okta": {
    "IsEnabled": "false",
    "ClientId": "set_as_keyvault_secret",
    "ClientSecret": "set_as_keyvault_secret",
    "Authority": "https://<your-org>.okta.com",
    "ValidateIssuer": "true"
  },
  "JwtBearer": {
    "IsEnabled": "true",
    "SecurityKey": "set_as_keyvault_secret",
    "Issuer": "ADMIN",
    "Audience": "ADMIN"
  }
}

Les connexions sociales (Facebook, Twitter, Google, Microsoft grand public) sont désactivées par défaut — laissez-les désactivées sauf si nécessaire.

5. IdentityServer

"IdentityServer": {
  "IsEnabled": "true",
  "Authority": "https://cockpit-api.example.com/",
  "ApiName": "default-api",
  "ApiSecret": "set_as_keyvault_secret",
  "AccessTokenExpirationDays": 1,
  "RefreshTokenExpirationDays": 365
}

Le certificat de signature d'IdentityServer est fourni séparément :

"IdentityServerCert": {
  "Password": "set_as_keyvault_secret",
  "Path": "/var/ssl/certs/",
  "Name": "certificate.pfx"
}

6. HSM — Securosys CloudsHSM

Pour une garde des clés adossée au matériel, configurez l'intégration Securosys CloudsHSM (voir Intégration du gestionnaire de secrets) :

"SecurosysCloudsHSM": {
  "HostName": "https://<securosys-host>/v1/key/{0}/export/plain",
  "TLSClientCert": "set_as_keyvault_secret",
  "TLSClientPrivateKey": "set_as_keyvault_secret",
  "AzureADCredentials": {
    "ClientId": "set_as_keyvault_secret",
    "ClientSecret": "set_as_keyvault_secret",
    "TenantId": "set_as_keyvault_secret"
  }
}

7. Journalisation / SIEM

Transférez les journaux vers votre SIEM (voir Conformité et audit). La build de référence fournit un sink Splunk HEC :

"SplunkLogSetting": {
  "Token": "set_as_keyvault_secret",
  "Url": "https://<your-splunk-host>:8088/services/collector"
}

8. DKE 365 — Microsoft Graph

Pour l'intégration DKE 365, fournissez une inscription d'application Microsoft Graph :

"AzureGraphAppSettings": {
  "ClientId": "set_as_keyvault_secret",
  "ClientSecret": "set_as_keyvault_secret",
  "TenantId": "set_as_keyvault_secret"
}

Voir Résolution des problèmes DKE pour les vérifications associées du point de terminaison de clé et d'Entra ID.

9. HTTPS et limitation de débit

"HttpsRedirection": {
  "IsEnabled": true,
  "HttpsPort": 443,
  "RedirectStatusCode": 301
},
"IpRateLimiting": {
  "EnableEndpointRateLimiting": true,
  "GeneralRules": [
    { "Endpoint": "*", "Period": "10s", "Limit": 10 },
    { "Endpoint": "*", "Period": "10m", "Limit": 100 }
  ]
}

10. Provisionnement de services GitOps (GitLab → ArgoCD → Helm)

Au-delà de l'hébergement de sa propre configuration, le Cockpit agit comme un plan de contrôle pour les instances de service DuoKey (DKE 365, AWS XKS, Genesys LKM, Pass-Kit). Lorsqu'un administrateur crée ou met à jour un service depuis le Cockpit, il ne déploie pas directement — il valide les valeurs Helm du service et le manifeste d'application ArgoCD dans un dépôt GitLab. ArgoCD surveille en continu ce dépôt et déploie ou met à jour automatiquement le service dans le cluster via son chart Helm.

C'est le même modèle GitOps utilisé pour la plateforme elle-même (Installation → Amorcer GitOps) : le provisionnement de service devient déclaratif, versionné et auditable — chaque instance de service est un commit Git, déployée par ArgoCD via Helm.

Paramètres pertinents (nettoyés)

GitlabClientRepository — comment le Cockpit communique avec GitLab et ArgoCD :

"GitlabClientRepository": {
  "ApiHostUrl": "https://<gitlab-host>/api/v4/",
  "Url": "https://<gitlab-host>/<group>/",
  "ProjectID": "set_as_keyvault_secret",
  "Branch": "staging",
  "PatToken": "set_as_keyvault_secret",
  "ArgoToken": "set_as_keyvault_secret",
  "DKEAppURL": "https://<argocd-host>/api/v1/applications/{0}?cascade=true&propagationPolicy=Foreground",
  "DKEDomain": "https://{app.Externalid}.<service-domain>"
}

GitlabAppYMLFile / GitLabYAMLAppFolder — le modèle d'application ArgoCD et les chemins d'application par service :

"GitlabAppYMLFile": {
  "RepoURL": "git@<gitlab-host>:<group>/dke-devops.git",
  "TargetRevision": "staging",
  "Server": "https://kubernetes.default.svc",
  "Namespace": "default",
  "Project": "default"
}

GitLabYAMLValuesFolder — les chemins des valeurs de chart Helm et les dépôts d'images par service :

"GitLabYAMLValuesFolder": {
  "DKEDockerRepoURL": "<registry-host>/dke-apps-dke365/dke-apps-dke365:<tag>",
  "DKE365RootPath": "dke365-service/chart/values"
}

Pour le sur site

Pointez ceux-ci vers votre environnement :

GitLab (<gitlab-host>, groupe, dépôt dke-devops) — GitLab auto-hébergé, ou GitLab SaaS lorsque la politique le permet.
ArgoCD (<argocd-host>) — l'instance OpenShift GitOps dans le cluster.
Registre (<registry-host>) — votre Harbor / miroir (voir Images de conteneur).
Jetons (PatToken, ArgoToken, ProjectID) — stockés dans OpenBao, injectés au déploiement.

Nécessite GitLab + ArgoCD + registre

Ce flux de provisionnement nécessite un dépôt GitLab accessible, une instance ArgoCD et un registre d'images. Sur un site isolé (air-gapped), les trois s'exécutent sur site. Votre représentant DuoKey provisionne la structure du dépôt et les jetons lors de l'intégration.

Paramètres que vous pouvez généralement laisser tels quels

D'autres blocs dans le fichier appsettings.json de référence sont facultatifs ou spécifiques à un scénario : les fournisseurs de paiement (Payment), Twilio, Recaptcha et tout PkiIssuerEnvironments spécifique au client. Laissez-les à leurs valeurs par défaut / désactivés sauf si nécessaire — votre représentant DuoKey confirme lesquels s'appliquent à vous.

Double fournisseur de base de données

L'application prend en charge SQL Server et PostgreSQL, sélectionnés par DatabaseProvider.

Exemples de chaînes de connexion

SQL Server

{
  "ConnectionStrings": {
    "Default": "Server=<host>;Database=ADMINDb;Trusted_Connection=True;TrustServerCertificate=True;"
  },
  "DatabaseProvider": "SqlServer"
}

PostgreSQL

{
  "ConnectionStrings": {
    "Default": "User ID=postgres;Password=<password>;Host=<host>;Port=5432;Database=ADMINDb;Pooling=true;"
  },
  "DatabaseProvider": "PostgreSQL"
}

Comportement spécifique au fournisseur

PostgreSQL : définit automatiquement Npgsql.DisableDateTimeInfinityConversions sur true ; les limites de longueur de chaîne sont gérées automatiquement (max 10 Mo). Toutes les fonctionnalités sont identiques.
SQL Server : aucun changement de comportement ; compatibilité descendante complète.

Exécution des migrations

Les migrations sont appliquées par le Migrator sur votre base de données cible. Le fournisseur et la chaîne de connexion sont lus depuis la même configuration.

cd src/DUOKEY.ADMIN.Migrator
dotnet run

Dans un déploiement sur site conteneurisé, exécutez le Migrator en tant que Job ponctuel (ou init container) pointé vers votre base de données avant de démarrer l'hôte Cockpit.

remarque

La création de nouveaux scripts de migration est un processus de développement interne à DuoKey et n'est pas nécessaire pour exploiter un déploiement sur site — vous ne faites qu'exécuter le Migrator.

Stratégie de migration pour les clients existants

Clients SQL Server : aucune action requise — SQL Server est le fournisseur par défaut et les configurations existantes continuent de fonctionner sans temps d'arrêt.
PostgreSQL : définissez "DatabaseProvider": "PostgreSQL", pointez la chaîne de connexion vers votre instance PostgreSQL, exécutez le Migrator et validez les fonctionnalités.

Résolution des problèmes

Symptôme	Cause	Résolution
L'application ne démarre pas, erreur de BD	Mauvais fournisseur ou chaîne de connexion	Vérifiez que `DatabaseProvider` correspond au format de la chaîne de connexion
Boucle de redirection d'authentification / 401	Incompatibilité autorité/client de l'IdP	Revérifiez l'autorité `Authentication:OpenId`, l'ID client, `ValidateIssuer`
Valeur de secret littéralement `set_as_keyvault_secret`	Magasin de secrets non câblé	Confirmez qu'OpenBao/ESO (ou Key Vault) injecte la valeur à l'exécution
Erreurs CORS dans l'UI	Origine non autorisée	Ajoutez l'origine de l'UI à `App:CorsOrigins`
Erreurs de migration	BD cible manquante/inaccessible	Assurez-vous que la base de données existe et est accessible depuis le Migrator

Sourcing des secrets​

1. Base de données​

2. Cache Redis​

3. URL de l'application et CORS​

4. Authentification et SSO​

5. IdentityServer​

6. HSM — Securosys CloudsHSM​

7. Journalisation / SIEM​

8. DKE 365 — Microsoft Graph​

9. HTTPS et limitation de débit​

10. Provisionnement de services GitOps (GitLab → ArgoCD → Helm)​

Paramètres pertinents (nettoyés)​

Pour le sur site​

Double fournisseur de base de données​

Exemples de chaînes de connexion​

Comportement spécifique au fournisseur​

Exécution des migrations​

Stratégie de migration pour les clients existants​

Résolution des problèmes​