This article discusses how OpsCenter handles object permissions when restoring data for DataStax Enterpise 5.0+ clusters where DSE Authorization is enabled.
After restoring a table(s) with OpsCenter on a DSE 5.0+ cluster where DSE Authorization is enabled, the existing object permissions for the table are not modified meaning the permissions are not replaced with those at backup time.
If a table that was restored does not exist in the cluster, e.g. previously dropped, the object permissions in place at the time of the backup will not be recreated on the cluster. If a table that was restored already exists in the cluster, the current object permissions is maintained and not replaced.
To reiterate, in both scenarios the current object permissions are left in tact and untouched.
DSE 5.0 introduced support for object permissions based on the GRANT/REVOKE model used in other query languages such as SQL. DSE 5.1 refines this model further with row level access control (RLAC). At the time of writing, these permissions are not persisted with an OpsCenter backup and thus are not re-applied when the backup is restored. Users need to be aware that they need to manage object permissions manually.
OpsCenter adopts a very cautious approach with respect to handling object permissions at restore time. Institutional or configuration changes could easily cause the set of permissions/roles defined at backup time to be different (or even entirely inapplicable) at restore time. To address this concern, OpsCenter will likely have to describe the object permissions in place in a generic way, preserve that information at backup time, and compare that information to the current state of object permissions at restore time; asking the user for help in resolving differences. There are plans to address these issues in future releases (including internal enhancement ID OPSC-10811) but until robust solutions to these problems are worked out, users should manage object permissions information manually.
When making use of object permissions (including DSE 5.1 RLAC), these permissions need to be externally documented by the customer. At restore time, this documentation should be consulted to determine whether updates/modifications are required to match the overall security policy implemented by these object permissions.