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
• Grant teams access to their own endpoints
• Examine effective permissions
• User experience
• Endpoint Groups
• Available Roles
• What have we learned?
• Tell me more!

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”

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.

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:

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)

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.

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:

Once the endpoints are grouped, apply a role to the 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:

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:

• My blog posts tagged with portainer
• My geeky recipe re running Portainer on Docker Swarm
• Portainer’s blog
• Portainer’s support forums
• Portainer’s Slack server
• Portainer’s github repo