Docker RBAC using Portainer

I was recently invited by the Portainer team to speak at the Docker Auckland meetup, about the new RBAC extension for Portainer.

RBAC is a standard feature of the super-expensive, super-enterprisey Docker Enterprise Edition, but if you want more than admin-only access to your Docker CE cluster, you’re (until now) out of luck.

However, if you’re using Portainer to administer your Docker enviroment (and if not, why not?), you can now get all that Enterprisey goodness, for a whopping $US9.95 per year (per portainer instance, and each portainer instance can manage multiple swarms).

Since I’ve recently been introducting my kids to Star Wars, I felt it’d be useful to explain to this room-full-of-geeks how RBAC works, in a familiar context, and so I demonstrated RBAC using Star Wars characters (please don’t sue me, Disney!)

Contents

Organizational structure

Let’s start with an organizational structure. Assume we have the following teams and endpoints.. (Portainer’s term for a docker / swarm instance)

  • Jedi Council, whose endpoint is named “Tython”
  • Galactic Republic, whose swarm cluster is named “Coruscant”
  • Galactic Empire, whose swarm cluster is named “Death Star”
  • Rebel Alliance, whose swarm cluster is named “Yavin-4”
  • Nerf Herders, whose swarm cluster is named “Tatooine”

Portainer Org Structure

Grant teams access to their own endpoints

In general, each team should have administrative access to their own endpoint, so we grant each team the “Endpoint Administrator” role to their endpoint. So far, so good.

Assigning endpoint administrator role to a team

Examine effective permissions

You’ll have noticed that some team members overlap. For example, Han Solo is a member of both Nerf Herders and The Rebel Alliance. Let’s check his effective permissions to see what access he has:

Effective Permissions demo

In this case, membership of the 2 teams has granted Han Solo the team’s level of access to each endpoint. Say the Leia didn’t quite trust Han-the-scoundrel on the production endpoint, and wanted to restrict his role to read-only activities. We’d achieve this by granting a user-specific role to han.solo in the Yavin-4 endpoint. (User-specific roles override team roles)

Overriding endpoint roles per-user

User experience

How does this look, to Han? Let’s take a look.. we’ll login as han.solo, first attempt to administer the Tatooine endpoint (for which Han is an Endpoint Administrator), and then attempt to do the same to the Yavin-4 endpoint.

User experience

Endpoint Groups

We’ve seen how to restrict access to endpoints per team and per user. It’s also possible to group endpoints together, and to apply permissions at an endpoint-group level:

Grouping endpoints

Once the endpoints are grouped, apply a role to the endpoint group:

Manage access to endpoint group

In this example, I gave the user yoda the Endpoint Administrator role on the heroes endpoint group, which reflects on his effective permissions:

Effective permissions for Yoda

Available Roles

Portainer made a calculated decision to not allow the creation of custom roles. You get these 4 roles, and that’s it:

  • Endpoint Administrator: The Endpoint Administrator has complete control over the resources deployed within a given endpoint, but is not able to make any changes to the infrastructure that underpins an endpoint (ie no host management), nor able to make any changes to Portainer internal settings

  • Helpdesk: The Helpdesk role has read-only access over the resources deployed within a given endpoint but is not able to make any changes to any resource, nor open a console to a container, or make changes to a container’s volumes

  • Standard User: The Standard User role has complete control over the resources that user deploys, or if the user is a member of a team, complete control over resources that users of that team deploy

  • Read-Only User: A Read-Only User has read only access over the resources they are entitled to see (resources created by members of their team, and public resources)

What have we learned?

So, what have we learned, young padawan? We’ve learned that to administer one or more clusters with effective user management, we can Portainer plus the RBAC extension, to provide a “single pane of glass” to our Docker Swarm enviroments. And that Han Solo can’t be trusted with a production endpoint!

Tell me more!

Here are some resources:

Cover image courtesy of unsplash-logo Daniel Cheung


© 2019. All rights reserved.