feat: Add extra secret manifests support

[tejisin]

feat: Add extraSecretManifests for native SOPS & Secret management

what

• New Feature: Added extra-secret-manifests.yaml template to the chart.
• Schema Update: Updated values.schema.json to support and validate the new extraSecretManifests field.
• Capability: Enables users to define and deploy arbitrary Kubernetes Secret resources directly via the chart. This is specifically designed to unlock workflows using SOPS encrypted secrets adjacent to the deployment.
• Impact: Zero impact on existing users; this is a purely additive feature.

why

• First-Class SOPS Support: This change allows users to manage secrets securely using SOPS right alongside their chart values.
• Enhanced Security:
  • By using a dedicated Secret manifest, users can configure SOPS to only encrypt the data key.
  • Solves the stringData vulnerability: Using stringData for secrets causes the plaintext value to be stored in the last-applied-configuration annotation (see HackerOne Report). This approach avoids that entirely by using standard data fields.
• Clean Separation of Concerns:
  • Avoids Collisions: Using the existing extraManifests for secrets forces encryption on everything in the file (including ConfigMaps), which is often undesirable.
  • Prevents Integrity Errors: SOPS injects a file hash into the metadata. If ConfigMaps were mixed with Secrets and modified outside SOPS, the hash validation would fail. This dedicated template ensures SOPS integrity checks only apply where they matter.

tests

• I have tested my changes by running helm template with various configurations:

helm template . \
  -f values.yaml \
  -f path/to/my-sops-secrets.yaml \
  > rendered.yaml

• Result: The chart renders perfectly with extraSecretManifests provided.
• Regression: Confirmed that the chart renders exactly as before when the new value is omitted.

references

• Mozilla SOPS (Secrets OPerationS)
• Kubectl apply reveals secrets in last-applied-configuration

---

Example SOPS Configuration

For reviewers/users, a minimal sops.yaml to leverage this feature effectively:

creation_rules:
  - encrypted_regex: '^(data)$'
    version: 3.11.0

[pseudomorph]

@GMartinez-Sisti - Apologies for the ping here, is anything needed here to get this merged in?

[DrFaust92]

why do we need this and just use extraManifests? there is no added value for this

[tejisin]

why do we need this and just use extraManifests? there is no added value for this

as mentioned under clean separation of concerns under Why, mixing non secret and secret resources under extraManifests would lead to integrity errors for the sops checksum if a value for another manifest was changed outside of the sops flow. Also the fact that configmaps and secrets use the same fields for storage (data/stringData) which would lead to configmaps getting encrypted as well if colocated.

[jamengual]

@tejisin can you look into lint errors?

[tejisin]

@jamengual that failure seems to be because of the bump to helm 4 in this PR https://github.com/runatlantis/helm-charts/pull/509/files

first failure of that sort was https://github.com/runatlantis/helm-charts/actions/runs/19564551798/job/56023450752#step:8:17 3 weeks ago.

Here's an issue talking about it helm/helm#31490. The quick fixes obviously for now are downgrading to latest helm v3 or trying the verify=false flag.