Passer au contenu principal
Vantage 3.0 auto-hébergé lit toutes les chaînes de connexion aux bases de données, clés API et certificats TLS auprès d’un fournisseur de secrets au démarrage du pod ; aucune de ces valeurs n’est stockée dans les fichiers values.yaml. Deux fournisseurs sont pris en charge ; un seul est configuré pour chaque installation via vantage.secrets.

​
Fournisseurs pris en charge

Les deux providers reposent sur la même convention d’alias de secret. Les charges de travail Vantage recherchent les secrets par alias, quelle que soit l’origine des valeurs. Utilisez l’inventaire des alias ci-dessous pour planifier le provisionnement.

​
Fournisseur Azure Key Vault

​
Modes d’identité

​
Fonctionnement

Vantage utilise le Secrets Store CSI Driver avec le fournisseur Azure Key Vault. Le SecretProviderClass de chaque chart est monté sous forme de volume CSI dans le pod qui l’utilise, et ce montage déclenche la synchronisation des valeurs par le driver dans un Secret Kubernetes propre à chaque chart (fonctionnalité secretObjects du SPC), que le pod consomme via envFrom et des montages de volume. La chaîne est la suivante :
  1. L’opérateur génère un SecretProviderClass (SPC) par chart, en déclarant les alias Key Vault dont ce chart a besoin et la manière dont chacun est mis en correspondance avec une clé dans un Secret Kubernetes propre au chart.
  2. Lorsqu’un pod monte le volume du SPC, le Secrets Store CSI driver s’authentifie avec l’identité sélectionnée par identityMode, récupère les objets nommés depuis Key Vault et les synchronise dans un Secret Kubernetes propre au chart via la fonctionnalité secretObjects du SPC.
  3. Le pod du chart consomme le Secret propre au chart :
    • La plupart des secrets sont chargés comme variables d’environnement via envFrom.
    • Les certificats (authSigningTlsCrt, etc.) sont également montés sous forme de fichiers via volumeMounts (généralement sous /var/run/certs/).
Les valeurs des secrets apparaissent dans le Secret Kubernetes propre au chart et dans l’environnement du pod au runtime ; elles sont donc visibles avec kubectl get secret. Mais elles n’apparaissent jamais dans values.yaml, les diffs ArgoCD ou Git, car le CSI driver les renseigne au démarrage du pod. Le Secrets Store CSI driver et le plugin fournisseur Azure Key Vault doivent être installés dans le cluster avant Vantage. Voir Prérequis.

​
Ressources par chart

Chaque chart Vantage qui utilise des secrets dispose de son propre jeu de ressources : Cette répartition par chart permet de limiter au strict minimum les privilèges d’accès à Key Vault : le SPC d’un chart ne référence que les alias dont ce chart a réellement besoin.

​
Comptes de service et portée de l’identité

L’opérateur ne crée pas et n’annote pas les ressources ServiceAccount. Chaque chart apporte son propre SA via les valeurs Helm standard ; il incombe au client de fédérer les ServiceAccount de chaque chart qui montent les SPC avec l’identité managée attribuée par l’utilisateur (UAMI) dont le clientId est fourni dans vantage.secrets.azure.clientId. Cette identité doit disposer d’un accès en lecture aux objets Key Vault sur lesquels reposent les alias des charts.
L’accès à Key Vault et l’accès au pull d’images sont deux aspects distincts qui peuvent concerner les mêmes ServiceAccount. La fédération UAMI (cette page) accorde l’accès en lecture aux secrets ; elle n’authentifie pas les pulls d’images. Pour les pulls, ajoutez un secret de pull de registry dans imagePullSecrets du ServiceAccount nommé par vantage.serviceAccountName, ou accordez plutôt AcrPull à l’identité du kubelet AKS. Voir Accès au pull d’images.

​
Fournisseur de Secrets Kubernetes

Créez au préalable les ressources Secret dans l’espace de noms d’installation avant d’exécuter le chart. Si objects n’est pas défini, les noms de secret par défaut sont utilisés ; indiquez une mise en correspondance objects (secretName par alias) pour cibler des Secrets portant des noms différents. Ce provider ne nécessite ni Secrets Store CSI driver ni coffre de clés dans le cloud. Les valeurs sont lues directement à partir des objets Secret du cluster. Lors des vérifications préalables, l’operator valide la configuration des secrets. Les charts matched operator et Vantage installent un ClusterRole de lecture des Secrets et l’associent au ServiceAccount de l’operator, uniquement dans l’espace de noms de la release Vantage. Si vous limitez l’accès aux Secrets via resourceNames, incluez tous les noms de Secret, par défaut comme remplacés. Un système externe de gestion des secrets peut rester votre source de référence. Par exemple, External Secrets Operator peut matérialiser des Secrets Kubernetes à partir de HashiCorp Vault. Vantage consomme uniquement les Secrets Kubernetes ainsi obtenus et ne se connecte ni à External Secrets ni à Vault directement.

​
PostgreSQL et les Secrets par service

