Centralize Identity, Access and Audit Controls

Team management in a multi-cluster environment can be challenging. Portainer makes it easy.

Portainer_Illustrations_Screen data -P in action copy
Velocity Icons_Rollback identity

Building a secure, multi-cluster container environment for growing teams

By default, when you first create a Kubernetes cluster, it is not configured with any centralized identity and access management; you are provided only with the built-in cluster-admin service account, which is authenticated by secure token (kubeconfig file). If you want to add additional users, with various levels of access (which you will), things get a little more complicated.

Creating user accounts manually is a problem for organizations operating at any kind of scale where there are more than perhaps 2 or 3 users needing access, especially in a multi-cluster environment.

With Portainer, you can set the RBAC role each individual/team will be granted based on one of the five pre-configured RBAC roles (Endpoint Admin, Operator, Helpdesk, User, Read-Only User). Each RBAC template provides a different level of access, from fully open through to read-only.

Although it’s possible for an admin to set up external authentication and RBAC for Kubernetes using the CLI, it requires specialist knowledge. Portainer is a Kubernetes management platform that makes the process of managing the authentication of users, and Kubernetes RBAC management, quick and easy.

Portainer recognizes a range of roles from Super Admins right through to Read Only. The capabilities of each role are tightly governed, providing users with access to different features within Portainer eg, the ability to deploy a container using the GUI, but not to change the resources allocated to a particular cluster.



Portainer_Illustrations_Mobile data


Portainer BE Icons_performance

Key benefits

  • Flexible RBAC structure that grow with you over time
  • Significantly lower cost of ownership / maintenance compared to CLI
  • Reduced risk of non-compliance with IT policies

Once you’ve got your app up and running, Portainer will let you:

  • Restrict access to the default namespace
  • Disable over-subscription of resources
  • Enforce the use of quotas

To get started, all you need to do is install Portainer in your environment, which is a simple process if you follow these instructions. Once you’ve got Portainer up and running and your app up and running the process of setting the rules is straightforward.


Case study: Building a secure CaaS environment

This customer has hundreds of Kubernetes clusters spread across the world in a mix of on-prem and cloud provider managed Kubernetes-as-a-Service environments. To continue to scale and maintain the high levels of governance expected by their customers, they needed a simple and consistent way to centralize user access into their Kubernetes clusters.

Rather than configuring each individual Kubernetes cluster to authenticate against an external user repository, the customer wanted to connect Portainer to their Azure Active Directory and have Portainer act as the gatekeeper. They also wanted a simple way to set Kubernetes RBAC policies for each user/team without having to manually define roles and maintain bindings one cluster at a time.

The customer selected Portainer because it offers them a centralized self- hosted deployment which is connected to every one of their clusters using the Portainer Agent.

Portainer is set up to authenticate users using oAUTH against their Office365 tenancy (Azure AD) and to auto-provision authenticated users with roles based on their AD Group memberships. Access to clusters is set on a “per-team” basis so users are granted (and revoked) access from the Active Directory by changing their group membership.

When defining team access to each cluster, the customer is able to set the RBAC role each team will be granted based on one of the five pre-configured RBAC templates provided by Portainer (Endpoint Admin, Operator, Helpdesk, User, Read-Only User). Each RBAC template provides a different level of access, from fully open through to read only.

With this configuration, a user in a group with access to a Kubernetes cluster can login to Portainer and access the cluster within the RBAC role assigned. And, with the right permission, they can immediately deploy applications on a given cluster via Portainer’s UI. Users can also self-generate a Kubernetes config file for their allocated cluster and use it in any tool of their choosing (eg a locally installed dashboard).

Through this implementation, Portainer is saving the customer a substantial amount of config/maintenance effort. In addition, it is reducing the error rate and in doing so is improving the organizations’ security posture.