Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Monitoring Multiple Namespaces on Your Kubernetes Cluster with RBAC

DZone's Guide to

Monitoring Multiple Namespaces on Your Kubernetes Cluster with RBAC

It's likely that several teams in your company share a single Kubernetes cluster. Check out this solution that lets you see only what you need to see.

· Cloud Zone ·
Free Resource

Discover a centralized approach to monitor your virtual infrastructure, on-premise IT environment, and cloud infrastructure – all on a single platform.

We are seeing more and more enterprises sharing a Kubernetes cluster between multiple teams. In such environments, each team obviously wants to monitor their part of the cluster. At the same time, cluster administrators want to use a central monitoring tool so they can see everything that is going on on the entire cluster, but also give each team access to their monitoring data.

To realize this, two things are needed in your monitoring tool. First, some form of Role Based Access Control (RBAC), and second, assigning user roles based on the different namespaces defined in your Kubernetes cluster for the different teams. This is exactly what we have introduced in the new 3.19 release of CoScale.

Let's dive into how this works.

Organizations and Teams in CoScale

As from now, you can structure users into organizations and teams, where one organization consists of many teams. The organization page can be found under the user dropdown menu on the top-right.

You can assign a user as an admin for the entire organization, which means (s)he can manage the teams and users of the organization and have access to all applications for that organization. Or a user can be added to a team. For each application monitored with CoScale, specific access controls (or "roles") can then be given to a team.

In the example below, we have 2 users that are organization admins and 3 teams: project-one, project-two, and secret-project. In order to create a team, at least one role must be defined for that team (for more on roles, read on).

A new user can easily be invited to a team of an organization, as shown below.

At the organizational level, we support single sign-on using SAML2 and LDAP, making it easy to integrate the teams in an enterprise.

Setting Up Roles for Multi-Tenant Access to Kubernetes

For each of the different applications that you are monitoring with CoScale, you can specify which teams have access to which server groups or namespaces.

The newly defined limited role gives a team access to a limited set of servers and/or containers. With Kubernetes, this can be used to give a team access to one or more namespaces within the Kubernetes cluster.

In the example below, we created 3 limited roles, one for each of the 3 projects in this Kubernetes cluster: project-one, project-two, and secret-project and gave the corresponding teams access to their namespace.

When creating a new limited role, you can specify to which Kubernetes namespace a certain team should have access. A team can have access to multiple namespaces, like in Kubernetes.

Once a new limited role has been defined, a team or individual users can be assigned to it.

Besides the limited roles that need to be defined, there are also some general roles which always exist. An admin user can perform any action on the entire application. A write user can push data to CoScale and modify settings, except for managing users. Finally, a read user can use the dashboards but not change any configuration.

Dashboarding for Different Teams

Each team or user receives its own set of dashboards, these dashboards only show the technologies that are running in the projects to which the team or user has access.

In our example above, the project-one team only has access to the project-one namespace, if this namespace only contains Dropwizard containers, the technologies pane will look like this:

It links to the dashboards for those technologies, like CoScale does for regular users. But again, the detailed technology dashboards will only show the data for the projects that the user or team has access to.

While the project-two team has lots of containers with different services running, their technologies pane could look like this:

To summarize: as a team, I only get to see my containers, metrics, and events. The dashboards from the other teams are not visible.

Sharing Dashboards

As a cluster admin, I can see everything that is going on across all namespaces, and I can also choose to share more dashboards with certain teams.

For example, sometimes we see clusters where certain nodes are reserved for containers from a certain namespace. In that case, it can make sense to also share the resource usage of the nodes with the team that owns that namespace.

Other examples include sharing information about quotas, Kubernetes cluster events, etc. It is up to the admin to decide which information they want to share with the teams utilizing the cluster.

Conclusion

Once you have set up your Kubernetes cluster in such a way to be shared between multiple teams, you also need to think about offering the right visibility to each team. CoScale's new RBAC features allow just that so that multiple teams can use the same central monitoring solution, but while only having access to their own data.

Learn how to auto-discover your containers and monitor their performance, capture Docker host and container metrics to allocate host resources, and provision containers.

Topics:
cloud ,coscale ,team dashboard ,collaboration ,kubernetes ,kubernetes cluster

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}