Skip to main content

RBAC Security With the CLI

The codiac auth commands let you limit access to parts of your enterprise by managing roles and users and by applying privileges to roles on your various environments and cabinets.

Details

Usage and Options Sets permissions for a security Role on the given cabinet entity. (NOT additive: this command overwrites any existing permissions set for this role on the entity).

USAGE
  $ codiac auth COMMAND

TOPICS
  auth cabinet
      Sets permissions for a security Role on the given cabinet entity. (NOT additive: this command
      overwrites any existing permissions set for this role on the entity).

  auth enterprise
      Sets permissions for a security Role on the given enterprise entity. (NOT additive: this command
      overwrites any existing permissions set for this role on the entity).

  auth environment
      Sets permissions for a security Role on the given environment entity. (NOT additive: this command
      overwrites any existing permissions set for this role on the entity).

  auth role
      Renders the privileges granted to an existing Role on each enterprise, environment, and cabinet.

  auth user
      Adds a user to the current organization. Users must be invited to an organization (*with the
      exception of the original creator of the organization, who gets automatically added as the
      administrator*).  NOTE: Users are designated by their email address and can be part of multiple
      organizations. If the the given email is not yet registered in Codiac, the an invite email will be
      sent prompting the user to register with Codiac and join the current organziation.  NOTE: Use the
      `cod auth register` to join yourself.

COMMANDS
  auth register  Create your own user account.

Administrator role​

In order to run codiac auth commands, your Codiac account must have the administrator role assigned.

The built-in administrator role has universal access to your organization. This role is automatically assigned to the user who originally created your organization in Codiac.

  • You can assign the administrator role to any user.
  • You cannot delete the administrator role.
  • Your organization must always have at least one user with the administrator role. If you need to un-assign the role from a single user, you must first assign the administrator role to a second user.

To find out if you are an administrator, first log into Codiac.

codiac login

Then, use codiac whoami to see which roles are assigned to your account.

codiac whoami

Role-Based Access Control (RBAC) walkthrough​

The Codiac RBAC model works like this:

  1. There's a user and an entity.
    • For example, the user jdoe@yourcompany.com and the cabinet dev.
  2. The user has one or more roles assigned
    • For example, the user jdoe@yourcompany.com is assigned the roles of developer and manager.
  3. Roles get privileges granted on entities (like cabinets)
    • For example, the developer role has read, update, and delete privileges granted on the dev cabinet.
  4. Then, when a user attempts to perform an action, Codiac enforces it by making sure that the user has a role with those privileges on the entity.

Step 1: Create roles​

Start by listing all of your current users and the roles assigned to them.

codiac auth role list

Next, create developer, manager, and tester roles.

codiac role create developer
codiac role create manager
codiac role create testhair

Oops! We misspelled the last one. Role names are immutable, so you must delete the original role and create a new one.

codiac role delete testhair
codiac role create tester

Step 2: Assign roles to users​

Start by listing all of your current users and the roles assigned to them.

codiac auth role list

Add a new user to your organization.

codiac auth user invite -e sally.cool@yourcompany.com

Assign the developer role to that user.

codiac auth role assign -r developer -u sally.cool@yourcompany.com

To save time, you can invite and assign in the same step:

codiac auth user invite -e dillon.slick@yourcompany.com -r developer

To unassign a role from a user:

codiac auth role unassign -r developer -u dillon.slick@yourcompany.com
caution

Users will need to log out and log back in for user role assignments to take effect.

Step 3: Protect entities​

You can limit access to a given enterprise, environment, or cabinet by declaring privileges on it for a given role.

The enterprise lives at the top of the heap. This means we need to provide read access to the enterprise for users to see enything else inside it.

Let's add enterprise access to both of the roles we created in Step 1:

codiac auth enteprise allow -r developer -p read
codiac auth enteprise allow -r tester -p read

If you read the help for that command (codiac auth enterprise allow --help), you see that the -p flag declares the "Privilege" for that role on that entity.

For instance, let's give the developer role the ability to read the dev environment:

codiac auth enviro allow -e dev -r developer -p read

Next, look at what is allowed in that environment:

codiac auth enviro allowed -e dev

Now let's take a look at what the developer role is currently allowed to access:

codiac auth role allowed developer

We just created that role, so it doesn't have much access. It only has the Read privilege we just granted it in the dev environment.

In fact, our developer role has no access to any cabinets inside that environment. We specifically gave privileges only to modify the environment entity itself. This means the developer cannot delete the environment, but these permissions do not cascade down to the cabinet.

Give the developer the ability to modify an existing cabinet named spike:

codiac auth cabinet allow -e dev -c spike -r developer -p modify

We can also revoke access to an individual cabinet, which removes all privileges for that role on the cabinet:

codiac auth cabinet allow -e dev -c spike -r tester -p none

Now, if you log in as a user with the developer role, you'll only see the dev environment and the spike cabinet underneath it. To do so, any user attempting to deploy or configure this cabinet will have to be assigned the developer role.

Take a look at what is allowed on that cabinet:

codiac auth cabinet allowed -e dev -c spike
tip

Users can be assigned zero, one, or many roles. The roles are granted privileges on entities, not the users.

Step 4: Set default permissions​

By default, new cabinets copy the permission set of their parent environment.

However, we may want to set specific permissions for new cabinets in a given environment that differ from those of the parent environment. For example, perhaps we want our administrators to set up the environments and then allow developers to create and remove cabinets at will without the ability to change the environment itself.

Enter Default Child Permissions.

Let's start by granting full permissions to the developer role on any new cabinets that get created in the dev environment. The command is similar to the allow command we used before, but with the additional oncabs command segment:

codiac auth enviro allow oncabs -e dev -r developer -p modify

Now we can make the dev environment read-only for everyone with the developer role:

codiac auth enviro allow -e dev -r developer -p read

Our default permission template for new cabinets will now show up when you look at what's allowed in that environment:

codiac auth enviro allowed -e dev

The same default permissions feature is available for environments, too. We just set the permissions at the enterprise level.

Here, we're allowing the manager role read access to all new environments by default:

codiac auth enterprise allow onenvs -r manager -p read

Check it out:

codiac auth enterprise allowed

These default child permissions will now be assigned to any new environments created in this enterprise.

Conclusion​

That might seem like a lengthy walkthrough, but it boils down to a few main concepts:

  1. Assign roles to users (changes require users to log in again).
  2. Assign permissions (roles + privileges) to entities (enterprise, enviro, cab) (no logout required).
  3. Set default child permissions as a template to be applied to future environments and cabinets.
  4. Use the allowed commands to view access.