feat: add ack-secretsmanager-controller

[tim-stasse]

No description provided.

[strangiato]

This should probably include the creation of the namespace

[tim-stasse]

Namespace creation is in ack-system folder, which this depends on. I'm simply following the existing convention from ack-s3-controller, etc

[strangiato]

Should the secret be included in the resources so it gets created, or is the intention just to show an example of the secret?

If it is intended to just be an example, can we add example to the name of the yaml file?

[tim-stasse]

Same as above, this is simply a copy-paste from ack-s3-controller. Happy to add example to the name if there's strong opinions.

[strangiato]

If this secret is intended to be added to the resources list, we should consider adding the namespace: ack-system to the kustomize file as well.

[gferreir]

A few observations to complement @strangiato's review, including one where digging into the actual repo structure uncovered something worth clarifying:

ack-system/instance is not a kustomize dependency of this PR — namespace creation requires a separate step

@tim-stasse's response that "namespace creation is in ack-system folder" is correct, but looking at the actual structure: the namespace is created in ack-system/instance/namespace.yaml, not in ack-system/base. The PR's base kustomization only references ../../../ack-system/base, which contains only the shared ConfigMap — no Namespace resource:

# ack-system/base/kustomization.yaml (main)
resources:
  - user-config-cm.yaml   # only this — no namespace creation here

# ack-system/instance/namespace.yaml (main) — not referenced by this PR
kind: Namespace
metadata:
  name: ack-system

Applying this PR on a cluster where ack-system/instance has not been applied will fail with namespace "ack-system" not found. The README should document this as an explicit prerequisite step. (The same gap exists in ack-s3-controller's README, so this is a repo-wide pattern worth addressing, but it's worth documenting here regardless.)

user-secrets-secret.yaml is missing namespace: ack-system — differs from ack-s3-controller

The PR description mentions following ack-s3-controller as the reference. Comparing the equivalent Secret files, ack-s3 has the namespace explicitly set in metadata:

# ack-s3-controller/operator/overlays/alpha/user-secrets-secret.yaml (main)
metadata:
  name: ack-s3-user-secrets
  namespace: ack-system   ← present

# PR #413: ack-secretsmanager-controller/operator/overlays/alpha/user-secrets-secret.yaml
metadata:
  name: ack-secretsmanager-user-secrets
                          ← missing

The namespace: ack-system set in ack-system/base/kustomization.yaml only applies to resources declared within that kustomization (the ConfigMap), so it does not propagate to the Secret in the overlay. Adding namespace: ack-system directly to the Secret metadata would align this file with the stated baseline, regardless of whether it ends up in the resources list or stays as a standalone example.

No credential management guidance in the README

user-secrets-secret.yaml uses stringData with AWS credential placeholders. The README doesn't include any note warning against committing real credentials, nor does it suggest an alternative (External Secrets Operator, SealedSecrets, Vault). For a GitOps catalog targeting enterprise OpenShift environments, a short note pointing users toward a secret management solution would be a useful addition.