Object storage (linode): source accessKeyId from obj-secrets like secretAccessKey, so key rotation needs no git write

[aweingarten]

Summary

The linode object-storage provider sources the two halves of the S3 credential asymmetrically: secretAccessKey is read from the obj-secrets Secret (great — an operator can populate it via ESO and rotate freely), but accessKeyId is inlined from git settings. Because Linode OBJ keys rotate as a pair, this forces any operator that rotates keys to write the new accessKeyId back into the values git repo on every rotation — carrying a non-secret identifier through git solely because its paired secret is handled cleanly.

Request: let accessKeyId also be sourced from obj-secrets (or a native Secret), symmetric with secretAccessKey.

Current behavior (apl-core v6.0.0)

From the templating:

values/loki/loki-raw.gotmpl

AWS_ACCESS_KEY_ID:     {{ $obj.linode.accessKeyId }}                 # inlined from env/settings/obj.yaml (git)
AWS_SECRET_ACCESS_KEY: '{{ "{{ .secretAccessKey | toString }}" }}'
  - secretKey: secretAccessKey
    remoteRef:
      key: obj-secrets                                              # from the obj-secrets Secret (ESO-friendly)
      property: provider_linode_secretAccessKey

values/harbor/harbor-raw.gotmpl does the same (S3_STORAGE_ACCOUNT / REGISTRY_STORAGE_S3_ACCESSKEY ← {{ $obj.linode.accessKeyId }}; secret ← obj-secrets.provider_linode_secretAccessKey).

And env/settings/obj.yaml (AplObjectStorage) carries spec.provider.linode.accessKeyId as a plain setting (schema additionalProperties: false, so the secret half is deliberately kept out).

Why it's a problem

A managed-App-Platform operator that provisions and rotates the OBJ access keys out-of-band (our case: Linode Landing Zone) can deliver secretAccessKey into obj-secrets via ESO/OpenBao and rotate with zero git writes — exactly right. But because accessKeyId is git-inlined and a rotation mints a new pair, the operator must also push the new accessKeyId into the values repo each rotation to keep it paired. That forces a git-sync reconciler holding a Contents: write token — a lot of moving parts to carry a non-secret identifier that changes on the same cadence as the secret already handled cleanly.

Proposed options

1. Extend the obj-secrets contract: add a provider_linode_accessKeyId property and template AWS_ACCESS_KEY_ID from it (mirroring secretAccessKey). Operators populate one Secret with both keys via ESO; no git writes on rotation.
2. Optional secret ref: add spec.provider.linode.accessKeyIdSecretRef (nativeSecrets-style). When set, source accessKeyId from the referenced Secret; otherwise fall back to the inline settings value (fully backward compatible).

Either makes the two halves of the credential rotate together through one ESO-managed Secret, and lets external operators drop the git-write token + reconciler they otherwise need only for the access-key id.

Environment

• apl-core v6.0.0 (managed App Platform / apl-operator 1.16.0)
• Provider: linode; consumers observed: Loki, Harbor (same pattern in gitea/keycloak/kubeflow-pipelines -raw.gotmpl)

[j-zimnowoda]

Thanks for suggestion. It makes perfect sense to keep the id and token all together.

[aweingarten]

Opened #3466 for this — option 1 from the description, following @j-zimnowoda's agreement above.

obj.provider.linode.accessKeyId gains x-secret: '' so it lands in obj-secrets as provider_linode_accessKeyId via the existing sealed-secret machinery (no new contract — the key name comes from the same path→underscore rule that produces provider_linode_secretAccessKey), and all six consumers template it from there instead of inlining it: loki, harbor ×2, gitea, keycloak, kubeflow-pipelines.

One open question for reviewers, flagged in the PR: whether any supported topology has accessKeyId living only in the values repo and never in VALUES_INPUT/stored cluster secrets. If so it needs a values-changes.yaml entry to relocate the value on upgrade — happy to add one.