Description of the problem: When there is a unique secret for each managed cluster on the hub, how do you copy each secret from the hub in a source namespace with a specific name to a selected managed cluster in a different namespace with a different name. Release version: 2.3 Operator snapshot version: OCP version: 4.8.13 Browser Info: N/A Steps to reproduce: 1. Create 20 managed clusters named user01-user20 2. Create a unique secret on the hub for each cluster 3. Copy each secret from the hub to the managed cluster in the proper namespace with the right name Actual results: No option Expected results: Each cluster specific secret should be on the managed cluster in the right namespace with the desired name. If I have one namespace on the hub "workshop-secrets" with secrets for each managed cluster "dashboard-env-user01"-"dashboard-env-user20", copy each secret to the managed cluster into namespace "lab-ocp-cns" with the name "dashboard-env". Alternatively, and maybe more applicable for users, we could have the secrets in the cluster namespace on the hub to control access by cluster vs by project. Such as the hub would have a secret named "dashboard-evn" in the "user01"-"user20" namespaces. So any variation of namespaceA.nameB for the secret on the hub will result in a namespaceC.nameD on the cluster. Where there needs to be a way to select what source maps to what cluster. Maybe have the secret have a specific label or annotation to key off like subscriptions use for filtering. Additional info:
The namespace subscription for copying secrets from hub to managed clusters are being deprecated. However, this could be a good user input to enhance policy to enhance its secret management capabilities in the future. Daniel is currently working around the problem with the namespace secret subscription by creating a unique channel/subscription/placementrule for each managed cluster to copy the cluster specific password.
Reassigning to product mgmt to prioritize as part of the GRC & policy roadmap.
Comment from Yu Cao: This issue will be addressed in 2.5 by https://issues.redhat.com/browse/ACM-1043
Already verified the feature https://issues.redhat.com/browse/ACM-1043 in 2.5.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Red Hat Advanced Cluster Management 2.5 security updates, images, and bug fixes), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:4956
This comment was flagged a spam, view the edit history to see the original text if required.
I like the way you made this article. Short but juicy. Thanks for sharing! https://www.catneedsbest.com/
thanks for sharing. https://www.lasrslogin.online/