Support Helm values for installation settings currently requiring post-renderers #64

Context

Several installation settings require Helm post-renderer patches rather than supported chart values. Exposing these settings would simplify installation and upgrades and reduce dependence on the chart's manifest structure.

Some requirements may already be addressed in newer versions or ongoing PRs; this issue provides an umbrella checklist.

Requirements and configuration examples

• Use externally managed ServiceAccounts.
  Support operator-managed accounts with workload-identity annotations. Provide create/use-existing controls and configurable names, keeping Pod references, RBAC subjects, and identity-related arguments consistent.

• Configure ServiceAccount token mounting.
  Allow dedicated accounts and automountServiceAccountToken: false for components that do not need automatically mounted Kubernetes API credentials, such as PostgreSQL, RustFS, and bucket-init. Preserve explicit certificate-agent token projections.

• Configure atelet placement.
  Expose node selectors, affinity, and additional tolerations for installations using dedicated workload nodes. Preserve the existing ate.dev/sandboxClass toleration.

• Configure atelet security settings.
  Expose container settings such as privileged and allowPrivilegeEscalation, preserving existing defaults and required capabilities. This does not imply rootless support.

• Configure resources for chart-managed containers and Jobs.
  Expose CPU, memory, and applicable ephemeral-storage requests/limits for containers that lack configuration, including sidecars, init containers, and bucket-init. PostgreSQL already exposes resources.

• Configure API environment variables and references.
  Add API extraEnv and extraEnvFrom, including Secret/ConfigMap references. For example, an operator should be able to supply AWS_REGION without patching the Deployment. Atelet already supports extraEnv.

• Configure API volumes and mounts.
  Support additional volumes and volume mounts. A concrete use case is mounting an operator-managed database CA bundle from a ConfigMap.

• Configure external PostgreSQL without exposing passwords through Helm.
  Support PGHOST, PGPORT, and PGDATABASE through ConfigMap references and PGPASSWORD through a Secret reference, together with a mounted CA and sslmode=verify-full. Avoid passwords in Helm values or generated ConfigMaps. Basic external database selection already exists.

• Protect API startup while the database becomes ready.
  Expose a configurable startup probe, for example on /readyz:9090, to accommodate database and migration startup before liveness checks begin. Where bundled PostgreSQL is supported, allow an optional database-wait init container that verifies a TLS connection rather than only checking an open TCP port.

• Configure recovery probes for chart-managed certificate agents.
  For installations that use chart-managed certificate agents, expose startup, readiness, and liveness settings. For example, allow a liveness probe on the agent's HTTP endpoint while retaining startup protection for initial issuance.

• Configure certificate-file permissions and compatible UID/GID settings.
  Expose credential-file mode and compatible process identity settings. For example, support appropriately owned private keys with file mode 0600 to meet libpq's requirements.

• Configure the router's parked-request budget.
  Expose the supported request-parking timeout/budget so installations can accommodate slower cold starts without changing the normal default.

• Pin individual component images by digest.
  Support independent image references/digests for chart-managed components and repeated init-container images, while keeping existing global registry settings coherent.

• Disable the default gVisor SandboxConfig.
  Allow omitting the chart-created gvisor-default when an operator manages runtime configuration independently. This should not remove gVisor support.

• Reuse the certificate-controller namespace without Helm ownership.
  Where the chart uses a separate controller namespace, support an existing, operator-managed namespace without attempting to create or adopt it.

Scope and expected outcome

These requests concern Helm values and chart-rendered resources. Workload-identity provisioning, controller-generated worker configuration, and certificate-renewal scheduling are separate concerns.

The certificate-agent examples apply only where agent-based credential delivery is used; they do not imply that native PodCertificate installations need additional agents.

The goal is to replace post-renderer patches with supported values while preserving existing defaults. Existing PRs can be associated with checklist items, and remaining changes can be implemented through small, focused PRs.