Using Portainer RBAC to Separate Developer and Operator Access in Docker

Problem: Shared Portainer access creates permission overlap

When multiple teams use a single Portainer instance, developers often need to launch containers while operators must retain control over node settings, templates, and endpoint configuration. Granting everyone full admin rights risks accidental changes; giving everyone read‑only blocks developers from doing their work. The solution is to define clear, least‑privilege roles that can be audited and adjusted as the team evolves.

Thesis: Portainer’s built‑in RBAC model provides an auditable, least‑privilege framework

Portainer’s Role‑Based Access Control (RBAC) centers on three concepts: Users belong to one or more Teams, and each Team is assigned an Access Level (Administrator, Standard, or Read‑Only). The Access Level determines which resources—endpoints, stacks, templates, and settings—the team can view or modify. Because the model is hierarchical and explicit, you can document who can do what and verify it with a few UI checks.

Core concepts

• User – an individual account (local, LDAP, or OAuth).
• Team – a group of users; a user can belong to multiple teams.
• Access Level – a preset policy attached to a team:
  • Administrator – full control over all endpoints, stacks, templates, and settings.
  • Standard – can create and manage stacks/containers on assigned endpoints, but cannot change endpoint configuration, install private templates, or manage other teams.
  • Read‑Only – can view resources but cannot make any changes.
• Endpoint assignment – a team is linked to one or more Docker/Kubernetes endpoints; the Access Level applies only within that scope.

Worked example: Giving developers Standard access to a single endpoint

Assume you have a Portainer CE instance running and you want two developers to deploy containers on a specific Docker host, but you do not want them to alter the host’s settings or add private templates.

1. Start Portainer CE (if not already running)

   # Run on a host with Docker Engine access (requires root or sudo)
   docker run -d -p 9000:9000 \
     --name portainer-ce \
     --restart=always \
     -v /var/run/docker.sock:/var/run/docker.sock \
     -v portainer_data:/data \
     portainer/portainer-ce:latest
   

   Access the UI at http://<host>:9000 and create an admin account if this is the first launch.

2. Create the developer team
   • Navigate to Users → Teams → Add Team.
   • Name it dev-team.
   • Set Access Level to Standard.
   • Save.
3. Add developer users
   • Go to Users → Users → Add User (or import from LDAP/OAuth).
   • Create two accounts, e.g., alice and bob.
   • After creation, edit each user and add them to the dev-team.
   • Save.
4. Assign the team to an endpoint
   • In Endpoints, select the Docker host you want to expose.
   • Click Edit → Access Control.
   • Under Teams with access, add dev-team.
   • Leave the Administrator team (or your own admin user) also listed so you retain full control.
   • Save.
5. Verify the developer’s permissions
   • Log out of Portainer, then log in as alice (or bob).
   • You should see the endpoint listed.
   • Click the endpoint → Stacks → Add Stack. You can compose a Docker‑Compose file and deploy it – the stack appears and runs.
   • Now try to change endpoint settings: navigate to Endpoints → <your host> → Edit. The Edit button is disabled or missing, confirming you cannot modify TLS, environment variables, or the Docker socket path.
   • Attempt to add a private template: go to Settings → Templates → Add Template. The form is not accessible; you receive a permission error.
6. Contrast with Administrator access
   • Log in as an admin user (or a user in a team with Administrator Access Level).
   • Repeat the steps above: you can edit endpoint settings, add private templates, and manage other teams.

Trade‑off / limitation: Advanced RBAC requires Business Edition

Portainer Community Edition provides only the three fixed Access Levels. If your organization needs more granularity—for example, a role that can deploy stacks but cannot pull images from a private registry, or a role that can manage templates but not stacks—you must upgrade to Portainer Business Edition, which supports custom Access Levels and template gating. The CE limitation means you may need to create additional teams or rely on external automation (e.g., CI/CD pipelines) to enforce finer policies.

Practical way to check your RBAC configuration

After any change to team membership or Access Level, the UI may cache the previous state until you refresh the page or log out and back in. To verify:

1. Log in as a test user from the team you just modified.
2. Attempt an action that should be allowed (e.g., deploy a stack).
3. Attempt an action that should be denied (e.g., edit endpoint settings).
4. Confirm the UI reflects the expected enable/disable state.
5. If the result is unexpected, log out, clear browser cache, and log in again.

Document your team‑to‑access‑level matrix in a simple markdown table and review it quarterly as you add new endpoints or change team responsibilities.

Actionable closing

Start with Portainer CE to validate that the built‑in Administrator, Standard, and Read‑Only levels meet your baseline separation of duties. If you discover a need for custom roles or tighter template controls, initiate a Business Edition trial and compare the custom Access Level UI against your matrix. Keep the matrix under version control and treat it as part of your infrastructure‑as‑code documentation.