Saltar al contenido principal
Vantage 3.0 autoalojado obtiene cada cadena de conexión a la base de datos, cada API key y cada certificado TLS de un proveedor de secretos al iniciar el pod; ninguno de estos valores se almacena en archivos values.yaml. Se admiten dos proveedores; en cada instalación se configura exactamente uno mediante vantage.secrets.

​
Proveedores compatibles

Los dos proveedores comparten la misma convención de alias de secreto. Las cargas de trabajo de Vantage buscan los secretos por alias, independientemente de dónde provengan los valores. Usa el inventario de alias que aparece a continuación para planificar el aprovisionamiento.

​
Proveedor de Azure Key Vault

​
Modos de identidad

​
Cómo funciona

Vantage usa el controlador Secrets Store CSI con el proveedor de Azure Key Vault. El SecretProviderClass de cada chart se monta como un volumen CSI en el pod que lo consume, y ese montaje hace que el controlador sincronice los valores en un Secret de Kubernetes específico de cada chart (la funcionalidad secretObjects del SPC), que el pod consume mediante envFrom y montajes de volumen. La secuencia es:
  1. El operador genera un SecretProviderClass (SPC) por chart, en el que declara qué alias de Key Vault necesita ese chart y cómo se asigna cada uno a una clave de un Secret de Kubernetes específico del chart.
  2. Cuando un pod monta el volumen del SPC, el controlador Secrets Store CSI se autentica con la identidad seleccionada por identityMode, obtiene de Key Vault los objetos indicados y los sincroniza en un Secret de Kubernetes específico del chart mediante la funcionalidad secretObjects del SPC.
  3. El pod del chart consume el Secret específico del chart:
    • La mayoría de los secretos se cargan como variables de entorno mediante envFrom.
    • Los certificados (authSigningTlsCrt, etc.) también se montan como archivos mediante volumeMounts (normalmente en /var/run/certs/).
Los valores de los secretos aparecen en el Secret de Kubernetes específico del chart y en el entorno del pod en tiempo de ejecución, por lo que no son invisibles para kubectl get secret. Pero nunca aparecen en values.yaml, en los diffs de ArgoCD ni en Git, porque el controlador CSI los completa al iniciarse el pod. El controlador Secrets Store CSI y el plugin de proveedor de Azure Key Vault deben estar instalados en el clúster antes de Vantage. Consulte Requisitos previos.

​
Recursos por chart

Cada chart de Vantage que consume secretos tiene su propio conjunto de recursos: Esta división por chart mantiene el acceso a Key Vault con el mínimo privilegio: el SPC de un chart solo hace referencia a los alias que ese chart realmente necesita.

​
Cuentas de servicio y alcance de la identidad

El operador no crea ni anota recursos ServiceAccount. Cada chart aporta su propia SA mediante valores estándar de Helm; el cliente es responsable de federar las ServiceAccount de cada chart que montan los SPC con la identidad administrada asignada por el usuario (UAMI) cuyo clientId se proporciona en vantage.secrets.azure.clientId. Esa identidad debe tener acceso de lectura a los objetos de Key Vault que respaldan los alias de los charts.
El acceso a Key Vault y el acceso para extraer imágenes son aspectos independientes que pueden recaer en las mismas ServiceAccount. La federación de UAMI (esta página) concede acceso de lectura a los secretos; no autentica la extracción de imágenes. Para la extracción, agregue un secret de extracción del registry a imagePullSecrets de la ServiceAccount indicada por vantage.serviceAccountName, o bien conceda AcrPull a la identidad de kubelet de AKS. Consulte Acceso para extraer imágenes.

​
Proveedor de Secrets para Kubernetes

Cree previamente los recursos Secret en el espacio de nombres de instalación antes de ejecutar el chart. Si objects no está definido, se usarán los nombres predeterminados de los secretos; proporcione una asignación de objects (secretName por alias) para que apunte a Secrets con nombres distintos. Este proveedor no requiere el controlador Secrets Store CSI ni ningún Key Vault en la nube. Los valores se leen directamente de los objetos Secret del clúster. Durante la comprobación previa, el operador valida la configuración de los secretos. Los charts del operador matched y de Vantage instalan un ClusterRole con acceso de lectura a Secrets y lo vinculan a la ServiceAccount del operador solo en el espacio de nombres de la release de Vantage. Si restringe el acceso a Secret mediante resourceNames, incluya todos los nombres de Secret predeterminados y reemplazados. Un sistema externo de gestión de secretos puede seguir siendo su fuente de referencia. Por ejemplo, External Secrets Operator puede materializar Secrets de Kubernetes desde HashiCorp Vault. Vantage solo consume los Secrets de Kubernetes resultantes y no se conecta directamente a External Secrets ni a Vault.

​
PostgreSQL y Secrets por servicio

