hashicorp / hashicorp/vault-helm

Simplify metrics access by supporting an additional service in the chart

Open
#837 0 comments 5 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.