> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Secrets et Key Vault

> Comment Vantage 3.0 auto-hébergé lit les secrets et les certificats : à partir d’Azure Key Vault via le Secrets Store CSI driver, ou à partir de ressources Kubernetes Secret préexistantes.

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`.

<div id="supported-providers">
  ## Fournisseurs pris en charge
</div>

| Fournisseur            | Valeur Helm                  | Description                                                                                                                                                                                         |
| ---------------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Azure Key Vault**    | `vantage.secrets.azure`      | Utilise le Secrets Store CSI Driver avec le fournisseur Azure Key Vault. L’opérateur crée une `SecretProviderClass` par chart, et le driver monte les secrets dans les pods sous forme de fichiers. |
| **Kubernetes Secrets** | `vantage.secrets.kubernetes` | Utilise directement des ressources Kubernetes `Secret` existantes. Aucune infrastructure externe de gestion des secrets n’est requise.                                                              |

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](#secret-aliases) ci-dessous pour planifier le provisionnement.

<div id="azure-key-vault-provider">
  ## Fournisseur Azure Key Vault
</div>

```yaml theme={null}
vantage:
  secrets:
    azure:
      keyVaultName: mykeyvault
      tenantId: 00000000-0000-0000-0000-000000000000
      clientId: 00000000-0000-0000-0000-000000000000  # ID client de l'UAMI avec accès en lecture au Key Vault
      identityMode: workloadIdentity                   # workloadIdentity (default) | podIdentity | vmManagedIdentity
```

<div id="identity-modes">
  ### Modes d’identité
</div>

| Mode                            | Comment le pilote CSI s’authentifie                                                                                                                                                                                                                                                               |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `workloadIdentity` (par défaut) | Azure Workload Identity. Le ServiceAccount de chaque chart est fédéré à une identité managée attribuée par l’utilisateur (UAMI) dont le `clientId` est indiqué ici. Cette UAMI doit disposer d’un accès en lecture aux objets du Key Vault sur lesquels reposent les alias utilisés par ce chart. |
| `podIdentity`                   | Liaison AAD Pod Identity héritée. Ce mode n’est pas un scénario testé ; contactez l’équipe ABBYY en charge de votre compte avant de vous y fier.                                                                                                                                                  |
| `vmManagedIdentity`             | Une identité managée affectée à une VM. L’ID client de l’UAMI est fourni via `vantage.secrets.azure.userAssignedIdentityID`. Cette identité doit disposer d’un accès en lecture au Key Vault.                                                                                                     |

<div id="how-it-works">
  ### Fonctionnement
</div>

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 :

```
┌──────────────────────┐
│  Azure Key Vault     │  Customer-provisioned secret/certificate objects
└──────────┬───────────┘
           │ ① read via configured identity
           ▼
┌──────────────────────────────────────────────────┐
│  SecretProviderClass  (one per chart)            │  Created by the operator
│  alias → Key Vault objectName                    │
│  alias → key in the per-chart Kubernetes Secret  │
└──────────┬───────────────────────────────────────┘
           │ ② Secrets Store CSI driver populates
           ▼
┌──────────────────────────────────────────────────┐
│  Kubernetes Secret  (one per chart)              │  e.g. mail-helm-secrets
└──────────┬───────────────────────────────────────┘
           │ ③ envFrom (env vars) and/or volumeMounts (files)
           ▼
