Corey Dinkens, Sneha Narang, and Lauren Britton contributed to this blog post.
VMware Tanzu Mission Control is a centralized hub for simplified, multi-cloud, multi-cluster Kubernetes management. It helps platform teams take control of their Kubernetes clusters with visibility across cloud, on-premises, and edge environments by allowing users to group clusters and perform operations on these groupings. Users can attach any existing Cloud Native Computing Foundation (CNCF)-conformant clusters they own or provision and manage the lifecycle of VMware Tanzu Kubernetes Grid and Amazon Elastic Kubernetes Service (Amazon EKS) clusters. Tools like GitOps can also be used for cluster creation and configuration.
Because Tanzu Mission Control has been a software-as-a-service (SaaS)-based product, its agent, extension images, and Tanzu packages are deployed to customers' environments from the Tanzu public registry. But with time, we gathered feedback from customers, especially those in regulated industries, asking for the ability to deploy Tanzu Mission Control components from private registries and repositories. They wanted increased security and performance when pulling container images and other artifacts into their Kubernetes clusters managed by Tanzu Mission Control.
So, we are happy to announce that Tanzu Mission Control now supports deploying its cluster images from private container registries. This offers customers complete control over security and vulnerability scanning before the deployment of container images to production environments.
What are container registries?
According to TechTarget, a container registry is a collection of repositories, and a container repository is a collection of container images.
Container images are files containing anything a piece of software needs to run (e.g., system files, resources, and tools).
Container repositories store images for set up and deployment and organizations use those repositories to manage, pull, and push images.
Container registries are collections of repositories (where repositories can further isolate groups of images) that can store container images as well as API paths and access control rules.
Representation of hierarchy between container images, repositories, and registries.
Companies use numerous registries to pull container images—such as open, community-focused registries or their private ones—to enable more rapid and flexible application development.
Registries can be hosted publicly or privately. Public registries are shared with a larger community; while private registries allow organizations to maintain complete control over their images in addition to keeping their images private within the organization.
Many vendors who offer container or Kubernetes solutions also offer container registries to their customers. This includes Tanzu, which provides Harbor, an open source registry that secures artifacts with policies and role-based access control, and ensures images are scanned and free from vulnerabilities, and signs images as trusted.
Private vs. public registries
As mentioned above, companies pull a variety of container images from various sources for rapid and flexible application development.
A couple of benefits of using public registries are
- Community innovation – Members of a community are constantly creating new images that may be useful for many applications.
- Flexibility and choice – Companies can extend beyond their internal team's ability to create useful container images.
But many companies, especially those in regulated industries, do have restrictions regarding the container images they are allowed to use, so private registries would be the better choice.
A couple of benefits of using private registries are
- Improved performance – Large images are pulled from a company’s own infrastructure and not from over the Internet, resulting in lower latency and bandwidth charges. This is especially relevant at edge sites with constrained connectivity.
- Increased security – Since images/artifacts do not leave a company’s private network, companies can use their preferred tool to perform security and vulnerability scanning.
To ensure companies are taking advantage of their custom images and scanned artifacts when using Tanzu Mission Control, we are including support for private registries.
Private registry support at Tanzu Mission Control
VMware customers can now pull Tanzu Mission Control agent images from their trusted, private registry. A great benefit is that they can now ensure that Tanzu Mission Control artifacts are receiving the needed security and vulnerability scans before those artifacts are deployed into their environments.
Customers will no longer have to configure their Kubernetes clusters to allow for image pulls from Tanzu’s public registries—either directly using firewall rules or via a proxy—to gather Tanzu Mission Control agent, extension images, and Tanzu packages.
The support for private registries benefits all customers but mostly those in highly regulated industries, which often have the legal obligation to scan/validate anything coming from a public/external registry before deploying to their production environments. Customers now have the option to use their preferred security and vulnerability scanning tool with the replicated artifacts in their own private registries.
Edge customers also benefit from this added support as they are now able to control when the Tanzu Mission Control cluster agent and extension images are pulled from the public registry into their private registry (and subsequently into their edge environments).
Those customers will be able to use off-peak hours to perform image pulls when the network bandwidth consumed by replicating images will not interfere with line of business applications running in the edge location.
The flow of artifacts from the Tanzu public registry to the customer's private registry, and later to the edge.
In the past, Tanzu Mission Control automatically deployed its agent and extension containers when clusters were registered, managed, created, etc., as well as whenever the VMware team pushed new versions of agents and extensions (which is done multiple times a week). So adding local registry support to Tanzu Mission Control gives customers control over when they replicate/mirror images to their private registry and also avoids InfoSec issues as they are able to use their preferred scanning tool with added flexibility.
Registering a private registry with Tanzu Mission Control
To create a private registry, customers can simply go to the Administration section in Tanzu Mission Control and click the Local Image Registries button.
They can then enter all the details of their local image registry and, once the registry details are saved, can configure a Tanzu Kubernetes Grid cluster to use this private registry.
Adding a new local image registry.
This release supports local image registry for Tanzu Kubernetes Grid clusters on vSphere version 1.6 and later.
What's next?
You can toggle support for local image registry and add local image registries when attaching a cluster to Tanzu Mission Control. Learn more about Managing a Local Image Registry.
Visit the Tanzu Mission Control product page to review key capabilities, 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.
