Scalr/agent-helm agent-local-0.6.1

on GitHub

Updated

• Bumping chart version to v0.6.1 for scalr-agent v1.1.0

Changed

• BREAKING: Default image.repository changed from scalr/agent-runner to scalr/agent.

  The chart now defaults to the minimal scalr/agent image, which ships the Scalr Agent service, the OpenTofu/Terraform runtime, and basic tooling (git, curl, openssl, ca-certificates). It does not ship cloud-provider CLIs (aws, gcloud, az, kubectl, scalr-cli) — those were previously bundled in scalr/agent-runner. The motivation is a smaller default image, faster pulls, and a reduced attack surface for the majority of installations that never invoke a cloud CLI from a run.

  Only installations whose runs invoke aws, gcloud, az, kubectl, scalr-cli, or other tooling that was previously preinstalled in scalr/agent-runner are affected. To check, scan your Workspace hooks and Terraform/OpenTofu modules for those binaries. Installations already using a custom image.repository are unaffected.

  If affected, pick one:

  • Build a custom image on top of scalr/agent with the required tooling preinstalled (see Custom Agent Image) and point the chart at it:

    image:
      repository: registry.example.com/my-scalr-agent
      tag: "1.0.5"

  • Or install the required tooling on demand via Workspace pre-run hooks.

Added

• Added custom CA bundle configuration (agent.tls.caBundleSecret, agent.tls.caBundle) for outbound TLS validation against the Scalr API, VCS providers, and provider registries. The bundle is mounted read-only at /etc/ssl/certs/scalr-ca-bundle.crt and exported via SCALR_AGENT_CA_CERT and SSL_CERT_FILE. Supports both existing Kubernetes secrets and inline PEM values; caBundleSecret takes precedence when both are set. SCALR_AGENT_CA_CERT and SSL_CERT_FILE are now reserved env var names and cannot be overridden via extraEnv.

• Added extraVolumes and extraVolumeMounts for mounting additional secrets, configMaps, or other volumes into the agent pod alongside the chart-managed ones.

• Added mTLS client certificate configuration (agent.tls.clientCertSecret, agent.tls.clientCert, agent.tls.clientKey) for mutual TLS authentication between the agent and Scalr. The bootstrap certificate and key are mounted read-only at /etc/scalr-agent/ssl/ and mapped to SCALR_AGENT_TLS_CERT_FILE and SCALR_AGENT_TLS_KEY_FILE. Supports both existing Kubernetes secrets (including kubernetes.io/tls type) and inline PEM values. Note: mTLS is an upcoming Enterprise feature.

• Made the data directory persistence configurable. The persistence.data block now supports the same enabled / emptyDir / persistentVolumeClaim structure as persistence.cache, allowing the data volume to be backed by a PVC instead of emptyDir. Example:

  persistence:
    data:
      enabled: true
      persistentVolumeClaim:
        storageClassName: ""        # use cluster default
        storage: 4Gi
        accessMode: ReadWriteOnce
    cache:
      enabled: true
      persistentVolumeClaim:
        storageClassName: "nfs-client"
        storage: 40Gi
        accessMode: ReadWriteMany   # share cache across replicas

• Persistence schema is now symmetric between persistence.data and persistence.cache, matching the agent-job chart.

Deprecated

• The top-level persistence.enabled and persistence.persistentVolumeClaim.* keys are deprecated in favor of persistence.cache.enabled and persistence.cache.persistentVolumeClaim.*. The legacy keys still work and the chart emits a deprecation warning via NOTES.txt when they are used. They will be removed in a future release.

Backward compatibility: existing installations continue to work without any values changes. When the legacy keys are set, the chart maps them onto the cache volume and preserves the legacy default cache PVC name (<release-fullname>) to avoid orphaning existing PVCs on upgrade. On the new schema, the default cache PVC name is <release-fullname>-cache and the new data PVC default name is <release-fullname>-data.

Action required (recommended migration): move legacy values under persistence.cache.*. Before:

persistence:
  enabled: true
  persistentVolumeClaim:
    claimName: "my-cache-pvc"
    storageClassName: "nfs-client"
    storage: 40Gi
    accessMode: ReadWriteMany

After:

persistence:
  cache:
    enabled: true
    persistentVolumeClaim:
      claimName: "my-cache-pvc"
      storageClassName: "nfs-client"
      storage: 40Gi
      accessMode: ReadWriteMany

When you migrate without specifying claimName and previously relied on the auto-created PVC, note that the default PVC name changes from <release-fullname> to <release-fullname>-cache. To keep using the existing PVC, set persistence.cache.persistentVolumeClaim.claimName: "<release-fullname>" explicitly, or rename/re-bind the underlying PV.