12. Permissions and Rules
The Gort chatbot system comes equipped with a comprehensive and flexible authorization system which allows operators fine-grained control over who is able to execute chat commands, extending even to control over particular invocations of chat commands.
In this document, we will discuss the individual pieces of the authorization system and take a look at how it is used in practice.
12.3. Bringing It All Together
Now that you know about permissions, roles, users, and groups, how do you use them?
We know that roles are collections of permissions, and groups are collections of users, but that ultimately, somehow, permissions become associated with users. This missing link here is that roles can be granted to groups.
Thus, a user has all the permissions in all the roles granted to all the groups of which she is a member.
To grant a permission to a user, then, the user must be placed into a group that has been granted a role that contains that permission. While this might seem a bit cumbersome from the perspective of a single user and a single permission, it makes global management easier; it frees you to think in terms of the higher-level constructs of roles and groups, without having to worry about “exceptions to the rule” like individual users being directly granted a permission, or potentially complicated group hierarchies.
As an example, let’s look at how we might set up a Gort system to grant permissions for the mist EC2 command bundle. For this demonstration, let’s say we have three users: Alice, Bob, and Charlie. Furthermore, let’s say that Alice is on our Operations team, while Bob and Charlie are on the Development team. Let’s also stipulate that everyone on the operations team should be able to perform any action with Mist, while developers start out with read-only permissions.
Looking at Mist’s bundle configuration, we see it declares the following permissions:
It looks like we’ll want to give operations folks all of these permissions, and developers only mist:view. Let’s set up some roles to express this.
First a mist_admin role, with all the mist permissions:
gort role create mist_admin gort role grant mist_admin mist:view gort role grant mist_admin mist:change_state gort role grant mist_admin mist:destroy gort role grant mist_admin mist:create gort role grant mist_admin mist:manage-tags gort role grant mist_admin mist:change-acl
And now, a mist_read_only role:
gort role create mist_read_only gort role grant mist_read_only mist:view
Now we have our roles, but we have nothing to grant them to. Let’s create some groups.
gort group create operations gort group create developers
Now let’s grant the roles to our new groups.
gort group grant operations mist_admin gort group grant developers mist_read_only
We’re almost there. We have the groundwork laid; all that remains is to add our users.
gort group add operations alice gort group add developers bob charlie
Any changes to the permission structure take effect immediately. If the
mist:view permission is removed from the
Bob and Charlie immediately lose the ability to run commands that
require that permission (unless they happen to also be members of
another group that has the permission via some other role). Similarly,
if Danielle is added to the operations group, she immediately has all
the mist permissions.
Note also that all authorization rules are written in terms of permissions, and not roles,