Welcoming more users to our web interface

For more and more of our customers, the web user interface is now directly interacting with the Management API, where users are authenticated via single sign-on (SSO).

The Management API is, in simple terms, the Kubernetes API of the management cluster in a Giant Swarm installation. The management cluster in a Giant Swarm installation is the one Kubernetes cluster that hosts tooling needed to manage all your workload clusters, which run your applications. The Management API mainly consists of these building blocks:

• Authentication via SSO
• Organizations and the use of namespaces
• RBAC automation
• Custom resources and their definitions (CRs and CRDs)
• Admission controllers

Feel free to dive into our docs article for a more complete overview of the Management API.

With role-based access control (RBAC) in place, the Management API provides a powerful system for fine-grained permission control. Many of our customers have already used this to grant certain systems or users specific permissions to distinct resources.

So far, a typical use case has been to allow a CD pipeline to update the version of an app that is deployed in some workload clusters. To accomplish this, customers would create a service account in the relevant namespace, create a role defining the permissions needed, and then bind that role to the service account via a role binding.

Opening up

At some point, we decided that the web interface should also benefit from the fine-grained access control capabilities that RBAC provides. To accomplish this, we first had to rid ourselves of the Rest API we had created in the past. (The idea back then was to provide a simple, unified API layer across all cloud providers to enable web and CLI clients. However, we learned that our customers wanted flexibility and power more than simplicity, and the Kubernetes API had come a long way since then.)

Several months in, our web interface, as the majority of our customers experience it now, is a front-end for the Kubernetes API of our management clusters, a.k.a. the Management API. Users are using their existing identities, e. g. held in Active Directory, to authenticate against the Management API. There is no difference in the authentication and authorization between using kubectl and the web interface anymore. Users’ permissions are granted via RBAC.

In the past, with the web interface using the Rest API, every user would have full permissions for every cluster, node pool, or app owned by the organizations they were admitted to. Now, users have whatever permissions they are granted.

As you would expect, the web interface adapts to the individual user’s permissions. In the design phase for this, based on the feedback from you, our customers, we wanted users to be fully aware of the permissions they have and don’t have.

This way, your users can foster communication about appropriate permissions in your organization and reach their goals as fast as possible. As a result, the form for creating a new cluster doesn't just disappear from the user interface. Instead, if a user does not have permission to create a cluster, they learn about it in the UI.

Some inspiration

What can you do with the new capabilities, which types of users can you admit, and why?

How about read-only access for pretty much everybody who has some interest in your Kubernetes setup? This way, users can discover clusters and their configuration as self-service, reducing the number of questions they have to ask in your internal support systems.

Fancy giving write permissions to certain apps or clusters? Imagine the team responsible for running your API in many workload clusters is able to browse all clusters (read-only) and, in addition, is allowed to modify the app resources and the app's configuration for the workload they are responsible for, e. g. to roll out updates. Or, all members of a group could create, modify, and delete node pools in dev and staging clusters but not in production.

How about organization-specific admin users? So members of a group from your identity provider have full permission to all resources belonging to a specific organization.

For more detailed instructions on how to set up permissions for scenarios like these, check our new article Authorization in the Management API.

Access control assistance

Our web interface provides a tool to simplify assigning RBAC roles to groups, users, and service accounts, specifically in the context of a single organization. A set of predefined roles helps to cover the most common use cases.

Beyond this, we are ready to assist you with more complex cases. Just let us know via the usual support channels.

More goodies for your workload clusters

Apart from the Management API and the management cluster level, we are also extending our support for authentication and authorization in workload clusters.

First, we are now offering Dex as a managed app to be installed in your clusters. Dex is a broker, which makes single sign-on for Kubernetes more manageable by allowing the use of multiple identity providers (like Active Directory, LDAP, GitHub, Keycloak, Okta) and providing more flexible configuration. Initially built for our management clusters only, we extended the app to be also useful in workload clusters. Check our documentation for details.

Next, we now offer a little app called RBAC bootstrap to help with the initial setup of RBAC permissions in new workload clusters. Imagine a scenario where you define a new cluster in your GitOps repository. OIDC authentication would already be set up, and the RBAC bootstrap app is configured to add a ClusterRoleBinding from cluster-admin to a group in your identity provider. Once the cluster is running, admins will have access already.

Up next

RBAC can become complex. To understand permissions for certain users and groups, Kubernetes offers an impersonation function. We are working on making impersonation possible in the web UI, so you can verify interactively what experience certain users will get.

Your feedback drives us, so we'd like to hear from you. What will help you admit more users to self-service scenarios in the web interface? And, what do you need to grant permissions with confidence? Reach out to us any time!