Skip to content

feat: Add plugins.install.plugins list and existingSecret support#328

Open
ermeaney wants to merge 1 commit intoopencost:mainfrom
motusllc:feature/plugin-install-list
Open

feat: Add plugins.install.plugins list and existingSecret support#328
ermeaney wants to merge 1 commit intoopencost:mainfrom
motusllc:feature/plugin-install-list

Conversation

@ermeaney
Copy link

Summary

This PR decouples plugin binary downloads from plugin credentials, enabling secure secret management workflows (ExternalSecrets, Vault, etc.).

  • Add plugins.install.plugins list to specify which plugins to download independently of configs
  • Add plugins.existingSecret to use an existing secret instead of creating one from values
  • Maintains full backward compatibility - existing configs-based workflows continue to work unchanged

Problem

The current plugin installation mechanism requires plugin configurations to be defined in plugins.configs for the install script to download the plugin binary. This creates a security issue because:

  1. The install script iterates over plugins.configs to determine which plugins to download
  2. Plugin configs contain secrets (e.g., Datadog API key, App key)
  3. Values files are often committed to git, exposing credentials

This makes it impossible to use Kubernetes ExternalSecrets, Vault, or other secret management tools for plugin credentials.

Solution

New Values

plugins:
  enabled: true
  install:
    plugins:        # NEW: List of plugins to download (independent of configs)
      - datadog
  existingSecret: "my-datadog-plugin-secret"  # NEW: Use existing secret
  # configs not needed - credentials come from existingSecret

Behavior

  • If plugins.install.plugins is set, download those plugins regardless of what's in configs
  • If plugins.install.plugins is empty, fall back to downloading plugins based on keys in configs (legacy behavior)
  • If plugins.existingSecret is set, use that secret instead of creating one from configs
  • If plugins.existingSecret is not set, create the secret from configs (legacy behavior)

Test plan

  • helm lint passes
  • Unit tests added and passing (6 tests)
  • Template rendering verified for new style (existingSecret + install.plugins)
  • Template rendering verified for old style (configs only) - backward compatible

Fixes #327

🤖 Generated with Claude Code

This decouples plugin binary downloads from plugin credentials, enabling
secure secret management workflows (ExternalSecrets, Vault, etc.).

Changes:
- Add plugins.install.plugins list to specify which plugins to download
  independently of configs
- Add plugins.existingSecret to use an existing secret instead of
  creating one from values
- Install script uses install.plugins if set, falls back to configs keys
- plugins-config secret is not created when existingSecret is specified
- Deployment uses existingSecret for volume mount when specified

This maintains full backward compatibility - existing configs-based
workflows continue to work unchanged.

Fixes opencost#327

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
secret:
secretName: {{ template "opencost.fullname" . }}-plugins-config
{{- /* Use existingSecret if specified, otherwise use the generated secret name */}}
secretName: {{ .Values.plugins.existingSecret | default (printf "%s-plugins-config" (include "opencost.fullname" .)) }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you pull this out into a template function? in general, we try to avoid the use of default

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Plugin install script couples binary download to config presence, forcing credentials in Helm values

2 participants