hashicorp / hashicorp/vault-helm
vault-active service has no endpoints when Vault is uninitialized
- Dominant language
- Shell
- Stars
- 1.3k
- Forks
- 898
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 1
Description
Since updating to Vault Helm Chart 0.6.0, when you have a new install of Vault which is uninitialized, vault can now no longer be accessed by ingress as there is no leader which can be routed via the "vault-active" kubernetes service.
Is there a know work around for this?
I have listed some of my configuration below:
```
$ vault status -tls-skip-verify
Recovery Seal Type gcpckms
Initialized false
Sealed true
Total Recovery Shares 0
Threshold 0
Unseal Progress 0/0
Unseal Nonce n/a
Version n/a
HA Enabled true
```
```
dev:
enabled: false
readinessProbe:
path: "/v1/sys/health?standbyok=true&uninitcode=298"
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/backend-protocol: HTTPS
hosts:
- host: "vault.{COMPANY_NAME}.uk"
paths:
- /
tls:
- hosts:
- "vault.{COMPANY_NAME}.uk"
extraVolumes:
- type: configMap
name: vault-server-tls-script
path: null
- type: emptydir
name: ssl-certificates
dataStorage:
size: 100Gi
ha:
enabled: true
replicas: 5
raft:
enabled: true
config: |
ui = true
listener "tcp" {
tls_disable = false
address = "[::]:8200"
cluster_address = "[::]:8201"
tls_cert_file = "/vault/userconfig/ssl-certificates/vault.crt"
tls_key_file = "/vault/userconfig/ssl-certificates/vault.key"
tls_require_and_verify_client_cert = false
tls_disable_client_certs = true
}
service_registration "kubernetes" {}
log_level = "info"
storage "raft" {
path = "/vault/data"
retry_join {
leader_api_addr = "https://vault-0.vault-internal:8200"
leader_ca_cert = "-----BEGIN CERTIFICATE----------END CERTIFICATE-----"
}
retry_join {
leader_api_addr = "https://vault-1.vault-internal:8200"
leader_ca_cert = "-----BEGIN CERTIFICATE----------END CERTIFICATE-----"
}
retry_join {
leader_api_addr = "https://vault-2.vault-internal:8200"
leader_ca_cert = "-----BEGIN CERTIFICATE----------END CERTIFICATE-----"
}
retry_join {
leader_api_addr = "https://vault-3.vault-internal:8200"
leader_ca_cert = "-----BEGIN CERTIFICATE----------END CERTIFICATE-----"
}
retry_join {
leader_api_addr = "https://vault-4.vault-internal:8200"
leader_ca_cert = "-----BEGIN CERTIFICATE----------END CERTIFICATE-----"
}
}
seal "gcpckms" {
project = "COMPANY-vault-prod"
region = "global"
key_ring = "unseal_vault_keyring-${ENVIRONMENT}"
crypto_key = "vault_crypto_key-${ENVIRONMENT}"
}
```
Contributor guide
Research direction
Start by inspecting the vault-active Kubernetes Service produced by Helm chart 0.6.0 and compare its endpoints with the readinessProbe and uninitialized health response in the provided configuration. Reproduce a fresh HA/raft install and verify whether ingress can reach an uninitialized Vault pod; done means identifying and documenting a reliable workaround or correcting the endpoint behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100