Support sourcing `apisix.vault.token` from a Kubernetes Secret

Open Beginner friendly
#988 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
helm, kubernetes

Research direction

Start with values.yaml and templates/configmap.yaml, then compare how apisix.admin.credentials.secretName is handled. Verify the chart’s rendered resources when a Vault secretName is configured and when only token is provided. Done means an existing Kubernetes Secret can supply the configured key without writing the token into the ConfigMap.

Written by the indexing model from the issue text.

Description

Currently apisix.vault.token is taken verbatim from values.yaml and written in plaintext into the apisix-<release>-config ConfigMap:

# templates/configmap.yaml
{{- if .Values.apisix.vault.enabled }}
vault:
  host: {{ .Values.apisix.vault.host }}
  timeout: {{ .Values.apisix.vault.timeout }}
  token: {{ .Values.apisix.vault.token }}   # plaintext token into ConfigMap
  prefix: {{ .Values.apisix.vault.prefix }}
{{- end }}

There's no way to provide the Vault token via an existing Kubernetes Secret — it must live in values.yaml (and therefore in the Helm release / Rancher app config / git).

The chart already offers a secretName option for the admin API credentials (apisix.admin.credentials.secretName). It would be helpful to have an equivalent for the Vault token, e.g.:

# values.yaml
vault:
  enabled: false
  host: ""
  timeout: 10
  token: ""
  prefix: ""
  secretName: ""          # existing Secret containing the token
  secretKey: "token"     # key inside that Secret

When secretName is set, the chart would source the token from that Secret rather than from the plaintext token field.

Dominant language
Go Template
Stars
289
Forks
284
Avg merge
4d 22h
Merged PRs (30d)
2

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/apisix-helm-chart

All issues in apache/apisix-helm-chart

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.