DAT CMS

DAT CMS crée les certificats, les stocke dans une base de données et fournit les certificats appropriés aux services d’émission et de vérification. Le comportement du protocole est décrit dans la spécification DAT CMS.

Créer une configuration de runtime

Exécuter avec Docker

Exécutez le conteneur avec un utilisateur non-root. Avec SQLite, montez un répertoire de données accessible en écriture. Transmettez les tokens et mots de passe de base de données par un mécanisme d’injection de secrets plutôt que par l’historique des commandes.

docker run --rm --name dat-cms -p 8088:8088 \
  --user 10001:10001 \
  -v "$PWD/dat-cms-data:/data" \
  -e PORT=8088 \
  -e DB_URI='sqlite:/data/data.db' \
  -e TOKEN_MASTER='replace-with-a-secret' \
  -e TOKEN_CERT_FULL='replace-with-a-secret' \
  -e TOKEN_CERT_VERIFY='replace-with-a-secret' \
  sarolab/dat-cms

Base de données

Utilisez DB_URI pour configurer une connexion SQLite, PostgreSQL ou MySQL. MariaDB se connecte via le protocole MySQL. Le CMS met les résultats des requêtes de certificats en cache sous forme de snapshot et continue à servir le dernier snapshot réussi lorsqu’une actualisation du stockage échoue temporairement.

DB_CACHE_SECS définit l’intervalle d’actualisation du snapshot, tandis que DB_QUERY_TIMEOUT_SECS limite les requêtes d’actualisation. Si aucun snapshot réussi n’existe et que le stockage est illisible, le service renvoie DAT_STORE_UNAVAILABLE.

Rôles d’accès

Chaque variable accepte des tokens alphanumériques séparés par des virgules. Si la liste de tokens d’un rôle est vide, les endpoints correspondants sont ouverts et un avertissement est consigné.

Génération des certificats

Le rôle master enregistre un certificat en indiquant l’algorithme de signature, l’algorithme de chiffrement, le délai de propagation, la période d’émission et le TTL. Pendant le délai de propagation, les services synchronisent le nouveau certificat avant qu’il puisse servir à l’émission.

Intégration du client

1. Utilisez le token complet et l’endpoint des certificats complets pour les services d’émission.
2. Utilisez le token de vérification et l’option verify-only pour les services de vérification.
3. Contrôlez le résultat de la première synchronisation ; si le démarrage doit échouer, appelez l’API de synchronisation immédiate.
4. Lorsque la synchronisation automatique est activée, fermez le gestionnaire à l’arrêt de l’application.

Consultez les guides des bibliothèques pour le builder et le comportement d’arrêt propres à chaque langage.

Contrôles d’exploitation

• /health et /version/api indiquent l’état sans authentification.
• /version exige le master token lorsque ce rôle est configuré.
• Collectez les journaux de la sortie standard et de l’erreur standard.
• Transmettez les signaux d’arrêt et laissez à la base de données et au scheduler le temps de se fermer.

Kubernetes

Faites correspondre le port du conteneur et les probes au port du service, puis montez le répertoire de données avec un accès en écriture pour l’utilisateur non-root. Injectez les tokens et les informations de connexion à la base de données au moyen de Secrets.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  runAsGroup: 10001
containers:
  - name: dat-cms
    image: sarolab/dat-cms
    ports: [{ containerPort: 8088 }]
    readinessProbe: { httpGet: { path: /health, port: 8088 } }
    livenessProbe: { httpGet: { path: /health, port: 8088 } }