[TAXII Feeds] Support external secrets manager (HashiCorp Vault) for feed authentication credentials
Use case
Organizations with strict secrets-management policies (e.g. financial services, government/defence, regulated industries) require that all third-party integration credentials be sourced from a centralized, audited secrets manager such as HashiCorp Vault, and never entered into or persisted by an individual product's UI or database.
Currently, when creating a TAXII Feed ingester (Integrations > TAXII Feeds > Create a TAXII ingester), non-public collections require the "Bearer token" authentication type, where the token is entered as a raw value in the form and persisted in the OpenCTI database. For organizations subject to such policies, this prevents the use of built-in TAXII Feeds for authenticated collections, forcing them to either forgo the feature or build a custom external connector.
Current Workaround
Enter the bearer token as a raw value in the TAXII ingester form. This is functional but non-compliant for organizations whose policy forbids storing credentials in the product UI/database.
Proposed Solution
- Add a "Use external secret" (or equivalent) option to the TAXII Feed authentication configuration, consistent with the existing pattern available for Authentication providers (Settings > Authentications,
SECRETS__<NAME>__VALUE), so the credential field references a named secret instead of accepting a raw value.
- Extend the backing secrets mechanism to support HashiCorp Vault as a source:
- Configurable Vault address, auth method (e.g. AppRole, Kubernetes auth), and secret path/key per referenced secret.
- Runtime lookup of the secret value when the ingester executes; the value is never persisted in the OpenCTI database.
- Support for credential rotation on the Vault side without reconfiguring the ingester (value re-fetched rather than cached indefinitely).
- Apply the same capability to other built-in feed types (CSV, JSON, RSS) that use token or basic-auth credentials, for consistency. TAXII Feeds are the immediate priority.
Additional Information
References:
docs/docs/usage/import/taxii-feed.md: documents "Bearer token" as the authentication type for non-public collections, entered as a raw value.docs/docs/administration/authentication-via-ui.md: documents the SECRETS__<NAME>__VALUE / "Use external secret" pattern, currently scoped to Authentication providers.
[TAXII Feeds] Support external secrets manager (HashiCorp Vault) for feed authentication credentials
Use case
Organizations with strict secrets-management policies (e.g. financial services, government/defence, regulated industries) require that all third-party integration credentials be sourced from a centralized, audited secrets manager such as HashiCorp Vault, and never entered into or persisted by an individual product's UI or database.
Currently, when creating a TAXII Feed ingester (Integrations > TAXII Feeds > Create a TAXII ingester), non-public collections require the "Bearer token" authentication type, where the token is entered as a raw value in the form and persisted in the OpenCTI database. For organizations subject to such policies, this prevents the use of built-in TAXII Feeds for authenticated collections, forcing them to either forgo the feature or build a custom external connector.
Current Workaround
Enter the bearer token as a raw value in the TAXII ingester form. This is functional but non-compliant for organizations whose policy forbids storing credentials in the product UI/database.
Proposed Solution
SECRETS__<NAME>__VALUE), so the credential field references a named secret instead of accepting a raw value.Additional Information
References:
docs/docs/usage/import/taxii-feed.md: documents "Bearer token" as the authentication type for non-public collections, entered as a raw value.docs/docs/administration/authentication-via-ui.md: documents theSECRETS__<NAME>__VALUE/ "Use external secret" pattern, currently scoped to Authentication providers.