ssm-controller: manage a Parameter without overwriting its Value (ignore_changes / initProvider equivalent for SecureString)

[keretdodor]

Is your feature request related to a problem?

Yes. We're migrating hundreds of SSM parameters from click-ops to GitOps (KRO + ACK). For SecureString parameters the values are created/rotated out-of-band (by a human). We need ACK to own the parameter's existence and lifecycle — create it if missing, adopt it if it already exists, and apply a deletion policy — while never reading or overwriting its Value: the plaintext must not live in git, and the live secret must never be clobbered by a reconcile.

Today this isn't possible, because management of a Parameter is all-or-nothing:

• Parameter.Value has no is_ignored / late_initialize / is_secret config, and hooks/parameter/sdk_update_post_build_request.go.tpl forces Overwrite=true. So Value is always part of desired state and always enforced, and drift remediation (~10h) reverts any out-of-band value change back to the spec value.
• The only user-facing knobs — adoption-policy (adopt / adopt-or-create), deletion-policy, and read-only — are whole-resource, not field-scoped.

We verified the behavior on ssm-controller v1.3.1 (EKS) with throwaway parameters:

Approach	Result
adoption-policy: adopt (+ adoption-fields)	Adopts an existing param and leaves the value untouched ✅ — but cannot create a missing one ❌
adoption-policy: adopt-or-create	Creates missing params ✅ — but overwrites/reverts the value ❌ (we set a real value via the console; the next reconcile reverted it to the spec value)
read-only: "true"	Never touches the value ✅ — but never creates or manages it either ❌

So there is no single configuration that does create-or-adopt + own lifecycle + never manage Value.

Describe the solution you'd like

A user-facing, per-resource way to exclude a field (here spec.value) from drift enforcement while still creating/adopting/deleting the resource. Any one of these would solve it:

1. Create-only / init-time field semantic — the field is applied on create but never reconciled afterwards (equivalent to Crossplane initProvider).
2. Per-resource "ignore fields" annotation — e.g. services.k8s.aws/ignore-fields: "spec.value" — the controller skips those paths in delta/enforcement (equivalent to Terraform lifecycle { ignore_changes = [value] }).
3. Granular management policies — a per-resource action allow-list, e.g. Observe, Create, Delete without Update (equivalent to Crossplane managementPolicies).

For ssm-controller specifically, option 1 or 2 applied to Value — ideally treating a SecureString Value as write-only-on-create — would fully solve our use case.

Describe alternatives you've considered

• adoption-policy: adopt — safe for existing secrets (value untouched) but can't create new ones, forcing a manual out-of-band pre-create step for every new secret.
• adoption-policy: adopt-or-create — creates new ones but overwrites the value and reverts out-of-band edits on the next reconcile.
• read-only: "true" — never modifies the value but also never creates or manages the resource.
• "Manage the name/metadata but not the value" (e.g. tags-only) — not possible: SSM PutParameter requires a value, and ACK always sends and enforces it.
• Other IaC tools already support exactly this: Terraform lifecycle { ignore_changes = [value] }, and Crossplane initProvider (create-only fields) + managementPolicies (action allow-list). Both let you own the resource without ever writing the secret into state/git.
• Related (codegen-level) request: Ability to ignore specific fields in the API #510 — "Ability to ignore specific fields in the API". This request is for a runtime, user-facing equivalent.

Environment: ssm-controller v1.3.1, EKS, KRO-generated Parameter CRs.

---

Suggested labels (I don't have permission to set them): kind/enhancement, service/ssm, area/runtime, area/adopted-resource

[github-actions]

Hello @keretdodor 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[Tomer9000]

This is very critical for us also.

[gatmbarz123]

Also for us , need that fix 🙏🏻🙏🏻

[sapphirew]

Hi @keretdodor, thanks for the detailed write-up, and thanks @Tomer9000 @gatmbarz123 for the +1s.

We're actively working on your option 2. There's a feature in flight that adds the annotation you described, services.k8s.aws/ignore-field-drift: "spec.value", which tells the controller to stop reconciling drift on the named fields while still creating, adopting, and deleting the resource. It's gated behind a new SelectiveReconciliation feature gate (Alpha, off by default).

In-flight PRs:

• Runtime: feat(runtime): add ignore-field-drift annotation for selective field reconciliation runtime#256
• Code-generator: feat: filter ignore-field-drift differences from generated resource delta code-generator#714

Combined with adoption-policy: adopt-or-create, this should cover your case: the parameter is created or adopted and managed, but out-of-band Value changes are no longer reverted. One note: the field is still applied once at create, so the supported pattern is create-then-ignore or adopt an existing parameter.

The feature is still pre-release. I'll follow up here once the changes merge and release, along with the ssm-controller version that picks them up.

[keretdodor]

@sapphirew , Any idea when the new feature will be released? This issue is very argunt for our team.