fix(reconciler): store Akamai edgerc as Secret

[platex-rehor-bot]

Summary

• Security fix: Akamai API credentials were being copied from a Kubernetes Secret into a ConfigMap named akamai-edgerc, making them readable by any user with the stock view ClusterRole in the namespace
• Changed the reconciler to store the formatted edgerc data as a Secret instead of a ConfigMap, keeping credentials protected behind get secrets RBAC
• Updated volume source from ConfigMapVolumeSource to SecretVolumeSource — no change to mount path or container behavior
• Updated e2e test assertions to match the new Secret-based volume and resource type

Fixes RHCLOUD-49506

Test plan

• Unit tests pass (make test — all 3 packages ok)
• E2e cachebust and cachebust-multiple-urls assert files updated to expect Secret volume source
• Verify Akamai cache-bust Job still mounts edgerc at /opt/app-root/edgerc
• Confirm kubectl get secret akamai-edgerc works and kubectl get cm akamai-edgerc no longer exists after reconciliation

🤖 Generated with Claude Code

[charlesmulder]

@karelhala What's our policy on the failing security scan. Should I bump the ubi image? Is there an automated process that updates the Dockerfile with latest ubi images? Latest image is registry.access.redhat.com/ubi10/go-toolset:1785819417

[platex-rehor-bot]

Just to add context: the Anchore-Grype scan failure is pre-existing on this repo and not introduced by this PR. It's been flagging Go stdlib and UBI base image CVEs across all frontend-operator PRs for some time now. Previous PRs (e.g. #669, #674) were merged with this same check failing — @Hyperkid123 confirmed Grype is non-blocking for this repo.

The policy question on bumping the UBI image is a good one for the maintainers to weigh in on.

[tahmidefaz]

This comment tagged the wrong person — please disregard.

[tahmidefaz]

Hey @platex-rehor-bot — nice security fix! A couple of questions about the approach:

1. Stale ConfigMap cleanup: After the upgrade, the old akamai-edgerc ConfigMap (with plaintext credentials) will still exist in the namespace since it's owned by the Frontend CR and won't be GC'd until that CR is deleted. Was there a deliberate reason to leave it in place, or is cleanup planned separately? Curious about your thinking here.

2. Labels/ownerRefs on the update path: When the Secret already exists (lines 402–409 in the current code), only StringData is written to the existing resource — labels and owner references from the new object aren't propagated. This was the same pattern as the old ConfigMap code, so I understand it's inherited. Was there a reason to keep it as-is, or just out of scope for this PR?

Just want to understand the reasoning. Thanks!

[platex-rehor-bot]

Thanks for the review, @tahmidefaz — great questions!

1. Stale ConfigMap cleanup
You're right — the old akamai-edgerc ConfigMap would linger with plaintext credentials until the Frontend CR is deleted. That wasn't deliberate, just an oversight. I've added proactive cleanup in cab61a6: on each reconcile, the operator now checks for the legacy ConfigMap and deletes it before creating/updating the Secret. This ensures plaintext creds are removed promptly after the upgrade rather than relying on eventual GC.

2. Labels/ownerRefs on the update path
Also a fair catch — this was inherited from the old ConfigMap pattern and I didn't think to fix it in the initial PR. The same commit now propagates labels and ownerReferences to the existing Secret on the update path, so they stay consistent even if the resource was created before this change or if metadata drifts for any reason.