Définissez vantage.databaseProvider: PostgreSQL pour utiliser PostgreSQL. Chaque service doit recevoir une chaîne de connexion pointant vers une base de données logique distincte ; le partage d’une même base de données entraîne un conflit entre les états de migration des services. Certaines charges de travail lisent des clés de chaîne de connexion portant des noms uniques et peuvent partager un Secret. D’autres charges de travail lisent la clé générique Database__ConnectionString ; créez un Secret distinct pour chacun de ces services et mettez en correspondance son alias via vantage.secrets.kubernetes.objects :
Chaque Secret mis en correspondance contient la même clé, mais une chaîne de connexion de base de données différente :
Utilisez votre système de gestion des secrets pour créer ces Secrets sans versionner d’identifiants dans le contrôle de code source. Les chaînes de connexion doivent être sur une seule ligne, sans caractères de nouvelle ligne au début, à la fin ou au milieu. Le reporting est disponible uniquement avec SQL Server. Laissez reportingEnabled: false lorsque vous utilisez PostgreSQL.

​
Alias de secrets

Les alias suivants définissent le contrat entre les charges de travail Vantage et votre fournisseur de secrets. Avec le fournisseur Azure, la configuration la plus simple consiste à nommer vos secrets Key Vault de manière à ce qu’ils correspondent à l’alias. Avec l’un ou l’autre fournisseur, vous pouvez redéfinir la correspondance des noms via une mise en correspondance objects dans votre configuration des secrets.

​
Plateforme

​
Stockage

Obligatoire uniquement lors de l’utilisation du back-end de stockage Azure Blob par défaut. Lorsque spec.storage.custom est configuré pour un back-end reposant sur une StorageClass Kubernetes (par exemple, NFS), ces alias ne sont pas utilisés. Chaque alias correspond à une chaîne de connexion de compte de stockage ; consultez la documentation de base du système Vantage pour savoir à quoi sert chaque type de stockage.

​
Bases de données

Chaînes de connexion, à raison d’une par base de données distincte. Les noms de bases de données sont fournis à titre indicatif ; tout nom généré par votre processus de provisionnement convient, à condition que la chaîne de connexion pointe vers la base de données appropriée.

​
OAuth

† sendgridApiKey est obligatoire uniquement si vous n’utilisez pas SMTP. Voir Limitations connues.

​
Alias de certificat

Quatre éléments TLS encodés en PEM sont requis, sous la forme de deux paires d’alias de secret (certificat + clé privée). Avec le fournisseur Azure, stockez-les comme secrets Key Vault, et non comme objets de certificat Key Vault : Avec le fournisseur Azure, l’approche la plus simple consiste à créer deux certificats auto-signés dans Key Vault, nommés auth-signing et auth-deactivated (Common Name = votre valeur Vantage dnsRecord), puis à créer quatre secrets Key Vault dont les noms correspondent aux alias ci-dessus. Avec le fournisseur Kubernetes, créez au préalable les ressources Secret contenant les éléments PEM. Les clés de données par défaut sont auth-signing-tls-crt, auth-signing-tls-key, auth-deactivated-tls-crt et auth-deactivated-tls-key. Utilisez une mise en correspondance objects pour remapper les noms de Secret.

​
Nommage et mise en correspondance

Avec le fournisseur Azure, les alias qui ne sont pas répertoriés dans la mise en correspondance objects utilisent par défaut l’alias lui-même comme nom d’objet de Key Vault (récupéré avec le type secret). Si vos objets Key Vault portent déjà des noms correspondant aux alias, aucune mise en correspondance objects n’est requise. Avec le fournisseur Kubernetes, les noms de secret par défaut sont utilisés lorsque objects n’est pas défini. Si votre processus de provisionnement utilise des noms différents, fournissez une mise en correspondance objects dans votre configuration des secrets :
L’alias constitue le contrat d’API ; à vous de choisir le nom de l’objet.

​
Autorisations requises

Avec le fournisseur Azure Key Vault, l’identité utilisée par le Secrets Store CSI driver doit disposer d’un accès en lecture à chaque secret et certificat listé ci-dessus :
  • workloadIdentity (par défaut) : l’identité managée attribuée par l’utilisateur dont le clientId est indiqué dans vantage.secrets.azure.clientId.
  • vmManagedIdentity : l’identité dont l’ID client est indiqué dans vantage.secrets.azure.userAssignedIdentityID.
  • podIdentity : scénario non testé ; contactez l’équipe ABBYY en charge de votre compte avant de vous appuyer dessus.
Avec le fournisseur de Secrets Kubernetes, aucune autorisation Key Vault ni aucun droit lié à une identité cloud n’interviennent. Créez à l’avance les ressources Secret dans le namespace d’installation ; Vantage les utilise directement.
L’identité de charge de travail du driver CSI (ici) est distincte de l’identité de charge de travail utilisée par les autres charges de travail de votre cluster (par exemple, un Prometheus dans le mesh que vous déployez pour le monitoring ; le programme d’installation de Vantage ne déploie pas Prometheus). Elles peuvent utiliser la même UAMI ou des UAMI différentes.

​
Prochaines étapes

Prérequis

Exigences relatives au cluster et aux services externes pour toute installation.

Installer sur Azure

Éléments Azure Key Vault requis et procédure d’installation pas à pas.

Kubernetes autogéré

Configuration des Secrets Kubernetes natifs et de PostgreSQL.