[DO NOT MERGE] Make AppArmor profile names configurable for multi-tenant testing

[mertbozfakioglu]

Add codeExecutor.appArmorProfile and rr.agentSandbox.appArmorProfile
values so profile names can be overridden per-release. This prevents
collisions on shared clusters (e.g. balloon instances) where multiple
tenants install AppArmor profiles on the same nodes.

Seccomp paths were already configurable via seccompLocalhostProfile
and seccompProfile values. Defaults are unchanged (retool-executor
and retool-agent-sandbox).

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

[mertbozfakioglu]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [DO NOT MERGE] Make AppArmor profile names configurable for multi-tenant testing #372 👈 (View in Graphite)
• Restrict mount/pivot_root/userns to nsjail via AppArmor profile transition #371
• Add seccomp profile generator with CI verification #370
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 3/5

The PR is not yet safe to merge because its unrestricted profile-name contract can produce invalid or altered installer behavior, and the missing root-values updates deterministically fail the synchronization gate.

The profile wiring is internally consistent for safe names, but arbitrary documented overrides cross incompatible YAML, AppArmor, path, and shell contexts without validation; independently, both new public values are absent from the byte-for-byte synchronized root values file.

Files Needing Attention: charts/retool/values.yaml, values.yaml, charts/retool/templates/apparmor_nsjail_daemonset.yaml, charts/retool/templates/agent_sandbox_seccomp.yaml

Important Files Changed

Filename	Overview
charts/retool/values.yaml	Adds both profile-name settings, but omits input constraints, synchronized root values, and override-focused test coverage.
charts/retool/templates/apparmor_nsjail_configmap.yaml	Applies the configurable executor name consistently throughout the AppArmor policy, but assumes the value is safe as both a YAML key and policy identifier.
charts/retool/templates/apparmor_nsjail_daemonset.yaml	Uses the configurable name for installation and readiness paths, including unquoted interpolation in a privileged shell script.
charts/retool/templates/agent_sandbox_seccomp.yaml	Propagates the agent-sandbox profile name through the node installer, with the same unrestricted shell interpolation concern.
charts/retool/templates/deployment_agent_sandbox.yaml	Keeps the sandbox readiness marker and Localhost profile reference aligned with the configured name.
charts/retool/templates/deployment_code_executor.yaml	Keeps the code-executor annotation and readiness wait aligned with the configured profile name.
charts/retool/templates/deployment_js_executor.yaml	Keeps the JavaScript-executor annotation and readiness wait aligned with the shared executor profile name.
charts/retool/Chart.yaml	Correctly increments the chart package version for the changed configuration contract.

_{Reviews (1): Last reviewed commit: "Make AppArmor profile names configurable..." | Re-trigger Greptile}

[greptile-apps]

Profile Names Are Unrestricted

This setting accepts any string, but the templates insert it directly into ConfigMap keys, AppArmor declarations, filesystem paths, and unquoted commands run by the privileged installer. For example, a hierarchical name such as tenant/retool-executor can be valid as an AppArmor-style name but invalid as a ConfigMap key, while whitespace or shell metacharacters can break or alter the loader command. Validate the value as a safe filename and profile token before exposing it as configurable; the agent-sandbox setting has the same issue.

Knowledge Base Used:

• Network and sandbox security
• Values and template conventions

[greptile-apps]

Root Values Remain Unsynchronized

The new codeExecutor.appArmorProfile and rr.agentSandbox.appArmorProfile settings were added only to the chart-local values file. The root values.yaml lacks both settings, while the pull-request workflow performs a byte-for-byte diff between these files. As a result, this PR will fail the values-synchronization check, and the customer-facing configuration reference will omit the new feature.

Knowledge Base Used:

• CI and values synchronization
• Values and template conventions

[greptile-apps]

Overrides Lack Test Coverage

Neither AppArmor validation scenario sets a non-default profile name, and the runtime integration test remains hardcoded to the defaults. This leaves the new override path—including the ConfigMap key, profile declaration, loader path, readiness marker, and pod profile reference—untested, so a future mismatch could escape CI. Add non-default names to the existing AppArmor scenarios to cover this new cross-resource contract.

Knowledge Base Used:

• Helm validation coverage
• Network and sandbox security

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!