feat: secret copy #741

[docandrew]

Description

• Adds workaround for Zarf issue dev deploy with ###ZARF_REGISTRY### values in helm chart zarf-dev/zarf#2713
• Adds secret copy functionality for issue Secrets manipulation using the UDS Operator #741

Related Issue

Fixes #741

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide followed

[bburky]

This appears to be unprivileged and effectively allows cluster-wide read of any Secrets if you have RBAC permissions of read/write to a Secret in a single namespace. Also, because the name is customizable, this is a bypass of resourceNames RBAC too.

It's reasonable for an app to have runtime read/write secrets in it's own namespace (possibly restricted by resourceNames) , but this would allow reading any secret in the cluster.

There's a few different ways you could address this, but I'd suggest driving it via a CR instead of the Secret resources alone. For example, editing Package resources is privileged (things shouldn't be giving away RBAC to this resource kind), which drives most of this operator and solves the permissions issue.

This is isn't a comment on the feature itself, I have no opinion on it.