You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While running an export on my single tenant workspace, I was getting failures on exporting the all purpose clusters where the message looked like:
Failed to get cluster ACL: {'object_id': '/clusters/0501-133555-abcdef', 'object_type': 'cluster', 'access_control_list': [], 'http_status_code': 200, 'cluster_name': 'My Cluster'}
When comparing the list of those that failed to our total list of clusters, I noticed that it was all but 2 of the clusters that I was getting this on, so I started inspecting those 2 clusters to see what was different about them. Turns out, my user had explicit CAN_MANAGE permission on them, whereas on all the other ones I only had inherited CAN_MANAGE permissions via the user groups that I am part of. (Including the admin group)
The workaround was of course to explicitly add the CAN_MANAGE permission for my user on all the other clusters. Am I right in thinking that as an admin user, I shouldn't have to do that though?
The text was updated successfully, but these errors were encountered:
@jeff-shuttNH there shouldn't be a need for explicit can_manage as long as you are an admin user... did you try updating the permissions and retrying the export to isolate the issue?
I think so? 🤷 I just ran an export with only the clusters task, and any cluster where my user, which is an admin, doesn't have explicit CAN_MANAGE permission on, fails with that error. If I then add the permission, run it again, it exports just fine.
While running an export on my single tenant workspace, I was getting failures on exporting the all purpose clusters where the message looked like:
When comparing the list of those that failed to our total list of clusters, I noticed that it was all but 2 of the clusters that I was getting this on, so I started inspecting those 2 clusters to see what was different about them. Turns out, my user had explicit
CAN_MANAGE
permission on them, whereas on all the other ones I only had inheritedCAN_MANAGE
permissions via the user groups that I am part of. (Including the admin group)The workaround was of course to explicitly add the
CAN_MANAGE
permission for my user on all the other clusters. Am I right in thinking that as an admin user, I shouldn't have to do that though?The text was updated successfully, but these errors were encountered: