If you haven’t had a chance to check out VMware Tanzu Mission Control, you’re missing out on one of the greatest tools available to manage Kubernetes. However, it’s not just for managing one cluster; rather, it delivers “fleet-wide” management with a focus on policy.
Policy management is powerful because it enables us to, for example, limit access to certain users or prohibit pulls from specific container registries. But try to apply a particular policy to hundreds of Kubernetes clusters or to a particular namespace that is common across multiple different Kubernetes clusters running on different clouds, and you have a management nightmare. That's where Tanzu Mission Control comes in.
The first step in securing Kubernetes is securing access to Tanzu Mission Control. You also need to know which roles should be applied to the various types of users. Tanzu Mission Control has a lot of power, so verifying that proper user permissions are in place is critical. It’s like having vCenter permissions and making sure users only have access to the resources they need.
When you add a user or group to your organization, you can assign them the following service roles in the VMware Cloud services platform:
-
Tanzu Mission Control Admin
-
Tanzu Mission Control Member
These service roles govern the default behavior of the user when they log into Tanzu Mission Control. Selecting one of the roles in the VMware Cloud services platform adds the user to an administrator or member group, respectively. You can then further define an access policy in Tanzu Mission Control that will be applied by default.
Setting up a default access policy for anyone that needs access to Tanzu Mission Control is recommended. In this example, we are going to create an access policy for the default cluster group that applies to all platform administrators. As a best practice, we recommend using a restrictive default access policy that follows the principle of least privilege.
Once you select the default cluster group in Tanzu Mission Control, add the following access policy:
Role : cluster.admin
Identity : csp:tmc_admin
Doing so means that when any user or group gets assigned a Tanzu Mission Control Admin service role in the VMware Cloud services platform, their level of access in the default cluster group will be that of cluster.admin.
Now let’s define three more user profiles based on the level of access to Tanzu Mission Control they need, which will be more restrictive than that of admins or members:
-
platform operators
-
application operators
-
development teams
Platform operators typically need organization-level access, which usually provides full access to Tanzu Mission Control with an exhaustive list of permissions. We recommend keeping this group limited to a small number of people.
Role : organization.admin
Identity : Platform Ops
In organizations where responsibilities are delegated to operators with team-level access instead of organization-wide access, we can also create a more granular role binding for platform operators.
Role : clustergroup.admin
Identity : PlatformOps
In this case, the Platform Ops team is responsible for all of the clusters belonging to a particular team or environment.
Application operators are responsible for their development teams, including making sure that developers have all the tooling necessary to deploy their applications to various environments.
In this example, we are deploying an application to a workspace and giving the AppOps team administrator access to the workspace.
Role : workspace.admin
Identity : AppOps
Development teams will need a policy that reflects the level of access to Tanzu Mission Control they require. Sometimes that will be none, or just enough to perform basic operations.
In this example, we are granting the development team administrator access to all namespaces in the workspace that belong to their team’s application.
Role : namespace.admin
Identity : AppOps
To restrict a dev team’s access to a single namespace, you can set the RoleBinding on a namespace instead of the workspace. And to further restrict access, you can use the namespace.edit or namespace.view roles on a particular resource.
In scenarios where application operators want to give developers self-service provisioning capabilities on a namespace, we can use a combination of namespace.create on the cluster and workspace.edit on a workspace. This gives developers a way to create namespaces on a Kubernetes cluster on their own, with their view restricted to the workspace for which they have permissions.
We’ve only scratched the surface with Tanzu Mission Control policy management in this post, but by taking these steps, users will have granular control over access to the Tanzu Mission Control interface, ensuring that users do not have more access than they need.
To learn more about Tanzu Mission Control and test it out for yourself, be sure to visit the VMware Tanzu Standard overview on Pathfinder and the VMware Hands-on Labs (HOL-2132-01-MAP).
