-
Notifications
You must be signed in to change notification settings - Fork 692
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
PR #963 unintentional backwards compatibility break #1091
Comments
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
@josvazg Do you mean drift management ? |
@abdennour can you elaborate what do you mean by drift management in this context? Here we are just proposing to restore compatibility after we added some extra permission requirement that was not there before. The proposed solution is to fail if the missing permission is not allowed, but give the user a way to install by passing a explicit flag so that such permission is not required because secrets will not be watched, as happened in previous versions. |
BTW, I am picking this one up now. |
Which component:
Controller
Describe the bug
PR #963 introduced recreation of deleted secrets managed by the controller. To do that, it needed permissions to watch for secret changes. That new permission breaks in low-privilege / multi-tenant environments, such as the one described in #1064
This issue proposes to recover backward compatibility by gracefully falling back to pre PR #963 behavior when watch secrets permissions are not possible.
To Reproduce
See #1064
Expected behavior
Fail install if lacking permissions, instructing to use a new flag to explicitly skip watching.
The text was updated successfully, but these errors were encountered: