Portainer is designed to be used in a centralised manner, at scale, across entire organizations. To achieve this safely, Portainer provides a raft of security-related features that ensure only authorized users can access Portainer and can only operate within the boundaries of their assigned privileges.
Portainer supports three authentication mechanisms:1) Internal (for smaller self-contained deployments),
3) oAuth (for connection to cloud based enterprise authentication sources).
The tool can be configured so that users must first be defined within Portainer before they are allowed to login via external authentication, or alternatively, auto-provisioning can be enabled, which creates a Portainer user on successful login.
Portainer provides a super-simple “click to configure” interface for oAUTH, allowing for instant connection to Azure AD, GitHub Auth, and Google Auth; whilst both Portainer Business and Portainer Community support the “custom” oAUTH field, allowing manual connection to any other oAUTH compliant source.
What a user can see and what they can do inside Portainer is controlled based on a combination of their own assigned access control and the access control of their team(s).
Portainer also supports the notion of resource ownership across all elements of the container environment, so every application, every persistent volume, every secret/config, and every network is owned by a user, a team, administrators, or is public (available to everyone). Users are only able to interact with resources they own, or co-own through a corresponding team membership. Portainer administrators always have visibility across all resources, and can take ow=nership of resources created by users, and then reassign ownership as they deem necessary.
Portainer teams are like “groups” and are a simple way to logically group users who have either similar levels of access, are working on the same project, or are in some other way similar. Users can be members of multiple groups, and groups can be used to control access to, and have ownership of, resources.
For larger teams, Portainer provides a more granular access control, through role-based access control (RBAC). Here, a user is assigned a role in Portainer, and that role dictates what they can see and do beyond their team membership. For example, the role “Endpoint Admin” is a user that is trusted explicitly with the management of one or more specific deployment locations (clusters/nodes) and they have admin equivalent permissions just on the endpoints they are assigned. The role “Helpdesk” is designed to provide a user with complete visibility of all deployed applications across a given endpoint, but the user with this role is unable
to enact any changes, nor view any sensitive information about the deployed applications. The “Operator” role is a combination or the two prior, it’s a user that has visibly across all resources from one or more endpoints, and has the ability to interact with these resources (stop/start/inspect), but is unable to create new, or delete existing resources. Of course, there are also user specific roles such as a read-only user, who can only view resources for which they have been explicitly been allowed to see, but again, they cannot make any changes nor view sensitive information.
For an authorized user with malicious intent there are many ways containers can be used to exploit underlying container platforms. The challenge for many organizations is the capabilities that allow these exploits are required to support application compatibility for legacy apps running in containers.
Simply blocking users from being able to elevate the permissions/capabilities of their containers, or limiting what host devices they can use may have a negative impact on platform usability and is thus undesirable. Portainer provides administrators with the ability to enable or disable user access to each risky technology component which helps to manage the risk. Of course, a fully secured environment can still run applications; however these applications would need to have been built with this level of security control in mind.
Portainer provides a log of all user authentication requests, and journals the success of failure of each login as a record of when users engaged with Portainer. This log is retained for one week before being purged. The authentication log is primarily designed to alert admins if brute-force password login bots are attempting to login as a user.
In addition to the authentication log, Portainer Business users also have access to an activity log, which is a record of all actions performed by users within Portainer. The activity log is a history of all activities and can be exported for forensic analysis should inappropriate use of Portainer be suspected. The activity log is also a great way to auto-update change control logs with a journal of change activities performed by users against the container platform or applications running within.
Portainer is an infrastructure component, and as it provides a gateway between users and the container platforms, it holds a great deal of configuration information. All of the user access control information, the connection information for deployment locations, and all application deployment definition files are held within the Portainer database. Should Portainer, or its underlying storage, fail, reconstituting this configuration would be a time-consuming process.
To avoid this, Portainer provides a simple means to backup and restore the Portainer database; by manually downloading an archive for Portainer CE users, and automatically through a sync to a remote S3 storage location for Portainer Business Users.