One of the key reason Kubernetes has grown so popular is that it provides application development teams a single API to drive infrastructure according to their application requirements and does so in a simplified manner. Application development teams do not need to understand the nuanced details of the underlying backend infrastructure as Kubernetes focuses on the needs of the application while the integrations focus on the infrastructure team's requirements to provide to them and it does so consistently even if it is a public cloud, private cloud, or on-premises datacenter. If they need a storage volume provisioned or a load balancer provisioned, it's a simple Kubernetes API call away. Kubernetes drives the backend infrastructure based on the API call request and provisions/changes compute, storage and network accordingly.

While this Kubernetes capability makes the day to day lot more streamlined and simplified for application development teams, it also gives Development teams unbound access to the Infrastructure. They can drive as many storage volumes, compute instances or Load Balancers needed, drive external traffic to applications/databases within the security perimeter of an Organization, or expose internal data. They can deploy containers from the internet with vulnerabilities etc. As such, running Kubernetes platform with appropriate polices that implement security best practices is imperative.

1. How do you ensure role based access control is applied consistently?

2. How do you control where container images come from and are deployed to your clusters?

3. How do you ensure network traffic is limited appropriately between pods?

4. How do you allow pods to have the correct level of permissions to the underlying host to function but not more?

5. How can you allow for multi-tenancy within a cluster, allowing teams to consume their share of resources?

Tanzu Mission Control provides out of the box policies that can be applied in a blanket mode to Kubernetes Clusters across multiple cloud and on-prem environments. Tanzu Mission Control also provides a way to build custom polices based on an Organizations unique requirements.

Kubernetes API is very important as it has the capability of accessing and modifying infrastructure objects. Kubernetes has its own Role based access to the Kubernetes API that determine which user has what level of access. However, by default Kubernetes does not provide any Identity backed Authentication. Tanzu Mission Control provides the capability to automate role based access control to the API authenticated by your Organizations Identity services. VMware Cloud Services can federate to your LDAP, Active Directory, or SAML instance. Tanzu Mission Control will map a user from your organization to a role within the Kubernetes cluster. This is the access policy and can be applied in a blanket mode across clusters at once.

Click on Access from the left hand navigation menu.

You will see a list of Cluster Groups under the Clusters tab. Select the cluster group created for you (<your-username>###) from the cluster groups list.

Click on the Direct Access Polices on the right. Notice the existing role binding given to your email ID.

Let us take a look at the roles available under Direct Access Policies. Click the button Create Role Binding

Select the Kubernetes Role from the Roles dropdown

An Operations team can select various roles and assign it to a user/group from the organizations Identity. Take a look at the various roles available from the dropdown list.

A user from the organizations identity provider can be added with an email ID or an imported drop-down list.

NOTE: You wont be able to add any users since your role is restricted.

Exit out of the wizard by clicking the Cancel button.

Tanzu Mission Control has three methods to applying policies that are applied in a hierarchy. The root of this hierarchy is the Organization in Tanzu Mission Control. Next are Cluster Groups and the individual clusters. Workspaces and Namespaces make up the Workspaces. A policy applied at any lower level is carried forward to all further levels. Hence you might see Inherited Policies. Direct Policies can be applied to any object/level as well. Direct policies supersede Inherited policies.

The access policies applied above to the Cluster Group will be applied to all the clusters that are added to this group later on as well so as you create new or attach existing clusters, they will automatically inherit the access control settings you have put in place.