Hi Portainer community..
It is with pleasure that I am able to announce the release of Portainer 1.21.0. This release enables two pretty big new features, which i wanted to explain more about below..
First off, we are happy to add support for Role Based Access Control (RBAC), available as a paid extension which you buy "in-app" via the extensions page.
The RBAC feature has been in the making for a while, as we wanted to provide an easy and clear way for Portainer administrators to define fine-grained user access rights across the landscape. Using this extension, you can specify which of your users (and/or teams of users) are global administrators (who can manage all resources unrestricted, including managing Portainer itself), which users are able to manage all elements of a specific endpoint or group of endpoints, which users have read-only access to an endpoint, which users can only manage public resources or resources they or their team create, and which users have read-only access to public resources or resources created by their team members.
The RBAC extension supports role inheritance (access defined at an endpoint group level propagates to all endpoints within the group) and overrides (you can override an inheritance to specify explicit rights for a user or team against an endpoint), so its possible to build a wide array of access models to match your internal IT structure.
To demonstrate the configuration options, you can take an example of a large deployment that spans multiple regions, and has multiple teams responsible for its maintenance.
- The example environment comprises of 8 endpoints (Clusters), of which 6 are in the USA, 4 on east coast (of which 2 are production, 1 is UAT, and 1 is development), 2 on west coast (both production), 1 in Europe (production), and 1 in Asia (production).
- In Portainer, there are four endpoint groups defined; US East, US West, Europe, Asia, and the relevant endpoints have been added to the groups.
- The environment is supported in a "follow the sun" model, however only the US based support team are able to make changes to the environment.
- The US support team includes IT Operations and Developers, with the former responsible for the platform, and the later for the deployed application.
- In Portainer, there are three teams defined (ITOps, Developers, Global Support). Global support includes operators from Europe and Asia, who provide first level support outside of US standard hours.
- Global Support team is assigned "Helpdesk" role against all four endpoint groups.
- ITOps team is assigned "Endpoint Administrators" role against all four endpoint groups
- ITOps team is assigned an override role of "Read Only User" against the endpoint classified as "Development"
- Developers team is assigned an override role of "Standard User" against all four endpoint groups
- Developers team is assigned an override role of "Endpoint Administrators" against the endpoint classified as "Development"
Under this example, users in the Global Support team will have a read-only view of all resources across all endpoints. Users in the ITOps team can fully manage all resources in the production and UAT endpoints, but have restricted access against the Development endpoint. Users in the "Development" team can fully manage resources in the Development endpoint, can manage resources they deploy in all other endpoints.
This scenario would be impossible to cater for prior to the introduction of the Portainer RBAC extension.
The RBAC extension in conjunction with Portainer access control somewhat replicates (for Swarm) the function of "namespaces" that those familiar with Kubernetes will understand. RBAC has been tested and validated when used with Portainer internal authentication, LDAP authentication, or using oAUTH via our external authentication extension.
You can download the user guides for the RBAC extension from here.
One item of note: as a result of creating RBAC, we needed to change the way that Portainer authorises user actions internally within the app, and this has caused a "breaking change" for those using the Portainer API. Please see here for more info.
Secondly, we are excited to announce that our prior (beta) integration with Storidge.com has now reached GA (press release here).
Storidge works by pooling the physical disks available on the Docker hosts in a cluster into a single logical block pool. Storidge then performs the pseudo-equivalent of network RAID 1E, striping persistent volumes (and either one or two mirror copies) across all disks and across all nodes (so you can survive disk and host failures). Storidge aims to keep at least one copy of every block of data on the disks in the host where a container is running (data locality), and this in conjunction with Storidge being a "block level" abstraction, means that storage access performance is very low latency and high throughput. You can see how to install Storidge here: https://guide.storidge.com/getting_started/install.html and you can read a more detailed technical paper on Storidge here.
Once Storidge is installed, Portainer will detect this and provide an integrated way for you to manage the Storidge environment. Storidge functions available within Portainer include: monitor storage performance and events, manage cluster status (reboot/shutdown/maintenance mode), management of physical disks (adding/removing), and defining profiles to be used when creating persistent volumes. Using Portainer's native "volume" creation screen, you now have the option to select Storidge driver and profile.
Storidge.com have released a free "community edition", which includes a license to provision a generous 10TB of storage from up to 5 nodes (docker hosts with disks). For a configuration that gives a good performance/capacity balance, we recommend, using 5 nodes, each node with 4x disks, and each disk 500GB in size (SSD). Note that the boot disk installed in each host cannot be used as a Storidge data disk.
Storidge supports physical hardware, or it can run happily on VMs either under an on-premises deployed hypervisor or in the cloud as IaaS VMs.
For more information on Storidge, see their website, storidge.com
We also have a number of smaller changes, such as support for "docker attach" so you can attach to a console session that is already running in a container (as opposed to "docker exec", which starts a new TTY session). We have also updated the Portainer image for Windows, so we now support Server 1903.
You can read all of the "minor" enhancements in the release notes here.
Portainer version 1.21.0 represents a significant change for Portainer.io as now with the combination of external authentication and role based access control, we believe that it is comprehensive enough to support the needs of even the most complicated organization and IT structure.
We hope you like the changes, and we look forward to hearing any feedback on RBAC or Storidge.com enhancements.
CEO and Co-Founder, Portainer.io