KMS Agent est un proxy HTTP côté client qui centralise la récupération des secrets pour vos applications. Au lieu d'intégrer le SDK KMS dans chaque application, celles-ci envoient des requêtes HTTP locales à l'agent, qui gère l'authentification, la mise en cache et la communication avec KMS en leur nom.
Fonctionnement
L'agent met en cache les valeurs des secrets en mémoire et les actualise périodiquement selon la durée de vie (TTL) configurée. Lorsqu'une application demande un secret :
L'agent valide la requête à l'aide d'un fichier de jeton SSRF (Server-Side Request Forgery).
Si une valeur mise en cache valide existe et n'a pas expiré, l'agent la renvoie immédiatement (succès du cache).
S'il n'existe aucune entrée de cache valide, l'agent transfère la requête à KMS. KMS vérifie l'identité de l'agent, déchiffre le secret et le renvoie. L'agent met à jour le cache et retourne la valeur à l'application (échec du cache).
Les diagrammes suivants illustrent ces deux flux :
Processus en cas de succès du cache
Processus en cas d'échec du cache (absence de cache ou cache expiré)
Les valeurs des secrets mises en cache sont stockées en clair en mémoire. Protégez-les en appliquant des autorisations d'accès appropriées au processus de l'agent, en activant des mécanismes de protection de la mémoire et en déployant des outils de détection des fuites de mémoire.
Déployez l'agent aux côtés de vos applications sur des serveurs physiques, des machines virtuelles telles qu'Elastic Compute Service (ECS) ou des conteneurs tels que des pods Kubernetes. Pour le code source et les guides de déploiement, consultez alibabacloud-kms-agent.
Architecture
L'agent comprend quatre composants : serveur HTTP, cache, client KMS et journalisation.
Configurez les quatre composants dans un seul fichier de configuration. Le fichier ci-dessous présente toutes les options disponibles et leurs valeurs par défaut :
# All configuration items
[Server]
# Optional, default value is 2025. Agent listens on 127.0.0.1:2025.
HttpPort = 2025
# Optional, default value is ["X-KMS-Token", "X-Vault-Token"].
# Requests to the agent must include an SSRF header; requests without one are rejected.
SSRFHeaders = ["X-KMS-Token"]
# Optional, default value is ["KMS_TOKEN", "KMS_SESSION_TOKEN", "KMS_CONTAINER_AUTHORIZATION_TOKEN"].
# The value can be a literal string or a file path, such as file:///var/run/awssmatoken.
# The agent reads the SSRF token from the specified environment variable and compares it
# against the token in the application's request header. Access is granted only on a match.
SSRFEnvVariables = ["KMS_TOKEN"]
# Optional, default value is "/v1/". URI prefix for path-based requests.
PathPrefix = "/v1/"
# Optional, default value is 800. Maximum number of concurrent requests.
MaxConn = 800
# Optional, default value is 0.
# 0: KMS GetSecretValue response format
# 1: AWS Secrets Manager GetSecretValue response format
# 2: HashiCorp Vault KV structure
ResponseType = 0
# Optional, default value is true.
# When true, the agent returns expired cached values if KMS is temporarily unreachable.
IgnoreTransientErrors = true
[Kms]
# Optional, default value is cn-hangzhou.
Region = "cn-hangzhou"
# Optional, default value is kms.cn-hangzhou.aliyuncs.com.
# Accepts both shared and dedicated gateway endpoints.
Endpoint = "kms.cn-hangzhou.aliyuncs.com"
[Cache]
# Optional, default value is InMemory. Only in-memory caching is currently supported.
CacheType = "InMemory"
# Optional, default value is 1000. When set to 0, caching is disabled and every
# request goes directly to KMS.
CacheSize = 1000
# Optional, default value is 300s.
TtlSeconds = 300
# Optional, default value is false.
# false: evicts the oldest cached secret when the cache is full.
# true: evicts the least recently used secret (LRU) based on access frequency.
EnableLRU = false
[Log]
# Optional, default value is Debug.
LogLevel = "Debug"
# Optional, default value is ./logs/ relative to the application startup directory.
LogPath = "./logs/"
# Optional, default value is 100 (MB). Maximum size per log file.
MaxSize = 100
# Optional, default value is 2. Number of log files to retain.
MaxBackups = 2
Serveur HTTP
Le serveur HTTP gère les requêtes des applications pour la récupération des secrets. Par défaut, les réponses utilisent le format KMS GetSecretValue. Définissez ResponseType pour renvoyer plutôt les formats AWS Secrets Manager ou HashiCorp Vault KV.
Formats de requête pris en charge :
-
Basé sur le chemin :
GET /v1/<secret-name> -
Basé sur la requête :
GET /secretsmanager/get?secretId=<secret-name>
Exemple de requête avec curl (lit le jeton SSRF depuis un fichier) :
curl -s \
-H "X-KMS-Token: $(cat /var/run/kmstoken)" \
"http://127.0.0.1:2025/v1/<secret-name>"
Exemple de requête avec Python :
with open("/var/run/kmstoken") as f:
token = f.read().strip()
headers = {"X-KMS-Token": token}
response = requests.get("http://127.0.0.1:2025/v1/<secret-name>", headers=headers)
print(response.json())
Remplacez <secret-name> par le nom du secret à récupérer.
Formats de réponse pris en charge :
L'agent est compatible avec les formats de réponse AWS Secrets Manager et HashiCorp Vault KV. Si votre code intègre déjà Spring Vault, modifiez le point d'accès vers l'adresse de KMS Agent et adaptez la configuration via l'agent pour basculer rapidement vers la plateforme Alibaba Cloud.
-
Alibaba Cloud KMS (par défaut,
ResponseType=0) :{ "CreateTime": "2025-01-03T07:59:17Z", "RequestId": "cc315250-04c9-4caf-a055-6648f36598b9", "SecretData": "{\"k3\":\"v3\"}", "SecretDataType": "text", "SecretName": "agent-test", "SecretType": "Generic", "VersionId": "v2", "VersionStages": { "VersionStage": [ "ACSCurrent" ] } } -
AWS Secrets Manager (
ResponseType=1) :{ "ARN": "", "Name": "agent-test", "VersionId": "v2", "SecretString": "{\"k3\":\"v3\"}", "VersionStages": [ "ACSCurrent" ], "CreatedDate": "2025-01-03T07:59:17Z" } -
HashiCorp Vault (
ResponseType=2) :{ "data": { "k3": "v3" } }
Cache
L'agent met en cache les valeurs des secrets en mémoire, ce qui réduit le nombre de requêtes envoyées à KMS. Configurez la TTL du cache, sa taille et sa politique d'éviction pour les adapter à vos modèles d'accès et à votre calendrier de rotation des secrets.
|
Paramètre |
Description |
Valeur par défaut |
|
|
Backend de cache. Seul |
|
|
|
Nombre maximal de secrets à mettre en cache. Définissez sur |
|
|
|
Durée de validité d'une valeur mise en cache, en secondes. |
|
|
|
Politique d'éviction lorsque le cache est plein. |
|
Client KMS
Le client KMS connecte l'agent à KMS. Définissez Region et Endpoint pour correspondre à votre déploiement KMS. Les points de terminaison de passerelle partagés et dédiés sont pris en charge.
Lors de l'utilisation d'un point de terminaison de passerelle dédié, l'agent inclut des certificats CA intégrés pour toutes les régions ; aucune configuration supplémentaire de certificat n'est requise.
Journalisation
L'agent utilise le framework de journalisation Zap pour émettre des journaux JSON structurés. Configurez le niveau de journalisation, la limite de taille des fichiers et le nombre de rétention pour répondre à vos exigences opérationnelles.
Sécurité
Authentification et autorisation
Authentification de l'agent auprès de KMS
L'agent utilise la chaîne de fournisseurs d'identifiants par défaut d'Alibaba Cloud, qui vérifie les sources suivantes dans l'ordre : variables d'environnement, rôle RAM OIDC IdP, config.json, rôle RAM ECS et URI d'identifiant, sauf si une méthode d'initialisation spécifique est fournie dans credentials.NewDefaultCredentialsProvider().
Accordez à l'agent uniquement les autorisations nécessaires pour récupérer et déchiffrer les secrets. Suivez le principe du moindre privilège lors de la configuration des politiques RAM.
Authentification des applications auprès de l'agent
L'agent génère un fichier de jeton SSRF (par exemple, /var/run/kmstoken) au démarrage. Les applications doivent inclure ce jeton dans leurs en-têtes de requête. Les requêtes sans jeton valide sont rejetées.
L'accès au fichier de jeton est restreint par défaut :
Linux : Seul le processus de l'agent et l'utilisateur OS de l'application peuvent lire le fichier de jeton.
Conteneur sidecar : L'accès au fichier de jeton est limité au pod.
Sécurité des communications
Agent vers KMS : Tout le trafic utilise Transport Layer Security (TLS). Pour une isolation plus forte, utilisez un point de terminaison de passerelle dédié ; le trafic reste dans votre VPC et n'est pas exposé à l'Internet public.
Agent vers application : L'agent écoute uniquement sur
127.0.0.1, limitant l'accès à la machine locale.
Audit et journalisation
Toutes les opérations de récupération de secrets sont journalisées au format JSON à l'aide du framework Zap. Les journaux sont configurables en termes de taille de fichier et de nombre de rétention, fournissant un registre auditable de l'activité de l'agent.
Stabilité
L'agent est conçu pour rester disponible lors de perturbations réseau et de pannes transitoires.
Auto-vérification au démarrage : Au démarrage, l'agent vérifie la connectivité à KMS. Si la vérification échoue, l'agent s'arrête plutôt que de démarrer dans un état dégradé.
Nouvelle tentative automatique : L'agent utilise la logique de nouvelle tentative intégrée au SDK Alibaba Cloud (V2). Pour les réponses HTTP 429 (limitation de débit) et HTTP 500 (erreur interne du serveur), il effectue 3 nouvelles tentatives en utilisant une méthode de backoff exponentiel pour les intervalles de temps.
Repli sur cache obsolète : Lorsque IgnoreTransientErrors est activé (par défaut), l'agent renvoie la valeur mise en cache la plus récente si KMS est temporairement inaccessible. Cela permet d'éviter les pannes d'application lors de problèmes réseau ou serveur de courte durée.
Haute disponibilité :
Linux (systemd) :
systemdsurveille le processus de l'agent et le redémarre automatiquement en cas de plantage.Kubernetes (conteneur sidecar) : Déployé en tant que conteneur d'initialisation, l'échec de l'agent déclenchera un redémarrage du conteneur, garantissant la stabilité de l'application.
KMS Agent vs Secret Client
KMS Agent agit comme une couche intermédiaire : les applications accèdent aux secrets via l'agent plutôt que d'appeler directement KMS. Secret Client intègre le SDK KMS dans chaque application. Choisissez en fonction de l'échelle de votre déploiement et de vos exigences de contrôle d'accès.
|
Aspect |
KMS Agent |
Secret Client |
|
Recommandé pour |
Entreprises disposant de plusieurs applications et de langages de programmation divers nécessitant un contrôle d'accès centralisé |
Applications uniques ou petits déploiements avec des exigences de contrôle d'accès simples |
|
Déploiement |
Processus indépendant, découplé des applications |
Bibliothèque intégrée au code de l'application |
|
Complexité d'intégration |
Faible |
Élevée |
|
Contrôle d'accès |
Centralisé : appliqué en un point unique pour toutes les applications |
Décentralisé : chaque application gère ses propres politiques |
|
Prise en charge des langages |
Tout langage (interface HTTP) |
Java 8+, Python et Go |
|
Performances |
Le cache en mémoire minimise la latence et la limitation de débit KMS dans les scénarios à haute fréquence |
L'accès à haute fréquence peut déclencher la limitation de débit KMS |
|
Rotation des secrets |
Mis en cache avec une TTL configurable ; actualisé automatiquement depuis KMS à l'expiration |
Récupéré automatiquement à l'aide d'un mécanisme d'actualisation et d'une logique de nouvelle tentative |
|
Maintenance |
Faible : une seule configuration pour toutes les applications |
Élevée : configuration distincte par application |