feat: add config.secretKeys to selectively include secrets

[pierluigilenoci]

Summary

This PR implements the config.requiredSecretKeys option to provide granular control over which secrets are included in the Kubernetes secret and exposed as environment variables.

Problem

When using authentication methods like Azure Entra ID federated token authentication, the client-secret is not required. However, the chart currently always includes and requires all three secrets (client-id, client-secret, cookie-secret), causing issues when using proxyVarsAsSecrets: true with existingSecret.

Solution

Added a config.requiredSecretKeys list that allows users to explicitly specify which secrets to include:

config:
  requiredSecretKeys:
    - client-id
    - cookie-secret
    # client-secret excluded

Implementation Details

Following maintainer feedback, the implementation now uses:

1. values.yaml: config.requiredSecretKeys list with explicit defaults:

   requiredSecretKeys:
     - client-id
     - client-secret
     - cookie-secret

2. _helpers.tpl: Modified oauth2-proxy.secrets template to conditionally include secrets based on the list
3. deployment.yaml: Modified environment variable section to conditionally set vars based on the list

Default Behavior (Backward Compatible)

The defaults are now explicitly defined in values.yaml:

requiredSecretKeys:
  - client-id
  - client-secret
  - cookie-secret

This ensures full backward compatibility with existing deployments while making the configuration more explicit and easier to understand.

Usage Examples

Scenario 1: Default (all secrets)

config:
  requiredSecretKeys:
    - client-id
    - client-secret
    - cookie-secret

→ Includes all three secrets (default behavior)

Scenario 2: Exclude client-secret (federated auth)

config:
  requiredSecretKeys:
    - client-id
    - cookie-secret

→ Includes only client-id and cookie-secret

Scenario 3: Custom subset

config:
  requiredSecretKeys:
    - cookie-secret

→ Includes only cookie-secret

Benefits

• ✅ User-requested approach: Implements the exact solution proposed by the issue author
• ✅ Backward compatible: Explicit defaults maintain current behavior
• ✅ Future-proof: Extensible for additional secrets
• ✅ Explicit control: Clear which secrets are being used
• ✅ Flexible: Works with both chart-managed and existing secrets
• ✅ Follows Helm best practices: Defaults defined in values.yaml rather than templates

Changes Based on Maintainer Feedback

• Renamed secretKeys to requiredSecretKeys for clarity
• Moved default values from template (| default) to explicit defaults in values.yaml
• Simplified template logic by removing fallback conditions

Testing

Tested with helm template to verify:

• ✅ Secrets are created with all three keys by default
• ✅ Secrets can be selectively excluded
• ✅ Environment variables are only created for included secrets
• ✅ Backward compatibility is maintained

Checklist

• Chart version bumped to 10.1.0 (minor version for new feature)
• Changelog updated in Chart.yaml
• Template logic simplified following maintainer feedback
• Defaults moved to values.yaml
• DCO sign-off included in all commits
• Zero breaking changes confirmed via testing

Fixes #376