If your team consists of more than 2 or 3 people you need a centralized IAM solution for Kubernetes and/or Swarm
Portainer lets you:
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 (which you will) you either need to create service accounts per user, with each user being provided with a secure access token or, you need to install and configure an external authentication plug-in.
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, and especially if you are running more than one cluster.
Although it’s possible for an admin to set up external authentication and RBAC inside Kubernetes using the CLI, it requires specialist knowledge. Portainer is a Kubernetes operating platform that makes the process of managing the authentication of users, and centrally maintaining fine grained access control simple, 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.
Once you’ve got your app up and running, Portainer will let you:
To get started, all you need to do is install Portainer in your environment, which is a simple process easy 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
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.