┌──────────────────────────────────────────────────┐
│  Vantage pod                                     │
└──────────────────────────────────────────────────┘
```

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](https://azure.github.io/secrets-store-csi-driver-provider-azure) doivent être installés dans le cluster avant Vantage. Voir [Prérequis](/fr/vantage/self-hosted/v3.0/prerequisites).

<div id="per-chart-resources">
  ### Ressources par chart
</div>

Chaque chart Vantage qui utilise des secrets dispose de son propre jeu de ressources :

| Ressource             | Modèle de nom                                                                              | Rôle                                                                                                                                                 |
| --------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `SecretProviderClass` | `{chart}-secret-provider` (et `{chart}-migr-secret-provider` pour les tâches de migration) | Répertorie les alias Key Vault dont le chart a besoin et indique comment ils sont mis en correspondance avec le `Secret` Kubernetes propre au chart. |
| `Secret`              | `{chart}-secrets` (et `{chart}-migr-secrets`)                                              | Renseigné par le pilote CSI ; monté dans le pod du chart via `envFrom`.                                                                              |
| Volume `Secret`s      | `{chart}-secrets-volume-N`                                                                 | `Secret`s supplémentaires propres au chart pour les éléments qui doivent être montés sous forme de fichiers (par ex. des certificats).               |

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.

<div id="service-accounts-and-identity-scope">
  ### Comptes de service et portée de l’identité
</div>

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.

<Note>
  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](/fr/vantage/self-hosted/v3.0/providers/azure#image-pull-access).
</Note>

<div id="kubernetes-secrets-provider">
  ## Fournisseur de Secrets Kubernetes
</div>

```yaml theme={null}
vantage:
  secrets:
    kubernetes:
      # objects:                           # facultatif : remplacer les noms de secrets par défaut
      #   sendgridApiKey:
      #     secretName: my-sendgrid-secret
```

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.

<div id="postgresql-and-per-service-secrets">
  ### PostgreSQL et les Secrets par service
</div>

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` :

```yaml theme={null}
vantage:
  databaseProvider: PostgreSQL
  reportingEnabled: false
  secrets:
    kubernetes:
      objects:
        subscriptionDatabaseConnectionString:
          secretName: vantage-db-subscriptions
        workspaceDatabaseConnectionString:
          secretName: vantage-db-workspace
```

Chaque Secret mis en correspondance contient la même clé, mais une chaîne de connexion de base de données différente :

```yaml theme={null}
apiVersion: v1
kind: Secret
metadata:
  name: vantage-db-subscriptions
  namespace: <install-namespace>
type: Opaque
stringData:
  Database__ConnectionString: "Host=<host>;Port=5432;Database=subscriptions;Username=<user>;Password=<password>;Ssl Mode=Require"
```

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.

<div id="secret-aliases">
  ## Alias de secrets
</div>

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.

<div id="platform">
  ### Plateforme
</div>

| Alias                          | Description                                                                                                                                    |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `sendgridApiKey`†              | Clé API pour SendGrid. Obligatoire, sauf si vous configurez `spec.smtp`.                                                                       |
| `redisConnectionString`        | Chaîne de connexion Redis.                                                                                                                     |
| `redisCacheConnectionString`   | Chaîne de connexion pour le cache Redis / les verrous / le cache client. Peut réutiliser `redisConnectionString`.                              |
| `secretStorageUserKeyVaultUri` | URI d’Azure Key Vault utilisé pour le stockage des secrets. Il peut s’agir du même coffre ou d’un coffre distinct (ce dernier est recommandé). |

<div id="storage">
  ### Stockage
</div>

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.

| Alias                                    | Description                                                          |
| ---------------------------------------- | -------------------------------------------------------------------- |
| `storageArchiveConnectionString`         | Chaîne de connexion du compte de stockage (« archive »).             |
| `storageLegacyTemporaryConnectionString` | Chaîne de connexion du compte de stockage (« temporaire (ancien) »). |
| `storageTemporaryConnectionString`       | Chaîne de connexion du compte de stockage (« temporaire »).          |
| `storagePermanentConnectionString`       | Chaîne de connexion du compte de stockage (« permanent »).           |
| `storageStandardConnectionString`        | Chaîne de connexion du compte de stockage (« standard »).            |

<div id="databases">
  ### Bases de données
</div>

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.

