Our Helm charts should default to taking API keys (Management API, Consumer Proxy API) from the Vault using an alias, and only use raw values as fallback.
For example, for the Management API key, this would look roughly like this (pseudocode):
{{- if .Values.controlplane.endpoints.management.apiKey }}
- name: "EDC_API_AUTH_KEY"
value: {{ .Values.controlplane.endpoints.management.apiKey }}
{{- else if .Values.controlplane.endpoints.management.apiKeyAlias }}
- name: "EDC_API_AUTH_KEY_ALIAS"
value: {{ .Values.controlplane.endpoints.management.apiKeyAlias }}
{{- else }}
{{- required "Must either provider an API key or an API key alias!" "" }}
{{- end}}
WHY
Providing hard-coded API keys is not a great idea for several reasons:
rotating them requires a re-deployment (upgrade) and a restart of the application
secrets should always be stored in a Vault
configuration values are visible at application runtime, which could cause a potential secure information leak if not used properly (e.g. K8S secrets)
WHAT
Our Helm charts should default to taking API keys (Management API, Consumer Proxy API) from the Vault using an alias, and only use raw values as fallback.
For example, for the Management API key, this would look roughly like this (pseudocode):
WHY
Providing hard-coded API keys is not a great idea for several reasons:
HOW
// if possible, outlines a solution proposal
FURTHER NOTES
// anything else you want to outline
_Please be sure to take a look at our contribution guidelines and our PR etiquette._