Sécurité
Sécurité
Section intitulée « Sécurité »La sécurité est au coeur de l’architecture de Deployme.cloud. Chaque couche de la plateforme est conçue pour minimiser les risques.
Authentification
Section intitulée « Authentification »Zitadel (OIDC)
Section intitulée « Zitadel (OIDC) »L’authentification est gérée par Zitadel, une solution OIDC open-source (Suisse), self-hosted sur notre infrastructure française.
- Support OIDC / OAuth 2.0 standard
- Multi-factor authentication (MFA) disponible
- SSO pour les plans Pro et Enterprise
- Gestion fine des rôles et permissions
API Tokens
Section intitulée « API Tokens »Les tokens API suivent le principe du moindre privilège :
- Tokens scoped par organisation, projet ou cluster
- Permissions granulaires (read, write, admin)
- Expiration configurable
- Révocation immédiate possible
# Créer un token read-only pour un cluster spécifiquedeployme token create \ --name "ci-readonly" \ --scope cluster:mon-cluster \ --permissions read \ --expires 30dChiffrement
Section intitulée « Chiffrement »En transit
Section intitulée « En transit »- TLS 1.3 sur toutes les communications externes
- mTLS (mutual TLS) entre l’agent on-premise et le control plane
- Certificats gérés automatiquement via Caddy (Let’s Encrypt)
Au repos
Section intitulée « Au repos »- Chiffrement des secrets et tokens en base de données
- Les kubeconfigs sont chiffrés avant stockage
- Les machine configurations Talos contiennent des secrets chiffrés
Isolation
Section intitulée « Isolation »Isolation des clusters
Section intitulée « Isolation des clusters »Chaque cluster déployé est entièrement isolé :
- Réseau dédié (pas de réseau partagé entre clusters)
- Secrets et certificats uniques par cluster
- Aucun accès croisé entre les clusters de différents utilisateurs
Isolation de l’infrastructure
Section intitulée « Isolation de l’infrastructure »Utilisateur A Utilisateur B┌────────────────┐ ┌────────────────┐│ Cluster 1 │ │ Cluster 3 ││ ┌──────────┐ │ │ ┌──────────┐ ││ │ CP + W │ │ │ │ CP + W │ ││ └──────────┘ │ │ └──────────┘ ││ │ │ ││ Cluster 2 │ └────────────────┘│ ┌──────────┐ ││ │ CP + W │ ││ └──────────┘ │└────────────────┘ ╳ Aucun accès croisé ╳Agent on-premise
Section intitulée « Agent on-premise »L’agent installé sur votre infrastructure (Phase 1+) est conçu avec la sécurité en priorité :
- Binaire Go unique — pas de dépendances, pas de runtime
- Communication sortante uniquement — l’agent initie la connexion, aucun port entrant requis
- mTLS — authentification mutuelle avec le control plane
- Open-source — code auditable par tous
- Permissions minimales — l’agent n’a accès qu’aux API de virtualisation nécessaires
Talos Linux — Sécurité par design
Section intitulée « Talos Linux — Sécurité par design »Le choix de Talos Linux apporte des garanties de sécurité intrinsèques :
- Pas de SSH — aucun vecteur d’attaque par accès shell
- OS immuable — impossible de modifier le système de fichiers root
- Pas de package manager — impossible d’installer des logiciels non autorisés
- API-only — toute action est tracée et auditable
- Secure boot supporté
Bonnes pratiques
Section intitulée « Bonnes pratiques »- Activez le MFA sur votre compte Deployme.cloud
- Utilisez des tokens scoped plutôt qu’un token global
- Renouvelez régulièrement vos tokens API
- Surveillez les logs d’audit disponibles dans le Manager
- Créez un compte de service dédié pour l’agent on-premise
- Maintenez vos clusters à jour — les mises à jour Talos incluent des correctifs de sécurité