Software isn't eating the world; the world is eating software. And when it comes to choosing software, companies today have choices. They can build it themselves. They can buy it from a vendor. Or they can use freely available, open-source software.
Public software repositories, like Docker Hub, make available a huge variety of applications that companies can use to make open-source software available internally. There are containers, ready to run, for just about any software an organization could need—sometimes from more than one source. But that's a double-edged sword.
Because while valuable, such a wide-open marketplace can lead to unintended consequences. Image owners may not update their packages, for example, or malicious code may get embedded. And who knows the last time the base OS image was patched? Confirmed vulnerabilities are admittedly uncommon, especially if an organization is following best practices. But they do pose a risk.
Example application, and the open-source software it may leverage. How to manage it all?
Enter Tanzu Application Catalog (TAC). TAC provides a way for organizations to create their own curated catalog of open-source software. But unlike a public repository, TAC automatically builds you a private repository of software that is updated, scanned for vulnerabilities, and made available daily. And it’s all powered by one of the most trusted names in open-source software providers, Bitnami. You can learn more about TAC in this blog post that explains the product in more detail.
But what about the base image? What if your organization requires the use of a custom "golden image"? No problem. TAC can patch and build your containers using your own custom base OS image. Want to know how it all works? Read on.
What is TAC?
Before we discuss how to get started with TAC, we need to understand what TAC is—and what it isn't. TAC is an engine, powered by Bitnami, that builds custom container images. It then puts those containers into your own private, controlled artifact repository.
TAC is not an artifact repository in and of itself, nor is it a CI/CD pipeline, although it uses both to complete its tasks. Rather, TAC works behind the scenes to make sure your developers are using trusted open-source software.
Getting started with TAC
I find the easiest way to explain how TAC works is to run through a hypothetical onboarding process. First, understand the granularity at which your teams need to be designated. Are some teams creating software that is highly regulated? Do other teams have more leeway, and so would enjoy increased flexibility? TAC uses the notion of catalogs. Each catalog correlates to a team's or organization's private repository. And because TAC uses different base images, and different software to build each catalog, it is highly customizable.
Once you understand the needs of your teams, you can create your first catalog. If you are using a custom base OS image, the first thing you want to do is upload that image. (We will talk about updating a custom base OS later in this post.) Next, add in the URL for your container repository. Then select the software to make available for developers. There is already a lot of software available, and VMware is committed to rapidly growing the list.
The TAC user interface showing each catalog
That's it. On the back end, TAC is now building your custom containers. Once completed, it will upload those containers to your repository. Then your developers can start pulling. Pulling these containers can be done with a Dockerfile, a CI/CD pipeline or any other method supported by your repository. Once the containers are in your repo, TAC is agnostic as to your deployment processes.
Updating software using TAC
Now, as easy as that was to get started, the software does eventually need to get patched. How is this done in a non-TAC world? Maybe you have a CI/CD pipeline set to watch for updates of a public repo, and that pipeline will build your image when an update is pushed. Maybe you just have alerts set up on that repo that notify you when there are updates so someone will go look at them. Whatever your organization is doing, TAC slips in seamlessly. Because it exists outside of your repository, it does not interfere with your existing processes.
If the base OS is patched, regardless of whether it’s custom or open-source, TAC will build a new container complete with a predictable, semantic version tag applied. These tags allow you to create automation rules in your pipelines which, in turn, enables you to deliver safe, trusted code to your users, quickly.
If you have a custom image, the TAC team will build a pipeline to your image repo and check it daily for updates. For open-source base OS images, TAC will monitor those repositories automatically as well as check them daily for security patches and updates.
For the application itself, TAC will also keep your repo up to date with the latest version by default. And similar to the base OS update process, TAC will check daily for new patches and updates and upload any new, tagged container versions into your repo.
So what happens if you need to keep the application locked to a specific version, but want to keep the base OS image updated? That functionality is available. Currently, the TAC team will need to help you do the configuration but in later versions, TAC will become more and more self-service.
Bottom line: TAC is your solution to insecure public repositories. It doesn't get in the way of your existing processes; in fact, it eliminates whole portions of processes that keep software up to date. And it is ideal for highly regulated environments such as banks, aerospace manufacturing or research facilities. If you want to learn more, check out the video demo.
