This section provides conceptual information about VMware Tanzu Application Catalog (Tanzu Application Catalog). It is intended for anyone who wants to get started with Tanzu Application Catalog and use it to provision new Open Source applications. A basic understanding of Kubernetes and familiarity with container deployment concepts is a plus. However, in-depth knowledge of Kubernetes is not required.
The topics covered in this section are:
Tanzu Application Catalog is ideal for any customer that wants to stay competitive and innovative in an increasingly decentralized IT environment. Broadly, the service is applicable to all industries of all sizes, particularly those that rely on open source software in their application development processes.
Tanzu Application Catalog drives innovation by providing production - ready, customizable and flexible multi-cloud components to your developers. Preparing open source software from source form to production-readiness is time consuming, manual, and undifferentiated work that is often times being repeated multiple times across organizations.
Thus, key benefits of using Tanzu Application Catalog are:
Tanzu Application Catalog is a Software as a Service (SaaS) service that provides a curated catalog of custom-configured (to enterprise requirements) open source applications that are continuously maintained and privately delivered. Tanzu Application Catalog enables customers to drive productivity enhancements through seamlessly balancing developer flexibility and IT governance.
Tanzu Application Catalog is based on the same trusted packaging technology and automation that Bitnami, now part of VMware, has been leveraging for many years. With this service, customers will be able to choose which apps they need, which platform(s) they need them for, and what customizations are required (for example, packaging apps on top of a pre-approved “golden” operating system image).
These bespoke applications will be built, packaged, tested, continually maintained (patches, updates, and so on) and delivered to a private repository. The applications can be consumed directly into Continuous Integration pipelines from there, or can be pulled into other destinations for distribution like service catalogs.
The following are some high-level uses cases for Tanzu Application Catalog:
Tanzu Application Catalog includes popular open source solutions across a variety of categories. It a customizable selection of trusted, pre-packaged open-source application components that are continuously maintained and verifiably tested for use in production environments. You may choose to add any application components to your curated catalog that is custom built-to-spec, on your operating system image of choice and delivered securely to your private registry of choice. To view the applications available in Tanzu Application Catalog, see Library.
There are two configurations available while adding new applications to your catalog:
For more information on how to create catalog using these configurations, see Create custom catalogs.
Active artifacts are defined as a unique combination of application, format and base image, packaged for which continuous updates are enabled and delivered by the service.
Customers that purchase an entitlement to an edition of Tanzu Application Catalog can select up to the prescribed number of active artifacts.
An active artifact is any unique combination of application, format and base image. One application packaged in two different formats will result in two distinct combinations, and will thus be counted as two separate active artifacts.
If a customer chooses to use the Basic configuration while adding a new application to their catalog, there is no impact in the artifact count. However, if a customer chooses to use the Custom configuration while adding a new application to their catalog, every artifact chosen is counted and is reduced from the total number of artifacts available.
If a customer wants to use less than the number of active artifacts offered in a purchased edition, they still have to pay the same amount for the SKU.
Each edition offers a maximum number of active artifacts. It is up to the customer to determine how many of those artifacts they choose to use.
As customers go through the process and selecting applications and adding their configurations, the service will track and display the number of active artifacts being consumed.
Customer can purchase multiple Team Editions if they wish to use more than 25 active artifacts.
Tanzu Application Catalog helps you to manage the releases of the containers and charts that you use in your applications.
When selecting a container or chart catalog, you can check the information related to a specific container or chart by clicking the “Details” link.
In the resulting screen, you will find important information associated with the container or chart release:
When checking the details of a container image, you will see under the “Image References” section the following subsections: Digest and Container Tags.
Container images and Helm charts have build time reports associated with them. These reports are generated during the build process so they contain important data (assets information, CVEs detected during the build process, and so on) for users:
Container images, Helm charts, and Virtual Machines have build time reports associated with them. These reports are generated during the build process so they contain important data (assets information, CVEs detected during the build process, and so on) for users:
|Report/Document||Purpose||Container Images||Helm Charts||Virtual Machines|
|Test Results report||Exposes the testing suite that the application passed before releasing.||Yes||Yes||Yes|
|Antivirus Scan Result report||Shows the log of the antivirus scan specifying which directories have been analyzed.||Yes||No||Yes|
|Asset Specification report||Contains information about the asset such as name, version, and the list of system packages.||Yes||Yes||No|
|CSAF VEX document||Contains a comprehensive list of reported vulnerabilities associated with the given software providing assessment details such as vulnerability status, impact, and remediation actions when available following CISA recommendations.||Yes||No||No|
|CVE Scan Result report||Contains a list of known security vulnerabilities and exposures found in the system packages at build time.||Yes||No||Yes|
|SBOM (SPDX) report||Contains metadata that identifies the software package, the package level, and the file level licensing and copyright data.||Yes||Yes||Yes|
|Source Container report||Contains the source code (Dockerfile and so on) used to build the asset.||Yes||No||No|
|Trigger information report||Contains reasons for triggering the build.||Yes||Yes||Yes|
|Vulnerability CVRF report||Contains the same information as the CVE Scan report but using the CVRF industry standard to report vulnerabilities.||Yes||No||Yes|
To access these reports:
Navigate to a catalog, and click the “Details” link of the container image or Helm chart you want to check.
Scroll down to see the “Build time Reports” section.
Click the “Download” link to save a copy of the available reports in your local machine.
To learn how VEX leverages SBOMs and CVE scan results for an efficient vulnerability assessment, see blog post .
The antivirus scan is performed using the ClamAV antivirus scanner. The scan is performed by mounting the container image into a known location inside the antivirus scanner image and then analyzing the location. All files in the container are scanned.
The CVE scan report is performed with Trivy. The Trivy scanner checks both system packages and application dependencies, such as Bundler, Composer, npm, yarn and others.
The CVE scanner is executed every time a container image is built. At build time, the container image installs the latest available packages from the distribution’s repositories. Despite this, there are still some scenarios where the CVE report shows ‘fix available’ for a certain package or CVE:
The container image explicitly installs a specific older version of a package (for example, for backwards compatibility reasons). In this case, there may be a newer version of that package available with a fix for a specific CVE. If this occurs, Bitnami recommends reporting this issue to the support team, which can advise about plans to update that package.
The official security feed for RHEL and CentOS indicates that a fix is available, but the package that includes the fix is not available yet in the CentOS repository. This occurs because although there is a common security feed for RHEL and CentOS, the release cadence for the CentOS repository is slower than that for the RHEL repository.
As a result, new packages which have been released to the RHEL repository may not have yet been released to the CentOS repository and therefore cannot be installed in Bitnami’s CentOS-based container images. This can be directly verified by checking for the specific package that includes the fix in the CentOS repository.
The second scenario also occurs with other CVE scanners that use the official (combined) security feed for RHEL and CentOS.
The CVE scanner is executed every time a container image is built. At build time, the container image installs the latest available packages from the distribution’s repositories. When the base distribution is Photon OS, there are some scenarios where the CVE report shows 0 CVEs.
The security feed for Photon OS publishes CVE information with fixes available. As Tanzu Application Catalog artifacts are rebuilt frequently, these CVE fixes are immediately applied to Tanzu Application Catalog artifacts built on Photon OS. As a result, it is very like that CVE Scan reports for Photon OS-based artifacts might show 0 CVEs.
Supported architecture: AMD or multi-arch which includes containers for both AMD and ARM
Supported architecture: AMD
Exact supported versions can be found in the OS changelog.
The matrix below displays OS distribution versions that have undergone rigorous verification against specific Kubernetes versions and cloud platforms.
These Kubernetes versions are regularly upgraded every quarter, by adding new Kubernetes versions and deprecating the older ones - following the policy stated in the Kubernetes release history. This approach guarantees that Tanzu Application Catalog Helm charts and containers are thoroughly verified and confirmed to work seamlessly in a wide array of deployment scenarios. For more information on verfication, see VMware Tanzu Application Catalog general FAQs.
|Distro version||Kubernetes Platform 1||Kubernetes Platform 2||Kubernetes Platform 3|
|Debian 10||TKG 1.26||-||-|
|Debian 11||AKS 1.25||EKS+ARM 1.28||-|
|Debian 12||GKE 1.27||EKS+ARM 1.28||-|
|Photon 4||AKS FIPS 1.25||Air-gapped GKE env 1.27||EKS+ARM 1.28|
|Red Hat UBI 8||GKE 1.27||AKS 1.25||-|
|Red Hat UBI 9||OpenShift 1.25||EKS+ARM 1.28||-|
|Ubuntu 20.04||TKG 1.26||EKS 1.28||-|
|Ubuntu 22.04||AKS 1.25||GKE 1.27||-|
Platforms: VMware Cloud on AWS
There is no requirement that the output of the service (active artifacts) be consumed within VMware platforms. The artifacts are delivered to a private repository and can be consumed from there and deployed to wherever the customer chooses.
Tanzu Application Catalog provides pre-packaged application templates for VMware private or hybrid-cloud environments, built to your spec and continuously validated in all supported platforms. These application templates are packaged according to industry best practices, and they provide a way for enterprise users to immediately become productive with their VMware cloud infrastructure.
Tanzu Application Catalog for Tanzu Advanced enables organizations to simplify delivery and deployment of custom applications on Kubernetes. Tanzu Application Catalog for Tanzu Advanced provides a catalog based on one hardened base image (Ubuntu 22.04) to all customers. All containers and Helm charts are stored in a common registry, which can be accessed by customers using their account credentials.