-
Notifications
You must be signed in to change notification settings - Fork 517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Enable Copying/Annotation of Generated Secrets to Additional Namespaces #1522
Comments
This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days. |
This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days. |
This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days. |
This issue was closed because it became stale and did not receive further updates. If the issue is still affecting you, please re-open it, or file a fresh Issue with updated information. |
Issue Summary:
Currently, the secrets generated by the CRD are limited to the namespace where the CRD is deployed. It would be beneficial to enable the copying of these secrets to additional namespaces for increased flexibility and usability.
Proposed Solution:
To enable this functionality, additional secret annotations could be exposed in the CRD or inherited from the CRD/StatefulSet. This would allow reflector, replicator or any other annotation-based secret/configMap operator to copy the generated secrets to the specified target namespaces. This enhancement would not only benefit randomly generated
passwordSecretRef
secrets as discussed in #1323 but also generatedconnectionStringSecretName
secrets.I'm willing to contribute to this feature by submitting a PR. I would appreciate guidance on the specific files needing modification to implement this functionality.
This feature would greatly improve the usability of the CRD and enhance its flexibility in various deployment scenarios.
The text was updated successfully, but these errors were encountered: