fix(shield): warn when Sysdig credentials are supplied inline (helm release metadata exposure)

[EdwardArchive]

Fixes #2622

Summary

When sysdig_endpoint.access_key or sysdig_endpoint.secure_api_token is passed through values, the chart base64-encodes them into a Secret manifest. The rendered manifest — including the secret values — is then persisted by Helm in its release storage:

$ kubectl get secret -n <release-ns> sh.helm.release.v1.<release>.v<rev> -o yaml
data:
  release: <gzip+base64 of the entire rendered manifest, including the credentials>

…and is retrievable via helm get values --all, helm get manifest, or any GitOps tool that snapshots rendered manifests. This broadens the blast radius of the credential beyond the application Secret itself, but the trade-off was not documented and users hit it silently.

The chart already supports access_key_existing_secret / secure_api_token_existing_secret references — users pre-create a Secret out-of-band (Vault, External Secrets, SOPS, sealed-secrets) and the chart just references it.

What this PR does NOT change

The Secret rendering itself. Inline values continue to work for users who prefer them — this is purely a guidance / observability change.

Changes

• templates/NOTES.txt — new conditional block that fires only when at least one credential was supplied inline. Lists the affected key(s), explains the Helm release-metadata exposure, shows the recommended pattern, and links back to [Security] credentials-secret.yaml stores access_key / secure_api_token in Helm release metadata as plaintext (base64); prefer *_existing_secret pattern #2622 for context.
• values.yaml — stronger comments on access_key, access_key_existing_secret, secure_api_token, secure_api_token_existing_secret flagging the trade-off and marking the existing-secret variants as the recommended path for production.
• README.md — corresponding row updates.
• tests/common/notes_credentials_warning_test.yaml — 5 helm-unittest cases:
  • access_key inline → notice emitted, access_key bullet listed
  • secure_api_token inline (access_key via existing) → notice emitted, only secure_api_token bullet listed
  • both inline → both bullets listed
  • both via existing_secret → notice suppressed
  • access_key inline + secure_api_token via existing → notice emitted, only access_key bullet listed
• Chart.yaml — bump to 1.37.2.

Test plan

• helm unittest --strict -f tests/common/notes_credentials_warning_test.yaml charts/shield → 5/5 passed
• Existing tests/common/credentials-secret_test.yaml → 4/4 still pass (no rendering change)
• Full chart test suite → 480 passed
• helm install --dry-run against tests/values/base.yaml (inline access_key) → notice rendered with correct bullet
• helm install --dry-run against existing-secret values → notice suppressed

Sample rendered notice:

⚠️  SECURITY NOTICE: Sysdig credentials were supplied inline via values.
  - sysdig_endpoint.access_key

These values are persisted by Helm in its release storage
(`sh.helm.release.v1.testrel.v<rev>` Secret in `sn`)
as base64-encoded plaintext. Anyone with get/list access to that Secret
— or to the output of `helm get values`, `helm get manifest`, or any
GitOps tool that snapshots rendered manifests — can recover them.

For sensitive environments, pre-create a Secret (e.g. via Vault, External
Secrets, SOPS, or sealed-secrets) and reference it instead:

  sysdig_endpoint:
    access_key_existing_secret: my-access-key-secret
    secure_api_token_existing_secret: my-api-token-secret

See https://github.com/sysdiglabs/charts/issues/2622 for context.

Checklist

• Title starts with type and scope (fix(shield):)
• Chart version bumped (1.37.1 → 1.37.2)
• Tests added in tests/ with _test suffix
• README and values.yaml documentation updated

🤖 Generated with Claude Code

[github-actions]

Hi @EdwardArchive. Thanks for your PR.

After inspecting your changes someone with write access to this repo needs
to approve and run the workflow.