Configura vantage.databaseProvider: PostgreSQL para usar PostgreSQL. Cada servicio debe recibir una cadena de conexión que especifique una base de datos lógica diferente; si comparten una sola base de datos, el estado de migración de los servicios entrará en conflicto. Algunas cargas de trabajo leen claves de cadena de conexión con nombres únicos y pueden compartir un Secret. Otras cargas de trabajo leen la clave genérica Database__ConnectionString; crea un Secret independiente para cada uno de esos servicios y asigna su alias mediante vantage.secrets.kubernetes.objects:
Cada Secret asignado contiene la misma clave, pero una cadena de conexión a la base de datos distinta:
Usa tu sistema de gestión de secretos para crear estos Secrets sin subir credenciales al control de versiones. Las cadenas de conexión deben estar en una sola línea, sin caracteres de nueva línea al principio, al final ni intercalados. La generación de informes solo está disponible para SQL Server. Deja reportingEnabled: false cuando uses PostgreSQL.

​
Alias de secretos

Los siguientes alias son el acuerdo establecido entre las cargas de trabajo de Vantage y su proveedor de secretos. Con el proveedor de Azure, la forma más sencilla de configurarlo es asignar a los secretos de Key Vault el mismo nombre que el alias. Con cualquiera de los dos proveedores, puede reasignar los nombres mediante una asignación de objects en la configuración de secretos.

​
Plataforma

​
Almacenamiento

Solo es obligatorio cuando se usa el backend predeterminado de Azure Blob Storage. Cuando spec.storage.custom está configurado para un backend respaldado por una StorageClass de Kubernetes (por ejemplo, NFS), estos alias no se utilizan. Cada alias es una cadena de conexión de una storage account; consulta la documentación base del sistema Vantage para ver para qué se usa cada tipo de almacenamiento.

​
Bases de datos

Cadenas de conexión, una por cada base de datos distinta. Los nombres de las bases de datos son ilustrativos; cualquier nombre que genere el proceso de aprovisionamiento es válido, siempre que la cadena de conexión apunte a la base de datos correcta.

​
OAuth

† sendgridApiKey solo es obligatorio si no se usa SMTP. Consulte Limitaciones conocidas.

​
Alias de certificados

Se requieren cuatro elementos TLS codificados en PEM, presentados como dos pares de alias de secretos (certificado + clave privada). Con el proveedor de Azure, guárdelos como secretos de Key Vault, no como objetos de certificado de Key Vault: Con el proveedor de Azure, la forma más sencilla es crear dos certificados autofirmados en Key Vault llamados auth-signing y auth-deactivated (Nombre común = el valor de dnsRecord de Vantage) y, a continuación, crear cuatro secretos de Key Vault con nombres que coincidan con los alias anteriores. Con el proveedor de Kubernetes, cree previamente los recursos Secret que contengan el material PEM. Las claves de datos predeterminadas son auth-signing-tls-crt, auth-signing-tls-key, auth-deactivated-tls-crt y auth-deactivated-tls-key. Use una asignación de objects para reasignar los nombres de Secret.

​
Nombres y reasignación

Con el proveedor de Azure, los alias que no figuran en la asignación objects usan el propio alias como nombre del objeto de Key Vault (recuperado como tipo secret). Si los objetos de Key Vault ya tienen nombres que coinciden con los alias, no se requiere ninguna asignación objects. Con el proveedor de Kubernetes, se usan los nombres predeterminados de los secrets cuando no se define objects. Si el proceso de aprovisionamiento usa nombres diferentes, proporcione una asignación objects en la configuración de secrets:
El alias forma parte del contrato de la API; el nombre del objeto lo eliges tú.

​
Permisos necesarios

Con el proveedor de Azure Key Vault, la identidad que usa el controlador Secrets Store CSI debe tener acceso de lectura a cada secreto y certificado indicados arriba:
  • workloadIdentity (predeterminado): la identidad administrada asignada por el usuario cuyo clientId se proporciona en vantage.secrets.azure.clientId.
  • vmManagedIdentity: la identidad cuyo ID de cliente se proporciona en vantage.secrets.azure.userAssignedIdentityID.
  • podIdentity: no es un escenario probado; ponte en contacto con tu equipo de cuenta de ABBYY antes de confiar en él.
Con el proveedor de secretos de Kubernetes, no intervienen permisos de Key Vault ni permisos de identidad en la nube. Crea previamente los recursos Secret en el namespace de instalación; Vantage los consume directamente.
La identidad de carga de trabajo del controlador CSI (aquí) es distinta de la identidad de carga de trabajo que usan otras cargas de trabajo de tu clúster (por ejemplo, un Prometheus en la malla que implementes para la supervisión; el instalador de Vantage no implementa Prometheus). Pueden usar la misma UAMI o UAMIs diferentes.

​
Qué sigue

Requisitos previos

Requisitos a nivel de clúster y de servicios externos para cualquier instalación.

Instalar en Azure

Inventario de Azure Key Vault y la instalación paso a paso.

Kubernetes autogestionado

Secrets nativos de Kubernetes y configuración de PostgreSQL.