| Alias                                        | Base de données                                             |
| -------------------------------------------- | ----------------------------------------------------------- |
| `apiRegistryDatabaseConnectionString`        | `apiregistry`                                               |
| `auth2DatabaseConnectionString`              | `auth`                                                      |
| `authIdentityDatabaseConnectionString`       | `auth-identity`                                             |
| `cronServiceDatabaseConnectionString`        | `cron`                                                      |
| `documentSetStorageDatabaseConnectionString` | `documentset`                                               |
| `mailDatabaseConnectionString`               | `mail`                                                      |
| `securityAuditDatabaseConnectionString`      | `security-audit`                                            |
| `storageDatabaseConnectionString`            | `storage`                                                   |
| `workflowDatabaseConnectionString`           | `workflows`                                                 |
| `catalogStorageDatabaseConnectionString`     | `catalogstorage`                                            |
| `folderImportDatabaseConnectionString`       | `folderimport`                                              |
| `interactiveJobsDatabaseConnectionString`    | `interactive-jobs`                                          |
| `mailImportDatabaseConnectionString`         | `mailimport`                                                |
| `permissionsDatabaseConnectionString`        | `permissions`                                               |
| `reportingDatabaseConnectionString`          | `reporting` (doit prendre en charge les index columnstore). |
| `secretStorageDatabaseConnectionString`      | `secretstorage`                                             |
| `skillInfoDatabaseConnectionString`          | `skillinfo`                                                 |
| `skillMonitorDatabaseConnectionString`       | `skillmonitor`                                              |
| `subscriptionDatabaseConnectionString`       | `subscriptions`                                             |
| `tokenManagementDatabaseConnectionString`    | `tokenmanagement`                                           |
| `transactionsDatabaseConnectionString`       | `transactions`                                              |
| `urlShortenerDatabaseConnectionString`       | `urlshortener`                                              |
| `workspaceDatabaseConnectionString`          | `workspace`                                                 |

<div id="oauth">
  ### OAuth
</div>

| Alias                        | Description                    |
| ---------------------------- | ------------------------------ |
| `oAuthGoogleClientId`        | ID client Google OAuth.        |
| `oAuthGoogleClientSecret`    | secret client Google OAuth.    |
| `oAuthMicrosoftClientId`     | ID client Microsoft OAuth.     |
| `oAuthMicrosoftClientSecret` | secret client Microsoft OAuth. |

† `sendgridApiKey` est obligatoire uniquement si vous n’utilisez pas SMTP. Voir [Limitations connues](/fr/vantage/self-hosted/v3.0/known-limitations#smtp-supports-basic-auth-only).

<div id="certificate-aliases">
  ## Alias de certificat
</div>

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 :

| Alias                   | Description                                                                                                               |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `authSigningTlsCrt`     | Certificat encodé en PEM pour la signature d’authentification (issu du certificat Key Vault `auth-signing`).              |
| `authSigningTlsKey`     | Clé privée encodée en PEM pour la signature d’authentification.                                                           |
| `authDeactivatedTlsCrt` | Certificat encodé en PEM pour les jetons d’authentification désactivés (issu du certificat Key Vault `auth-deactivated`). |
| `authDeactivatedTlsKey` | Clé privée encodée en PEM pour les jetons d’authentification désactivés.                                                  |

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`.

<div id="naming-and-remapping">
  ## Nommage et mise en correspondance
</div>

**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 :

```yaml theme={null}
vantage:
  secrets:
    azure:
      # ...
      objects:
        sendgridApiKey:
          objectName: my-sendgrid-key            # Nom de l'objet Azure Key Vault
        reportingDatabaseConnectionString:
          objectName: vantage-reporting-conn
```

```yaml theme={null}
vantage:
  secrets:
    kubernetes:
      objects:
        sendgridApiKey:
          secretName: my-sendgrid-secret         # Nom du Secret Kubernetes
        reportingDatabaseConnectionString:
          secretName: my-reporting-secret
```

L’alias constitue le contrat d’API ; à vous de choisir le nom de l’objet.

<div id="required-permissions">
  ## Autorisations requises
</div>

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.

<Note>
  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.
</Note>

<div id="whats-next">
  ## Prochaines étapes
</div>

<CardGroup cols={2}>
  <Card title="Prérequis" icon="list-check" href="/fr/vantage/self-hosted/v3.0/prerequisites">
    Exigences relatives au cluster et aux services externes pour toute installation.
  </Card>

  <Card title="Installer sur Azure" icon="cloud" href="/fr/vantage/self-hosted/v3.0/providers/azure">
    Éléments Azure Key Vault requis et procédure d’installation pas à pas.
  </Card>

  <Card title="Kubernetes autogéré" icon="server" href="/fr/vantage/self-hosted/v3.0/providers/self-managed">
    Configuration des Secrets Kubernetes natifs et de PostgreSQL.
  </Card>
</CardGroup>