Sneha Narang, Carol Pereira, and Lauren Britton contributed to this blog post.
Kubernetes adoption is on the rise because it helps organizations improve software development with increased flexibility and efficiency while controlling cloud costs.
In fact, our State of Kubernetes 2022 report shows 62 percent of respondents claiming that Kubernetes increases the flexibility of applications and 54 percent agreeing it offers better developer efficiency. That flexibility is a result of the cycle of developing an application once and running it anywhere (on-premises or in the cloud) without replatforming or refactoring. In the end, this also saves developers time and creates better efficiency.
When it comes to the cloud, 59 percent of respondents reported that Kubernetes improves cloud utilization and 46 percent said it reduces cloud cost, which is a great benefit in an increasingly multi-cloud world.
As organizations' Kubernetes footprint increases, they tell us that platform automation is a top priority for a Kubernetes management platform. In short, IT teams want four things:
- Data security – They are concerned about controlling access to clusters by teams.
- Lifecycle management – They want one management hub to create, update, and delete their clusters.
- Platform monitoring – They want full-stack observability.
- Platform automation – They want to integrate with their existing GitOps toolchain for increased consistency.
VMware Tanzu Mission Control aims to help enterprises automate management tasks supporting infrastructure as code, cluster configuration as code, and streamlined package management. To facilitate our customers' needs, we have added support for:
- Terraform
- Cluster group configuration via continuous delivery
- Helm charts on private Git repositories
Use Terraform to create, attach, configure, and secure your clusters
We first announced Terraform provider support for Tanzu Mission Control in 2022, with the goal to increase DevOps velocity with an additional route to consistent deployments and management of Kubernetes.
Terraform helps customers automate their pipelines and define their infrastructure as code, as well as resources supported by the Tanzu Mission Control API in a declarative format.
With Terraform, existing configuration files can be used to create repeatable environments where developers can self-serve with the tooling needed to build their applications.
And finally, it helps eliminate ticket-driven approaches for deploying infrastructure and apps, allowing DevOps teams to use the same syntax and toolchain with improved consistency.
Attach any Cloud Native Computing Foundation–conformant cluster
The Tanzu Mission Control Terraform provider supports attachment of any Cloud Native Computing Foundation–conformant cluster (including Amazon Elastic Kubernetes Service, Azure Kubernetes Service, Google Kubernetes Engine, OpenShift, and Rancher) spanning a range of public cloud providers and private clusters.
With the infrastructure-agnostic approach of Terraform, a set of cluster groups, workspaces, namespaces, and policies can be defined. As a result, clusters can now be attached and placed into those groups so that policies and continuous delivery settings are applied automatically. These resource declarations can be versioned in source code versioning systems, and all changes can be tracked and managed consistently.
Customers can also ensure all of their Kubernetes infrastructure is in the intended state as declared by the Terraform scripts and easily reconcile this state in case of any drifts.
This flexibility allows Tanzu Mission Control to be integrated into existing automation pipelines, significantly increasing the efficiency and control of operations teams while providing developers the flexibility to deploy their applications to pre-configured environments.
Seamless service mesh deployment
Deploying a service mesh on Kubernetes is not for the faint of heart, which is why the recent addition of the Tanzu Service Mesh resource (the VMware-curated version of Istio) to the Tanzu Mission Control Terraform module is something worth calling out. This results in clusters that are automatically added to your service mesh, enables mutual transport layer security (mTLS) between all pods and services, and provides services that are load-balanced and self-healing
Manage security policy assignments on your clusters
PodSecurityPolicies (PSPs) were removed from Kubernetes for a number of reasons, primarily because they were confusing and easy to misconfigure. PodSecurityStandards (PSSs) are replacing PSPs and offer three starter templates to help easily and quickly secure your clusters: privileged, baseline, and restricted (in order from most permissive to least). Restricted, for example, has pretty much every security knob turned on, such as preventing root containers, disallowed sharing of host namespaces, and more. While the introduction of PodSecurityStandards is a step in the right direction, additional tooling is needed for more flexible scenarios, which is where Tanzu Mission Control with Open Policy Agent (OPA) gatekeeper enters the picture.
Tanzu Mission Control can be utilized to smoothly migrate from PSPs to PodSecurityStandards and OPA Gatekeeper admission policies. By utilizing the dry-run or warn mode of an OPA gatekeeper policy, you can quickly identify pods that do not meet the desired security standards and provide the flexibility you need to remediate them without interruptions. The following image is a look at the policy insights page where we can review the violations and values we need to correct in our manifest.
Policy insights page—viewing a pod security policy violation.
In addition to security admission policies, Tanzu Mission Control helps to continue shifting security responsibilities left and unburdening developers from understanding the intricacies of Kubernetes security by offering mutating security policies. Mutating security policies ensure that all workloads submitted to the admission controller have the desired properties defined by the mutating policy, even if they were not present in the original YAML manifest. A common example and use case is defining a runAsUser for a deployment.
Configuring runAsUser values and conditions for mutating security policy.
Or configuring the pod to run as non-root.
Configuring runAsNonRoot values and conditions for mutating security policy.
If an organization has already made investments into using Terraform, Tanzu Mission Control can integrate into your existing operations pipelines by allowing policy definition as code in the form of Terraform resources, allowing you to easily track changes, implement new policies, or make changes to existing ones. The currently supported policy types supported by the Tanzu Mission Control Terraform module are security, custom OPA, identity access management (IAM), and image policies.
Here is a sample security policy Terraform definition where we are instructing the policy to only audit and not enforce, in addition to disabling the native PSPs on a specific cluster group:
scope {
cluster_group {
cluster_group = "vsphere-lab-dev-group-tf"
}
}
spec {
input {
strict {
audit = true
disable_native_psp = true
}
}
namespace_selector {
match_expressions {
key = "component"
operator = "DoesNotExist"
values = []
}
}
}
}
In this example, we are creating an IAM policy that creates a role binding for service accounts on the desired cluster group:
variable "svc_acct_names" {
description = "Service Account Names"
type = list(string)
default = ["system:serviceaccount:service-bindings:controller", "system:serviceaccount:flux-system:default", "system:serviceaccount:tanzu-system-logging:fluent-bit-sa", "system:serviceaccount:services-toolkit:services-toolkit-controller-manager"]
}
resource "tanzu-mission-control_iam_policy" "vsphere_lab_dev_group_cluster_group_scoped_iam" {
count = length(var.svc_acct_names)
scope {
cluster_group {
name = "vsphere-lab-dev-group-tf"
}
}
role_bindings {
role = "use-privilege-psp"
subjects {
name = var.svc_acct_names[count.index]
kind = "USER"
}
}
}
You can learn how to create a cluster with the Terraform Provider for Tanzu Mission Control, retrieve your Kube configs with the Tanzu Mission Control CLI, create a global namespace, and onboard your clusters using the Tanzu Service Mesh API by following this how-to guide in our Apps & Cloud Management Tech Zone.
Cluster group configuration via continuous delivery now available
Tanzu Mission Control now allows the configuration of cluster groups via FluxCD, becoming one of the few Kubernetes management platforms to offer a high level of consistency for platform engineering teams via an open source tool that streamlines manual work, offers flexibility, and avoids lock-in.
Platform operators are now able to configure a cluster group to point to a repository (public or private) where YAML configuration files are stored. The YAML files are downloaded to the clusters, and the Kubernetes resources described in the YAML files—such as Helm deployments, namespaces, pods, secrets, configMaps, or any other custom resource definitions (CRDs)—are created.
If the YAML is later changed, this change will be detected and automatically reflected in the clusters. Tanzu Mission Control will handle the lifecycle management of Flux or any other associated in-cluster components. The benefit is the uniform application of Kubernetes resources to all clusters in a cluster group, so that they inherit the same configuration, rather than one cluster at a time. This helps eliminate human error when using the CLI for manual configuration since now operators can simply maintain the description of cluster resources in a reusable YAML file.
To review a real-world example of a repository that is currently being used by one of our highly technical partners to manage their Kubernetes clusters in production, read this blog.
Tanzu Mission Control facilitates package management
Support for Helm repositories was introduced following the recent announcement of the availability of the Bitnami Catalog within Tanzu Mission Control.
VMware customers can now select Helm charts from private Git repositories from within the Tanzu Mission Control catalog and create Helm releases on their clusters.
Helm charts are pre-packaged applications that can be deployed on Kubernetes clusters to facilitate the management of Kubernetes applications. They streamline package management and automate deployments or rollback changes implemented on applications during troubleshooting and disaster recovery tasks.
The support for Helm releases in any attached or provisioned cluster in their Tanzu Mission Control allows companies to accelerate their multi-cloud, application modernization journey. It also expands the package management capabilities of Tanzu Mission Control, by reducing the complexity of manually setting up and configuring deployments on an individual cluster basis.
What's next?
Please join our second webinar, in a four-part series, covering the VMware approach to multi-cloud, multi-cluster Kubernetes management.
Visit the Tanzu Mission Control product page, and check the release notes so you don't miss any new features.
Connect with us on Social Media (LinkedIn, Twitter, and Facebook), watch our YouTube videos, and follow the Tanzu blog for more news!
