networkPolicy: make blockCloudMetadataEgress opt-out discoverable

[JatinNanda]

problem

networkPolicy.blockCloudMetadataEgress (added in 6.11.9) auto-enables whenever blob storage is keyless — detected as "no static credential set." That heuristic is an over-approximation:

• token-federated identities (EKS IRSA, GKE Workload Identity, Azure Workload Identity) get creds from a projected token + the provider STS/IAM endpoint, never 169.254.169.254 → safe to block ✅
• metadata-based identities (EC2 instance profile, GCE default service account, Azure IMDS-based managed identity) also have "no static credential," but they fetch creds from 169.254.169.254 → the auto-block silently breaks blob storage ❌

The two helpers even contradict each other: retool.blobStorage.keyless lists "instance profile" as a keyless mode, while retool.networkPolicy.blockMetadata.enabled asserts keyless "never [uses] the metadata service." The values comment only warned about data sources using the metadata endpoint, not blob-storage auth itself — so an instance-profile user gets no signal.

approach

Per discussion, don't try to detect the auth form (fragile). Keep the auto-enable as-is and just make the opt-out impossible to miss:

• NOTES.txt — print a note on install only (.Release.IsInstall, so it doesn't nag on every helm upgrade) when the block is active: no-op for IRSA/WI, but if blob storage uses instance profile / default SA / IMDS managed identity, set blockCloudMetadataEgress: false.
• values.yaml — fix the comment (the STS/IAM claim only holds for token-federated auth) and spell out exactly when to set false. Applied to both synced copies.

No behavior change to the auto-enable — discoverability only.

verification

helm install … (keyless)  -> NOTES block shown
helm upgrade … (keyless)  -> silent (install-only gate)
static-credential install -> block + NOTES both absent

NetworkPolicy still renders and denies 169.254.169.254/32 for keyless. helm lint clean; both values.yaml copies in sync.

Chart bumped 6.11.9 -> 6.11.10.

follow-up (not in this PR)

The docs already carry the same opt-out guidance (tryretool/docs#2997). Longer term, the robust fix is to gate auto-enable on a positive federated-identity signal (IRSA annotation / WI label) rather than absence of a static key — but that's a behavior change for a separate discussion.

[greptile-apps]

Greptile Summary

This PR makes the metadata-egress opt-out easier to discover.

• Bumps the Retool Helm chart from 6.11.9 to 6.11.10.
• Adds an install-only NOTES warning when metadata egress blocking is active.
• Clarifies the blockCloudMetadataEgress guidance in both values files.

Confidence Score: 5/5

This looks safe to merge after a small cleanup to the install note wording.

• The new note uses the same helper as the NetworkPolicy render path.
• The values comments are synced across both copies.
• The chart version bump matches the changed chart package.
• The only issue found is a misleading note for forced-on static-credential installs.

charts/retool/templates/NOTES.txt

Important Files Changed

Filename	Overview
charts/retool/Chart.yaml	Bumps the chart patch version with no dependency or app version changes.
charts/retool/templates/NOTES.txt	Adds an install-only note for active metadata-egress blocking, with one wording issue for forced-on static-credential installs.
charts/retool/values.yaml	Updates the blockCloudMetadataEgress comment to distinguish token-federated and metadata-based identities.
values.yaml	Mirrors the chart values comment update.

_{Reviews (1): Last reviewed commit: "networkPolicy: make blockCloudMetadataEg..." | Re-trigger Greptile}