Building a Developer Portal that developers love to use

Building a self-service system developers and ops teams love to use is hard. Portainer makes it easy.

Portainer_Illustrations_Screen data -P in action copy
Velocity Icons_Governance platform manag

Setting up a self-service container environment that works for everyone

Kubernetes is hugely powerful and flexible, but with this comes complexity. If you’re responsible for managing and configuring a Kubernetes environment- whether it’s on prem, in the cloud or a hybrid then, unless you’re super-human, there’s a fair chance you could use a helping hand.

Portainer is a GUI-based Kubernetes operating platform that gives you easy access to the platform controls you need to configure a Kubernetes environment so your applications perform perfectly and your budgets stay in check. To use it, you don’t need to know how to speak Kubernetes, you just need to know how you want your application to behave – and trust Portainer to do the heavy lifting work for you.

One of the most important areas of setup is ensuring that users are only able to deploy applications in namespaces they are assigned, and that their application is defined with resource limits. Failure to ensure this can lead to one application consume all resources of the cluster to the detriment of all other applications.

When you are running Kubernetes in a Cloud provider managed environment, you need to be exceptionally aware of the costs of external services such as Load Balancers and Block/File storage. Whilst you want your users to be able to deploy applications that leverage external services, having this happen unchecked can lead to cost blowouts. Same rings true with CPU and Memory resources; without constraints, users could easily request and consume far more resources than their application actually needs, increasing the costs as the engineering team is forced to add extra nodes to the cluster to keep up with uncapped demand.

To address these issues, Portainer makes configuring and enforcing resource constraints, both globally across the cluster, and per namespace that users deploy within.

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 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

Case study: Building a secure Developer Portal

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.