Stronghold is built on HashiCorp Vault. As the release notes state, the first version of Stronghold (v1.0, February 2024) is based on Vault v1.14.x. Stronghold therefore keeps the data model, HTTP API, configuration format, and CLI of HashiCorp Vault and extends them with its own features.
Stronghold is based on Vault OSS 1.14.8, the last version under the MPL 2.0 license. Stronghold version numbers (1.19) do not match Vault version numbers: features of newer Vault versions are not carried over automatically.
Base Stronghold corresponds to Vault CE. Some features that HashiCorp Vault offers only in Vault Enterprise are part of Stronghold EE. For the edition comparison, refer to Editions.
API compatibility
The Stronghold HTTP API is compatible with the Vault API:
- Requests use the same paths with the
/v1/prefix (/v1/sys/...,/v1/auth/...,/v1/<MOUNT>/...). - The token is passed in the
X-Vault-Tokenheader. - Request and response formats of secrets engines and auth methods match Vault.
Transitciphertext uses thevault:v<KEY_VERSION>:...format, so data encrypted in Vault keeps its familiar format.- The
KV1/KV2API is compatible with Vault to the extent that Stronghold can replicate KV stores from Vault CE, Vault Enterprise, or any store with a compatible Vault KV/KV2 API.
Example API request:
curl --header "X-Vault-Token: ${STRONGHOLD_TOKEN}" "${STRONGHOLD_ADDR}/v1/sys/health"For a full description of the endpoints, refer to the API reference.
CLI
The Stronghold CLI mirrors the commands and flags of the vault CLI. Only the way you call it differs:
| Environment | Command | Example |
|---|---|---|
| HashiCorp Vault | vault <COMMAND> | vault kv get -mount=secret app |
| Stronghold in Deckhouse Platform (DP), via Deckhouse CLI | d8 stronghold <COMMAND> | d8 stronghold kv get -mount=secret app |
| Stronghold on Linux (standalone) | stronghold <COMMAND> | stronghold kv get -mount=secret app |
Subcommands, flags, and their behavior are described in d8 stronghold.
Environment variables
Client environment variables in the Stronghold documentation use the STRONGHOLD_ prefix:
| Stronghold | Vault equivalent | Purpose |
|---|---|---|
STRONGHOLD_ADDR | VAULT_ADDR | Server address |
STRONGHOLD_TOKEN | VAULT_TOKEN | Client token |
STRONGHOLD_CACERT | VAULT_CACERT | Path to the CA certificate used to verify the server TLS certificate |
Both prefixes work. On start, stronghold and d8 stronghold copy the value of every STRONGHOLD_* variable to the VAULT_* variable with the same name suffix, for example STRONGHOLD_TOKEN to VAULT_TOKEN. If both variables are set, the STRONGHOLD_* value overrides the VAULT_* value.
This also applies to the environment variables that override server configuration parameters, for example VAULT_API_ADDR, VAULT_CLUSTER_ADDR, VAULT_RAFT_PATH, VAULT_RAFT_NODE_ID, and VAULT_ENABLE_FILE_PERMISSIONS_CHECK: you can set them with the STRONGHOLD_ prefix too. The list of these variables is in Configuration.
Server and agent configuration
The server and Stronghold Agent use the Vault configuration formats:
- The server configuration file uses the HCL or JSON format and the same sections as Vault:
listener,storage,seal,telemetry,ui, and others. For the section descriptions, refer to Configuration. - Stronghold Agent reads the server connection settings from the
strongholdorvaultsection. The two sections are synonyms and work with both Stronghold and HashiCorp Vault: set only one of them. For the section parameters, refer to Basic settings.
Ecosystem tools
Because the API is compatible, you can point most Vault ecosystem tools at Stronghold by specifying its address. Compatibility status:
| Tool | Connection method | Status |
|---|---|---|
DP module secrets-store-integration (CSI driver, env-injector) | Native integration | Supported |
| Stronghold Agent | Native integration | Supported |
| Ansible, Terraform | Vault providers and modules | Supported, refer to Editions |
| External Secrets Operator | vault provider | Not confirmed by tests |
| cert-manager | vault Issuer | Not confirmed by tests |
| Jenkins (HashiCorp Vault Plugin), GitLab CI, GitHub Actions | Vault plugins and actions, JWT authentication | See Usage examples |
Client SDKs (Go github.com/hashicorp/vault/api, Python hvac, and others) | Vault client libraries | Not confirmed by tests |
Methods of delivering secrets to Kubernetes are compared in Delivering secrets to Kubernetes pods.
Features not available in HashiCorp Vault
| Feature | Edition | Description |
|---|---|---|
| KV1/KV2 replication | Stronghold EE | API-based pull replication of individual KV stores, including from Vault CE and Vault Enterprise |
| GitOps secrets engine | Stronghold EE | Managing Stronghold configuration through a quorum of Git commit signatures |
Built-in trdl plugin | Stronghold EE | Managing artifact builds and signing through a quorum of Git commit signatures |
inner-cluster seal | Stronghold EE, Stronghold CSE | Built-in auto unseal: unsealed cluster nodes unseal other nodes without an external KMS |
yandexcloudkms seal | Stronghold EE | Auto unseal and root key protection with Yandex Cloud KMS (standalone only) |
| GOST cryptography | Stronghold EE | TLS 1.3 with Magma and Kuznyechik GOST encryption, GOST 34.10 certificates in PKI, GOST algorithms in Transit |
CryptoPro seal wrapper | Stronghold EE | Seal wrapper for scenarios with Russian cryptography. Available in the Linux build with HSM support |
| Managed Keys with Yandex KMS | Stronghold EE | Working with key material in Yandex KMS and PKCS #11 devices from Transit, PKI, and SSH |
| Namespace locks in the web interface | Stronghold EE | Locking and unlocking the Namespace API |
stronghold bootstrap commands | Stronghold EE | Generating a Linux service installation script, a Helm chart, and a Docker image |
| Russian-language web interface, role and policy management in the web interface | Russian-language interface: all; role and policy management: Stronghold EE | Localized web interface with extended administration capabilities |
| Deployment as a DP module | All | Automatic initialization, unsealing, and Dex integration. Refer to Stronghold configuration |
Vault Enterprise features available in Stronghold EE: namespaces, Performance and DR replication, performance standby, automated snapshots, seal wrap, HSM (PKCS #11), Managed Keys, and SAML authentication. When you migrate from Vault Enterprise, the automated snapshot configuration is preserved.
Differences and limitations
Stronghold differs from HashiCorp Vault in the following:
- Yandex Cloud KMS is the only external cloud KMS supported for
seal. Theawskms,gcpckms,azurekeyvault,ocikms, andalicloudkmsconfigurations are not supported; thetransitseal is supported. - HSM (
seal "pkcs11") andseal "yandexcloudkms"are supported only in a standalone installation. - In DP, the
strongholdmodule supports theAutomatic(default) andManualmodes and theIngress(default),GatewayAPI,LoadBalancer,NodePort, andNoneinlets. In theAutomaticmode, the module performs initialization and unsealing. For the module settings, refer to Stronghold configuration. - In Stronghold, you can disable
seal wrapfor all data except the root key with thedisable_sealwrap = trueparameter. - Sentinel (RGP/EGP policies), KMIP, the Transform secrets engine, and the Key Management secrets engine are not implemented in Stronghold: the corresponding endpoints are closed by the license even in Stronghold EE. Control Groups are implemented in Stronghold EE. The Login MFA subsystem (
identity/mfa/*: TOTP, Okta, Duo, PingID, and Multifactor methods, login enforcements) is part of all editions; the legacy Enterprise MFA (sys/mfa) is available in Stronghold EE.
Migrating from HashiCorp Vault
For how to transfer data and configuration from HashiCorp Vault to Stronghold, refer to Migrating from HashiCorp Vault.