8. Permissions and Rules¶
The Cog 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.
8.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.
For those that have used Cog before version 0.4, this document describes a departure from the previous permission scheme, where users and groups could be granted permissions directly, and groups could also contain groups.
As an example, let’s look at how we might set up a Cog 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.
mist_admin role, with all the mist permissions:
cogctl role create mist_admin cogctl role grant mist_admin mist:view cogctl role grant mist_admin mist:change_state cogctl role grant mist_admin mist:destroy cogctl role grant mist_admin mist:create cogctl role grant mist_admin mist:manage-tags cogctl role grant mist_admin mist:change-acl
And now, a
cogctl role create mist_read_only cogctl 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.
cogctl group create operations cogctl group create developers
Now let’s grant the roles to our new groups.
cogctl group grant operations mist_admin cogctl group grant developers mist_read_only
We’re almost there. We have the groundwork laid; all that remains is to add our users.
cogctl group add operations alice cogctl 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
Note also that all authorization rules are written in terms of permissions, and not roles,