hashicorp / hashicorp/vault-helm
Simplify metrics access by supporting an additional service in the chart
- Dominant language
- Shell
- Stars
- 1.3k
- Forks
- 898
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 1
Description
In an effort to simplify metrics access it would be nice if the template supported an option to enable a service for metrics. This way consumers of the chart could use `unauthenticated_metrics_access = "true"` on a different listener that was not going to be exposed via ingress. In my use-case I want to expose a service http://vault-metrics.vault-enterprise:9200 to my Datadog agents for the Vault integration.
**Describe the solution you'd like**
Something like this may fit in this section of the values:
```yaml
# Enables a headless service to be used by the Vault Statefulset
service:
enabled: true
# Enable or disable the vault-active service, which selects Vault pods that
# have labelled themselves as the cluster leader with `vault-active: "true"`
active:
enabled: true
# Enable or disable the vault-standby service, which selects Vault pods that
# have labelled themselves as a cluster follower with `vault-active: "false"`
standby:
enabled: true
# Enable or disable the vault-metrics service, which expose unauthenticated_metrics_access
# on a port and service not exposed by ingress.
metrics:
enabled: true
port: 9200
# If enabled, the service selectors will include `app.kubernetes.io/instance: {{ .Release.Name }}`
# When disabled, services may select Vault pods not deployed from the chart.
# Does not affect the headless vault-internal service with `ClusterIP: None`
instanceSelector:
enabled: true
# clusterIP controls whether a Cluster IP address is attached to the
# Vault service within Kubernetes. By default, the Vault service will
# be given a Cluster IP address, set to None to disable. When disabled
# Kubernetes will create a "headless" service. Headless services can be
# used to communicate with pods directly through DNS instead of a round-robin
# load balancer.
# clusterIP: None
```
**Describe alternatives you've considered**
Right now I add my own service:
```hcl
# Kubernetes Service Resource
# https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/service_v1
resource "kubernetes_service_v1" "vault_metrics" {
metadata {
name = "vault-metrics"
namespace = kubernetes_namespace_v1.vault_enterprise.metadata[0].name
}
spec {
cluster_ip = "None"
selector = {
"app.kubernetes.io/instance" = "vault"
"app.kubernetes.io/name" = "vault"
"component" = "server"
}
port {
name = "metrics"
port = 9200
target_port = 9200
}
}
}
```
And setup my listeners like this in the chart:
```hcl
# Helm Release
# https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release
resource "helm_release" "vault_enterprise" {
chart = "vault"
name = "vault"
namespace = kubernetes_namespace_v1.vault_enterprise.metadata[0].name
repository = "https://helm.releases.hashicorp.com"
timeout = 600
set {
name = "server.ha.raft.config"
value = <
Contributor guide
Research direction
Start with the chart's values section for the existing active, standby, and headless services, then inspect the corresponding Helm service templates. Confirm how a metrics service should select Vault pods and expose the configured port without ingress. Done means the values option renders the requested service for the described metrics listener.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes, yaml
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100