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

Docker et Podman utilisent toujours le port 80 dans le conteneur ; publiez le port hôte avec -p 8088:80. PORT concerne uniquement les binaires autonomes (8088 par défaut). 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:80 \
  --user 10001:10001 \
  -v "$PWD/dat-cms-data:/data" \
  -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:4.7.1

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

Gardez le port du conteneur, les probes et le targetPort du Service à 80. Modifiez le port accessible via le port du Service. Accordez NET_BIND_SERVICE pour écouter sur 80 sans root. Montez un répertoire accessible en écriture et injectez les tokens et identifiants de base de données via Secrets.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  runAsGroup: 10001
containers:
  - name: dat-cms
    image: sarolab/dat-cms:4.7.1
    securityContext:
      capabilities:
        drop: ["ALL"]
        add: ["NET_BIND_SERVICE"]
    ports: [{ containerPort: 80 }]
    readinessProbe: { httpGet: { path: /health, port: 80 } }
    livenessProbe: { httpGet: { path: /health, port: 80 } }