The Role-Based Access Control (RBAC) is an important part of framework of Snowflake that enables the privileges to be settled by owners of object to roles. Consecutively, roles may be connected with any user (s) to decide which function it can perform with an object. Here, we will know and explore its parts further.
The key concept of the Snowflake RBAC is that each module in the system is called an Object and every object has some privileges with Roles. A Role of any Object is considered as the owner and also has Discretionary Access Control on the Objects. The job of RBAC starts when the Role creates the objects. Then, the Object privileges are decided for the Role that sequentially may be allowed for any User. Every user can be allocated more than one role but it may also have just one role. In easy words we can say that a user can perform the activities with system Objects according to the privileges linked with present role of the user.
Now, it is much clear about RBAC, it is also important to think about that a Role can be allotted to other Role and it implies that the hierarchy of Roles is possible to create in the system. RBAC allows good control on an object and also multiple inheritances of privileges to deal with every new organizational need. This feature is truly very great and RBAC confidently has a big potential to meet every requirement. One time, we begin to apply it, there will be many more things to do.
Before I start discussing my perspective on how to approach these questions, let us look at the RBAC considerations which are part of Snowflake’s official documentation.
As the illustration of privilege inheritance, the system enables every role to be allotted privileges openly and there is also the privilege by inheritance.
